Subject: [MEXT] Last Call: draft-ietf-mext-nemo-pd (DHCPv6 Prefix Delegation for NEMO) to Proposed Standard

From: The IESG <[email-masked]>
Date: Tue, 07 Sep 2010 08:36:20 -0700

The IESG has received a request from the Mobility EXTensions for IPv6 WG 
(mext) to consider the following document:

- 'DHCPv6 Prefix Delegation for NEMO '
   <draft-ietf-mext-nemo-pd-06.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
[email-masked] mailing lists by 2010-09-21. Exceptionally, 
comments may be sent to [email-masked] instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-pd-06.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=17328&rfc_flag=0

No IPR declarations were found that appear related to this I-D.

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 08 Sep 2010 16:58:48 +0200

I agree mainly with the document draft-ietf-mext-nemo-pd.

It is good and needed to dynamically assign a Mobile Network Prefix to
the NEMO-enabled Mobile Router.

However, here are a couple of missing points.

One missing point is about how will the Mobile Router configure its
default route on the home link?  I thought Prefix Delegation would bring
DHCP in the picture and would allow MR to synthesize a default route
even though RAs are absent.  But I now realize that a DHCPv6-PD
implementation (and std?) does not allow a router (MR) to synthesize its
default route (neither RA does, nor DHCPv6-nonPD does).

Another missing point is that this spec talks _only_ one specific case
where DHCPv6-PD is used _without_ a real Relay: the MR is Client and
Relay and the HA is the Server DR.  My deployment is different: the MR 
is not the Relay, just Client; and the Server DR is not HA.  For this to 
work there are some modifications needed on the DHCPv6 Relay 
implementation and std (manage the the allocated prefix in the Relay's 
routing table).

I believe this model of deploying DHCPv6-PD (HA is not Server, Client is
not Relay) is inline with existing DHCPv4 deployments and that gives
an easy v6 migration path.

There are several ways of addressing these two missing points.

Alex

Le 07/09/2010 17:36, The IESG a écrit :
> The IESG has received a request from the Mobility EXTensions for
> IPv6 WG (mext) to consider the following document:
>
> final comments on this action.  Please send substantive comments to
> the [email-masked] mailing lists by 2010-09-21. Exceptionally,
> _______________________________________________ IETF-Announce
> mailing list [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce
>

---

From: Wassim Haddad <[email-masked]>
Date: Wed, 8 Sep 2010 22:54:57 -0700

> default route (neither RA does, nor DHCPv6-nonPD does).

=> Am not sure I understand from your comment where the problem really lies. 
If neither RA does the job nor DHCPv6 then why do you think this problem (if it 
is really a problem) should be adressed in this particular draft and not in a more
general way?

Wassim H.

> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

Regards,

Wassim H.

---

From: Hesham Soliman <[email-masked]>
Date: Thu, 09 Sep 2010 16:01:23 +1000

>> default route (neither RA does, nor DHCPv6-nonPD does).

=> I think the MR can easily act as a host on its egress interface and
configure its default/next hop router that way. Of course the other
alternative is to use routing protocols, but I think using ND should be
sufficient. 

Hesham

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 09 Sep 2010 08:28:30 +0200

Le 09/09/2010 08:01, Hesham Soliman a écrit :
>
>
>
> On 9/09/10 3:54 PM, "Wassim Haddad"<[email-masked]>
> wrote:
>
>>> It is good and needed to dynamically assign a Mobile Network
>>> Prefix to the NEMO-enabled Mobile Router.
>>>
>>> One missing point is about how will the Mobile Router configure
>>> its default route on the home link?  I thought Prefix Delegation
>>>  would bring DHCP in the picture and would allow MR to synthesize
>>>  a default route even though RAs are absent.  But I now realize
>>> that a DHCPv6-PD implementation (and std?) does not allow a
>>> router (MR) to synthesize its default route (neither RA does, nor
>>> DHCPv6-nonPD does).
>
> =>  I think the MR can easily act as a host on its egress interface
> and configure its default/next hop router that way. Of course the
> other alternative is to use routing protocols, but I think using ND
> should be sufficient.

Hesham - when at home, the MR acts  as a router (ip_forward==1,
join all-routers group), as such ND is insufficient to obtain the
default route - it's a Router.

When at home, and using DHCPv-PD, the MR also acquires its Home Address
with DHCPv6.  If so, then it doesn't use SLAAC to auto-configure neither
a Home Address nor a default route.

In implementation it is of course possible to dynamically change MR
behaviour from Host to Router: be at home, first act as host (fwd==0) to
acquire the Home Address and default route, then set fwd=1 and use
DHCPv6-PD to acquire a prefix (but not the Home Address) and take
advantage of the default route acquired previously as a Host.  This is
one way of solving the issue.  However it is not specified.  I am not
sure how clean is it anyways to disregard that 'M' bit of RA anyways.

The alternative to using routing protocols (OSPF?) to communicate a
default route to the MR - I am not sure how this could work, never seen
it in practice.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 09 Sep 2010 08:34:20 +0200

Le 09/09/2010 07:54, Wassim Haddad a écrit :
>> default route on the home link?  I thought Prefix Delegation would
>> bring DHCP in the picture and would allow MR to synthesize a
>> default route even though RAs are absent.  But I now realize that
>> a DHCPv6-PD implementation (and std?) does not allow a router (MR)
>> to synthesize its default route (neither RA does, nor DHCPv6-nonPD
>> does).
>
> =>  Am not sure I understand from your comment where the problem
> really lies. If neither RA does the job nor DHCPv6 then why do you
> think this problem (if it is really a problem) should be adressed in
> this particular draft and not in a more general way?

Right.  I am not sure how could that more general way be.  What do you
mean by a more general way?

Why this particular draft?  Prior to DHCPv6-PD came into picture there
was only one way to configure the MNP in the moving network: manual
config.  If we say manual config then we can also add the default route
manually.  Now we are ready to have SLAAC+DHCP, and as such manual
config seems to be quitting the picture.  YEt there's no means to
configure automatically the default route at home (it's a Router!).

NEMO-DHCPv6-PD could have been a good place where to say how the default
route is configured on the MR at home, since it is _almost_ entirely
automatic.  That's why I call it a missing point.

Alex

>
>
> Wassim H.
>
>
>> Another missing point is that this spec talks _only_ one specific
>> case where DHCPv6-PD is used _without_ a real Relay: the MR is
>> Client and Relay and the HA is the Server DR.  My deployment is
>> different: the MR is not the Relay, just Client; and the Server DR
>> is not HA.  For this to work there are some modifications needed
>> on the DHCPv6 Relay implementation and std (manage the the
>> allocated prefix in the Relay's routing table).
>>
>> I believe this model of deploying DHCPv6-PD (HA is not Server,
>> Client is not Relay) is inline with existing DHCPv4 deployments
>> and that gives an easy v6 migration path.
>>
>>> The IESG plans to make a decision in the next few weeks, and
>>> solicits final comments on this action.  Please send substantive
>>> comments to the [email-masked] mailing lists by 2010-09-21.
>>> Exceptionally, comments may be sent to [email-masked] instead. In
>>> either case, please retain the beginning of the Subject line to
>>> allow automated sorting.
>>>
>> _______________________________________________ Ietf mailing list
>> [email-masked] https://www.ietf.org/mailman/listinfo/ietf
>
> Regards,
>
> Wassim H.
>
>
>
>
>

---

From: Hesham Soliman <[email-masked]>
Date: Fri, 10 Sep 2010 19:30:48 +1000

On 9/09/10 4:28 PM, "Alexandru Petrescu" <[email-masked]>
wrote:

> one way of solving the issue.

=> Exactly. 

 However it is not specified.

=> Who cares, specify it in your product description. The IETF doesn't
specify how to build products. If you want to solve this with protocols then
use routing protocols. Of course you need to solve the security issues when
the MR moves. 

I am not
> default route to the MR - I am not sure how this could work, never seen

=> For  a good reason! You need to work out trust across domains.

Hesham

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 10 Sep 2010 11:43:04 +0200

Le 10/09/2010 11:30, Hesham Soliman a écrit :
>
>
>
> On 9/09/10 4:28 PM, "Alexandru
> Petrescu"<[email-masked]> wrote:
>
>>>>> One missing point is about how will the Mobile Router
>>>>> configure its default route on the home link?  I thought
>>>>> Prefix Delegation would bring DHCP in the picture and would
>>>>> allow MR to synthesize a default route even though RAs are
>>>>> absent.  But I now realize that a DHCPv6-PD implementation
>>>>> (and std?) does not allow a router (MR) to synthesize its
>>> =>   I think the MR can easily act as a host on its egress
>>> interface and configure its default/next hop router that way. Of
>>> course the other alternative is to use routing protocols, but I
>>> think using ND should be sufficient.
>>
>> When at home, and using DHCPv-PD, the MR also acquires its Home
>> Address with DHCPv6.  If so, then it doesn't use SLAAC to
>> auto-configure neither a Home Address nor a default route.
>>
>> behaviour from Host to Router: be at home, first act as host
>> (fwd==0) to acquire the Home Address and default route, then set
>> fwd=1 and use DHCPv6-PD to acquire a prefix (but not the Home
>> Address) and take advantage of the default route acquired
>> previously as a Host.  This is one way of solving the issue.
>
> =>  Exactly.
>
> =>  Who cares, specify it in your product description. The IETF
> doesn't specify how to build products.

Hmm... to me it is a very IETF sensitive issue the Router vs Host.  For 
example, an ND spec says distinctively what a Host and what a Router 
does, e.g. a Host does not respond to Router Solicitation.

In this same way a Router should dynamically be able to obtain a default
route, in addition to a Host doing so.

The products sold are neither Hosts nor Routers - they're BFRs, servers,
desktops, tablets, laptops.

> If you want to solve this with protocols then use routing protocols.
> Of course you need to solve the security issues when the MR moves.

But SLAAC (what you call ND) is not a routing protocol yet does deliver
a default route, only to Hosts.  DHCPv6 is not a routing protocol either
but does not deliver a default route neither to Hosts nor to Routers.

(I am not clear whether the DHCPv6 spec forbids delivery of a default
  route; or allows; I have to check; the implementation does not.)

>> default route to the MR - I am not sure how this could work, never
>> seen it in practice.
>

Probably...

Alex

---

From: Hesham Soliman <[email-masked]>
Date: Fri, 10 Sep 2010 19:48:43 +1000

> does, e.g. a Host does not respond to Router Solicitation.

=> Yes and it does so on a per-interface basis, not on a per-machine basis.

Hesham

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 10 Sep 2010 11:55:31 +0200

Le 10/09/2010 11:48, Hesham Soliman a écrit :
>> Hmm... to me it is a very IETF sensitive issue the Router vs Host.
>> For example, an ND spec says distinctively what a Host and what a
>> Router does, e.g. a Host does not respond to Router Solicitation.
>

Yes, and the Mobile Router is a Router on its egress interface when
connected at home, as per spec.  It is that interface that needs a
default route automatically configured.

Alex

>
> Hesham
>
>>
>> In this same way a Router should dynamically be able to obtain a
>> default route, in addition to a Host doing so.
>>
>> The products sold are neither Hosts nor Routers - they're BFRs,
>> servers, desktops, tablets, laptops.
>>
>>> If you want to solve this with protocols then use routing
>>> protocols. Of course you need to solve the security issues when
>>> the MR moves.
>>
>> But SLAAC (what you call ND) is not a routing protocol yet does
>> deliver a default route, only to Hosts.  DHCPv6 is not a routing
>> protocol either but does not deliver a default route neither to
>> Hosts nor to Routers.
>>
>> (I am not clear whether the DHCPv6 spec forbids delivery of a
>> default route; or allows; I have to check; the implementation does
>> not.)
>>
>>> I am not
>>>> The alternative to using routing protocols (OSPF?) to
>>>> communicate a default route to the MR - I am not sure how this
>>>> could work, never seen it in practice.
>>>

---

From: Hesham Soliman <[email-masked]>
Date: Fri, 10 Sep 2010 19:58:32 +1000

> default route automatically configured.

=> Ok, so you're happy with it being half host half router when it's away
from home? If so then let it do the same at home. Otherwise, I don't know
how you want to fix this in this WG.

Hesham

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 10 Sep 2010 14:00:47 +0200

Le 10/09/2010 11:58, Hesham Soliman a écrit :
>
>
>
> On 10/09/10 7:55 PM, "Alexandru
>>>>> =>    Who cares, specify it in your product description. The
>>>>>  IETF doesn't specify how to build products.
>>>>
>>>> Hmm... to me it is a very IETF sensitive issue the Router vs
>>>> Host. For example, an ND spec says distinctively what a Host
>>>> and what a Router does, e.g. a Host does not respond to Router
>>>>  Solicitation.
>>>
>> Yes, and the Mobile Router is a Router on its egress interface
>> when connected at home, as per spec.  It is that interface that
>> needs a default route automatically configured.
>
> =>  Ok, so you're happy with it being half host half router when it's
> away from home?

When it is away from home it is fully a Host on the egress interface.
When at home fully Router on same.  I am happy with it this way.

> If so then let it do the same at home. Otherwise, I don't know how
> you want to fix this in this WG.

It would mean to specify it to be a at home, be first a Host (get
default route) then change and become a Router, but still at home.

This behaviour could be set in the DHCPv6-PD-NEMO draft, being under
discussion now.

Alex

---

From: Hesham Soliman <[email-masked]>
Date: Fri, 10 Sep 2010 22:12:23 +1000

> When at home fully Router on same.  I am happy with it this way.

=> Ok that doesn't make any sense to me.

> default route) then change and become a Router, but still at home.

=> Ditto.

Hesham

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 10 Sep 2010 16:34:21 +0200

Le 10/09/2010 14:12, Hesham Soliman a écrit :
>
>
>
>>
>> When it is away from home it is fully a Host on the egress
>> interface. When at home fully Router on same.  I am happy with it
>> this way.
>>
>

Well, let me rephrase as the RFC text puts it: when the MR is at home it
joins the all-routers multicast address, otherwise it joins the
all-hosts address.  ND spec says similar.  Similarly, when MR at home it
can send RAs on the egress, if away it MUST NOT send RAs on it.  It must
always send RAs on the ingress.  This is to make sure MR doesn't break
the Internet routing.

Does this sound better?

>>> If so then let it do the same at home. Otherwise, I don't know

Let me phrase otherwise.

Current DHCPv6-PD-NEMO text draft-ietf-mext-nemo-pd-06 says:
> 3.2. Exchanging DHCPv6 messages when MR is at home
>
>
> When the MR is on its home link, the HA uses the home link to
> exchange DHCPv6PD messages with the MR (Figure 3).

It should say: "when the MR is on its homelink, it can obtain an IPv6
address and a default route with SLAAC (if it acts as a Host), or simply
an IPv6 address and no default route, with DHCPv6; then, the HA uses the
home link to exchange DHCPv6PD..."

And in this section:
> 3.5. Other DHCPv6 functions
>
>
> The DHCPv6 messages exchanged between the MR and the HA MAY also be
> used for other DHCPv6 functions in addition to DHCPv6PD.  For
> example, the HA MAY assign global addresses to the MR and MAY pass
> other configuration information such as a list of available  DNS
> recursive name servers [RFC3646] to the MR using the same DHCPv6
> messages as used for DHCPV6PD.

It should say: "neither DHCPv6-PD nor SLAAC allow MR to autoconfigure a
default route".  Is this better?

Do you think there's no need to autoconfigure a default route on the MR
at home?

Do you think there's no problem in the fact that RFC forbids MR to
autoconfigure a default route while connected at home?

Do you think there's no problem in the fact that SLAAC and DHCPv6-PD
implementations dont offer a default route to MR at home?

Do you think nothing should be done at IETF about default route,
DHCPv6-PD and NEMOv6 MR at home?

Alex

---

From: "Laganier, Julien" <[email-masked]>
Date: Fri, 10 Sep 2010 09:57:36 -0700

> This behaviour could be set in the DHCPv6-PD-NEMO draft, being under

This is a non issue for this draft. This is not specific to NEMO but generic to any DHCPv6 Prefix Delegation setup where the requesting router needs to configures an address on its north side. It can do so as per the deployment specifics, including, but not limited to, acting as a host on the north interface and as a router on south interfaces -- please remember that Neighbor Discovery is specified on a per-interface basis.

[ I also note that this draft has been more than 2 years in the MEXT working group in which you are participating, which gave you ample time to comment on this and other things... ]

--julien

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 10 Sep 2010 19:38:20 +0200

Le 10/09/2010 18:57, Laganier, Julien a écrit :
>>>>>>> =>     Who cares, specify it in your product
>>>>>>> description. The IETF doesn't specify how to build
>>>>>>> products.
>>>>>>
>>>>>> Hmm... to me it is a very IETF sensitive issue the Router
>>>>>> vs Host. For example, an ND spec says distinctively what a
>>>>>> Host and what a Router does, e.g. a Host does not respond
>>>>>> to Router Solicitation.
>>>>>
>>>>  when connected at home, as per spec.  It is that interface
>>>> that needs a default route automatically configured.
>>>
>>> =>   Ok, so you're happy with it being half host half router
>>> when it's away from home?
>>
>> This behaviour could be set in the DHCPv6-PD-NEMO draft, being
>> under discussion now.
>
> This is a non issue for this draft. This is not specific to NEMO but
> generic to any DHCPv6 Prefix Delegation setup where the requesting
> router needs to configures an address on its north side.

Right... and a default route - that's the blocking point to me: I have
all this shiny software and RFC but no automatic default route, I have
to manually configure it.

> It can do so as per the deployment specifics, including, but not
> limited to, acting as a host on the north interface and as a router
> on south interfaces -- please remember that Neighbor Discovery is
> specified on a per-interface basis.

It's not sufficient to say Mobile Router always acts as a Host on the
North interface.  Because it must act as a Router too on its North
interface.  It must join the all-routers multicast address on the home
link, in order to forward packets from hosts on the home links towards LFNs.

If you don't like my default route comment then you could also just
write in DHCPv6-PD-NEMO "this does not configure a default route on the
Mobile Router, neither SLAAC".

> [ I also note that this draft has been more than 2 years in the MEXT
> working group in which you are participating, which gave you ample
> time to comment on this and other things... ]

Note taken and I owe explanation.  If you wish consider my comments
non-blocking, as comments to a soon-to-be-Request-For-Comments.

I simply did not have neither the software nor the network testbed to
prototype until now.  Obtaining that is not easy, takes planning and
time. E.g. a stable DHCPv6-PD was available only lately from ISC despite
early initial availability.  It was mainly written for ISP-to-House
deployments which are very different than Mobile Router moving around.

If you wish too, you could bring it back from IESG to here and I will
comment further on it to work with real Relay, to solve
the sync between Prefix Table, Routing Table, radvd.conf, lease file, to
require Relay to insert route (currently it doesn't!), to respect 'M',
and so on.

Or we could just deliver to IESG and see past.  I am fine with all
options.

Alex

---

From: "Laganier, Julien" <[email-masked]>
Date: Fri, 10 Sep 2010 14:18:12 -0700

> to manually configure it.

If you agree that this is generic to DHCPv6 prefix delegation and not limited to this specific application of DHCPv6 prefix delegation to a NEMO environment, then this draft can proceed.

If you are missing a mechanism to get a default route on a DHCPv6 prefix delegation requesting router, you can write a draft and submit it to the DHC WG.

I also don't know what the problem is on most cases. Presumably the requesting router's default route is to send packet to the delegating router. 

> Mobile Router, neither SLAAC".

You agreed earlier that this is generic to DHCPv6 prefix delegation and not specific to NEMO so this draft is NOT the place to digress on default routes for DHCPv6 prefix delegation.
 
> non-blocking, as comments to a soon-to-be-Request-For-Comments.

As you agreed earlier that this is generic to DHCPv6 prefix delegation and not specific to NEMO I do not consider this as blocking. 
 
> time. E.g. a stable DHCPv6-PD was available only lately from ISC
> despite early initial availability.  It was mainly written for ISP-to-House
> the sync between Prefix Table, Routing Table, radvd.conf, lease file,
> to require Relay to insert route (currently it doesn't!), to respect 'M',
> and so on.

We are not bringing it back to the MEXT WG for something that is not related to the MEXT WG but generic to DHCPv6 prefix delegation.
 
> Or we could just deliver to IESG and see past.  I am fine with all

This is what we are doing.

If you really think there's a missing piece, write a draft and submit it to the DHC WG.

--julien

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 10 Sep 2010 23:26:52 +0200

> If you really think there's a missing piece, write a draft and submit it to the DHC WG.

How about megoing to DHC saying this is needed for a NEMO Mobile Router? 
  They'dsay go to MEXT.  Or they'd say this is a SLAAC problem go to 
6MAN.  And so on.  But let me try anyways see what they think.

Alex

---

From: Hesham Soliman <[email-masked]>
Date: Sat, 11 Sep 2010 16:13:51 +1000

> always send RAs on the ingress.  This is to make sure MR doesn't break

=> I thought we were discussing the specific issue of how to solve this
problem in _this_WG_ as I mentioned in my first email. I know what the RFC
says and I wouldn't have done it this way but given this, I don't know how
else you can solve it _here_.

Hesham

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 11 Sep 2010 14:22:30 +0200

Le 11/09/2010 08:13, Hesham Soliman a écrit :
>
>
>
> On 11/09/10 12:34 AM, "Alexandru Petrescu"<[email-masked]>
> wrote:
>

I am open to solve it here and I have suggestion :

- make DHCPv6-PD-NEMO assign a default route to the Mobile Router at
   home.

What do you think?

I also followed advice and went asking to DHC WG.  I got redirected to 
MIF soon-Charter DHCP options route table, and got mentioned 
draft-ietf-v6ops-ipv6-cpe-router req W-3 talking DHCPv6-PD and default 
route.

Alex

---

From: Wassim Haddad <[email-masked]>
Date: Sat, 11 Sep 2010 09:50:44 -0700

> draft-ietf-v6ops-ipv6-cpe-router req W-3 talking DHCPv6-PD and default 

=> Then we better wait for this draft to move forward. 

Regards,

Wassim H.

---

From: Hesham Soliman <[email-masked]>
Date: Sun, 12 Sep 2010 09:03:23 +1000

> - make DHCPv6-PD-NEMO assign a default route to the Mobile Router at

=> That can work but I don't understand why you don't like the host on
egress interface behaviour. The RFC seems inconsistent on its requirements
for the egress interface at home, but it's been a long time since I read it
so I may have forgotten some of the reasons. I think it can work and at
least it will lead to a consistent implementation.
Extending DHCP can work but whether it's done here or in dhc or mif is not
really important to me.

Hesham

---

From: Wassim Haddad <[email-masked]>
Date: Sat, 11 Sep 2010 19:39:23 -0400

Hi Hesham,

Since DHC WG explicitly recommended sending such request to MIF, IMHO trying to do it in 
MEXT will only cause delay in doing it in MIF.

IMHO, the best way forward is not to extend DHCP but to revise and make the change in the 
RFC. But I guess this is another discussion!

Wassim H.

________________________________________
From: Hesham Soliman [[email-masked]]
Sent: Saturday, September 11, 2010 16:03
To: Alexandru Petrescu
Cc: Wassim Haddad; IETF Discussion; mext
Subject: Re: [MEXT] Last Call: draft-ietf-mext-nemo-pd (DHCPv6 Prefix Delegation for NEMO) to Proposed Standard

Hesham

---

From: Alexandru Petrescu <[email-masked]>
Date: Sun, 12 Sep 2010 16:51:14 +0200

Le 12/09/2010 01:03, Hesham Soliman a écrit :
>
>>> =>   I thought we were discussing the specific issue of how to
>>> solve this problem in _this_WG_ as I mentioned in my first email.
>>> I know what the RFC says and I wouldn't have done it this way but
>>> given this, I don't know how else you can solve it _here_.
>>
>> - make DHCPv6-PD-NEMO assign a default route to the Mobile Router
>> at home.
>>
>> What do you think?
>
> =>  That can work but I don't understand why you don't like the host
> on egress interface behaviour.

What do you mean more precisely MR be host on the egress interface?  Do
you mean to set forward=0 for that particular interface on linux
(/proc/sys/net/ipv6/conf/egress/ip_forward).  IF so then that will allow 
the MR to acquire a default route and an address on its egress interface 
at home, but will not allow to forward packets on that interface which 
is bad for a Router.

Do you mean something else when you say to make  Host on the egress 
interface of the Mobile Router? (other than resetting that forward flag).

Alex

> The RFC seems inconsistent on its requirements for the egress
> interface at home, but it's been a long time since I read it so I may
> have forgotten some of the reasons. I think it can work and at least
> it will lead to a consistent implementation. Extending DHCP can work
> but whether it's done here or in dhc or mif is not really important
> to me.
>
> Hesham
>
>>
>> I also followed advice and went asking to DHC WG.  I got redirected
>> to MIF soon-Charter DHCP options route table, and got mentioned
>> draft-ietf-v6ops-ipv6-cpe-router req W-3 talking DHCPv6-PD and
>> default route.
>>
>> Alex
>>
>>
>>>
>>> Hesham
>>>
>>>
>>>
>>>
>>>
>>
>
>
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Sun, 12 Sep 2010 17:27:52 +0200

Le 12/09/2010 01:03, Hesham Soliman a écrit :
>  on egress interface behaviour. The RFC seems inconsistent on its
> requirements for the egress interface at home, but it's been a long
> time since I read it so I may have forgotten some of the reasons. I
> think it can work and at least it will lead to a consistent
> implementation.

I am not sure which RFC you mean seem inconsistent?  If rfc3963 - yes,
it says MR MAY use the received RAs on the egress interface to
autoconfigure an address and form a default route.  However, I think in
practice pure linux does not do it (or am I missing radvd procsys
options?).  One would have to check the public NEMOv6 implementations
too.  Without NEMOv6 implementation this does not work (i.e. that MAY is
interpreted as a no on pure linux).  With it I don't know.

I myself have forgotten many of the reasons.  I think I vaguely remember
Pascal insisting of that being MR-autoconfigure an address as a MAY
because IIRC a Cisco router would autoconfigure an address and a default
route.  I am not very precise on this remembering.

If you mean RFC4861 then I think it is consistent andgood it has this
distinction between Host and Router (Router doesn't autoconfigure a
default route, etc.).  A router is more dangerous to Internet than a
host, so one would make sure things don't get autoconfigured in such a
dangerous manner as to break things and make loops.

> Extending DHCP can work but whether it's done here or in dhc or mif
> is not really important to me.

Same for me.

Remark that this behaviour (install a default route on a Router's
interface when DHCPv6-PD is used) should work irespective to whether or
not Mobile IPv6 is used (NEMOv6), whether or not that router has one or
multiple interfaces (MIF).

In this sense this default router installation upon DHCPv6-PD should be
probably DHC WG.  But they somebody there seemsto say the RR (requesting
router) uses SLAAC to autoconfigure a default route, not DHCP.  And that
a machine acts simultaneously as a host and a router (autoconfigure a
default route _and_ forward packets).  Which seems to be saying what you
were first saying, but still incoherent with that linux forward flag.

Alex

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 13 Sep 2010 08:55:59 -0700 (PDT)

----- Original Message ----
> From: "Laganier, Julien" <[email-masked]>
> To: Alexandru Petrescu <[email-masked]>; Hesham Soliman 
><[email-masked]>
> Cc: IETF Discussion <[email-masked]>; mext <[email-masked]>
> Sent: Fri, September 10, 2010 11:57:36 AM
> Subject: Re: [MEXT] Last Call: draft-ietf-mext-nemo-pd (DHCPv6 Prefix 
>Delegation for NEMO) to Proposed Standard
> 
> This is a non issue for this  draft. This is not specific to NEMO but generic 
>to any DHCPv6 Prefix Delegation  setup where the requesting router needs to 
>configures an address on its north  side. It can do so as per the deployment 
>specifics, including, but not limited  to, acting as a host on the north 
>interface and as a router on south interfaces  -- please remember that Neighbor 
>Discovery is specified on a per-interface  basis.
> 
> [ I also note that this draft has been more than 2 years in the  MEXT working 
>group in which you are participating, which gave you ample time to  comment on 
>this and other things...  ]
> 

Julien: Alex, myself, possibly others have been raising issues with this draft 
since long time.

It is not new.

Regards,

behcet

---

From: "Laganier, Julien" <[email-masked]>
Date: Mon, 13 Sep 2010 13:38:54 -0700

Behcet Sarikaya wrote:
> Laganier, Julien wrote:
> > [...]
> >   working group in which you are participating, which gave you ample time to
> >   comment on this and other things...  ]
> 
> Julien: Alex, myself, possibly others have been raising issues with
> this draft since long time.

... during which there was no consensus that there is an issue to be addressed by the MEXT WG. 

> It is not new.

No, it is not new.

--julien

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 14 Sep 2010 09:01:33 -0700 (PDT)

----- Original Message ----
> To: Behcet Sarikaya <[email-masked]>; Alexandru Petrescu 
><[email-masked]>
> Sent: Mon, September 13, 2010 3:38:54 PM
> Subject: RE: [MEXT] Last Call: draft-ietf-mext-nemo-pd (DHCPv6 Prefix 

I am curious on this. If someone raises an issue during WGLC or IETF LC, 

do we go back to the WG and ask if there is consensus on this issue?

I'll appreciate clarification for my education.

Regards,

Behcet

---

From: "Laganier, Julien" <[email-masked]>
Date: Tue, 14 Sep 2010 12:23:44 -0700

Behcet Sarikaya wrote: 
> 
> Laganier, Julien wrote:
> >
> > Behcet Sarikaya wrote:
> > >
> > > Laganier, Julien wrote:
> > >  >
> > > > [...]
> > > >
> > > > [ I also note that this draft  has been more than 2 years in the
> > > >  MEXT working group  in which you are participating, which gave you
> > > >  ample time to comment on this and other things...  ]
> > >
> > > Julien: Alex,  myself, possibly others have been raising issues
> > > with this draft since  long time.
> >

Good education usually involves one doing his/her homework:

<http://tools.ietf.org/html/rfc2418>

--julien

---

From: Hesham Soliman <[email-masked]>
Date: Thu, 16 Sep 2010 01:27:10 +1000

> interpreted as a no on pure linux).  With it I don't know.

=> Ok but now you're talking about an implementation issue. 3963 allows the
router to act as a host on its egress at home. Either we change
implementations or the RFC needs to be changed. Kernel implementations need
ro change anyway to support nemov6.

> route.  I am not very precise on this remembering.

=> I also think what he suggested makes sense. Which means the MR would act
the same way at home or on a visited link when it comes to listening to RAs.
So it adds little argument to the need for dhc extensions.

> default route, etc.).

=> I was talking about 3963. 4861 is fine in this respect.

Hesham

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 16 Sep 2010 17:52:12 +0200

Le 15/09/2010 17:27, Hesham Soliman a écrit :
>
>
>>> =>   That can work but I don't understand why you don't like the
>>> host on egress interface behaviour. The RFC seems inconsistent
>>> on its requirements for the egress interface at home, but it's
>>> been a long time since I read it so I may have forgotten some of
>>> the reasons. I think it can work and at least it will lead to a
>>> consistent implementation.
>>
>> I am not sure which RFC you mean seem inconsistent?  If rfc3963 -
>> yes, it says MR MAY use the received RAs on the egress interface to
>> autoconfigure an address and form a default route.  However, I
>> think in practice pure linux does not do it (or am I missing radvd
>> procsys options?).  One would have to check the public NEMOv6
>> implementations too.  Without NEMOv6 implementation this does not
>> work (i.e. that MAY is interpreted as a no on pure linux).  With
>> it I don't know.
>
> =>  Ok but now you're talking about an implementation issue. 3963
> allows the router to act as a host on its egress at home. Either we
> change implementations or the RFC needs to be changed. Kernel
> implementations need ro change anyway to support nemov6.
>
>>
>> I myself have forgotten many of the reasons.  I think I vaguely
>> remember Pascal insisting of that being MR-autoconfigure an
>> address as a MAY because IIRC a Cisco router would autoconfigure an
>> address and a default route.  I am not very precise on this
>> remembering.
>
> =>  I also think what he suggested makes sense. Which means the MR
> would act the same way at home or on a visited link when it comes to
> listening to RAs.

I think MR is good to act as a router on the home link and even some
times offer a default route to someone in the home link needing one.
And that makes it MUST send RAs sometimes.

> So it adds little argument to the need for dhc extensions.

In a sense, yes, right, little from NEMOv6 spec requires dhc extensions.
  It is more of my current stubordness requiring dhc extensions to
deliver a default route to a Mobile Router at home.

Alex

>> If you mean RFC4861 then I think it is consistent andgood it has
>> this distinction between Host and Router (Router doesn't
>> autoconfigure a default route, etc.).
>