Subject: Re: [nemo] Re: I-D ACTION:draft-paakkonen-nemo-prefix-delegation-00.txt

From: Ralph Droms <[email-masked]>
Date: Tue, 01 Jul 2003 12:30:16 -0400

All,

Following up on our conversation a couple of months ago
about using DHCPv6 PD for prefix delegation to mobile
routers, I've published "DHCPv6 Prefix Delegation for
NEMO" <draft-droms-nemo-dhcpv6-pd-00.txt>.  This draft
describes the use of DHCPv6 to meet my understanding
of the requirements for prefix delegation to mobile
routers.  Comments welcome...

- Ralph

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 02 Jul 2003 14:58:09 +0200

Ralph Droms wrote:
> Following up on our conversation a couple of months ago about using 
> DHCPv6 PD for prefix delegation to mobile routers, I've published 
> "DHCPv6 Prefix Delegation for NEMO" 
> <draft-droms-nemo-dhcpv6-pd-00.txt>.  This draft describes the use of
>  DHCPv6 to meet my understanding of the requirements for prefix 
> delegation to mobile routers.  Comments welcome...

I'm happy this draft exists and is up for comments. I think that the way
it suggests behaviour of PD between MR and HA is very good for the
simplest mobile network configurations.

> The requirements for basic network mobility support [8] include the 
> ability of the MR to receive delegated prefixes that can then be 
> assigned to links in the mobile network.  DHCPv6PD can be used to 
> meet this requirement for prefix delegation.

Just a short note to mention that the requirements draft is not [8] but
[7] and [7] does not impose that HA MUST be able to delegate prefixes.
But I also think that HA delegating prefixes is a good feature that
would help with dynamic assignment of prefixes.

> The DHCPv6PD DR function MUST be implemented in the HA for the MR. 
> The use of a DHCPv6 relay agent is not defined for DHCPv6PD. [DR 
> delegating router:   the router that acts as a DHCP server, and is 
> responding to the prefix request.]

So I understand HA for Mobile Routers must be a DHCPv6 Server.  But in
the case of Mobile Hosts, the HA can also be a DHCPv6 Relay only, so it
would be nice if HA for Mobile Routers also could act as a Relay only.
Or otherwise the HA for Mobile Hosts be a Server.

> Other updates to the HA data structures required as a side effect of
>  prefix delegation are specified by the particular network mobility 
> protocol.  For example, in the case of "Basic Network Mobility 
> Support" [8], the HA would add an entry in its binding cache 
> registering the delegated prefix to the MR to which the prefix was 
> delegated.

I don't think that any proposed solution would involve triggering
additions of BC entries as a result of PD operations.  Adding entries in
the BC is exclusively a result of Binding messaging, in my understanding.

On another hand, and trying an implementation-independent formulation,
one would say that forwarding information would be updated on the HA as
a result of assigning a prefix to a MR.  And along the same lines, the
same happens at MR: when MR receives a prefix it necessarily adds a
route to its routing table.

Please correct me where I'm wrong with the above.

Other:

I was wondering about the necessity to explain what happens when there
is a FR (fixed router, moves together with MR, sits below MR) inside the
mobile network, and that needs to have its own prefix, supposedly a
sub-prefix of the prefix assigned by HA to MR.  Does the MR (acting as a
RR requesting router) have the power to become a DR and delegate
sub-prefixes to FR?

Or, maybe FR will be itself a RR and request a prefix from the HA
(acting as a DR)?

Thanks for providing the draft for discussion,

Alex
GBU

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 02 Jul 2003 14:58:09 +0200

Other:

Alex
GBU

---

From: Ralph Droms <[email-masked]>
Date: Wed, 02 Jul 2003 10:19:56 -0400

At 02:58 PM 7/2/2003 +0200, Alexandru Petrescu wrote:
>>DHCPv6 PD for prefix delegation to mobile routers, I've published "DHCPv6 
>>Prefix Delegation for NEMO" <draft-droms-nemo-dhcpv6-pd-00.txt>.  This 
>>draft describes the use of
>>ability of the MR to receive delegated prefixes that can then be assigned 
>>to links in the mobile network.  DHCPv6PD can be used to meet this 
>>requirement for prefix delegation.
>

OK ... the definition of HA in section 2 of "Basic Network Mobility 
Support" <draft-wakikawa-nemo-basic-00.txt> [8] states: "HA MUST be able to 
delegate a prefix to a MR by any delegation protocols."  By "requirements 
for basic network mobility support", I was referring to this requirement 
from <draft-wakikawa-nemo-basic-00.txt>.

>>The DHCPv6PD DR function MUST be implemented in the HA for the MR. The 
>>use of a DHCPv6 relay agent is not defined for DHCPv6PD. [DR delegating 
>>router:   the router that acts as a DHCP server, and is responding to the 
>>prefix request.]
>

At present, DHCPv6 prefix delegation requires that the DR share a
link with the RR.  Introducing a DHCPv6 relay agent would require
some additional mechanism to install the correct routing information
on a router that shares a link with the RR.  Installing the routes
would involve some protocol outside DHCPv6 if the DHCPv6 relay
agent is not implemented on a router.

>> protocol.  For example, in the case of "Basic Network Mobility Support" 
>> [8], the HA would add an entry in its binding cache registering the 
>> delegated prefix to the MR to which the prefix was delegated.
>

OK

>route to its routing table.

Agreed - and this routing information update issue is the basis for
the requirement that the DHCPv6 server be in the DR that shares a link
with the RR.

>Or, maybe FR will be itself a RR and request a prefix from the HA

There is no restriction against a device having an RR implementation
on its upstream interface and a DR implementation on the downstream
interfaces, and no restriction against the RR sharing delegated
prefixes with the DR for sub-delegation.  We haven't written
down an explicit explanation of the details...

>Thanks for providing the draft for discussion,

You're welcome, and thanks for the comments...

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Wed, 02 Jul 2003 10:19:56 -0400

OK

- Ralph

---

From: Henrik Petander <[email-masked]>
Date: Thu, 3 Jul 2003 10:52:00 +0300 (EEST)

> simplest mobile network configurations.

Yes, this seems like an easy way to allow a mobile node to become a mobile
router e.g. when user attaches a PDA to her mobile phone.

> the BC is exclusively a result of Binding messaging, in my understanding.

I guess the prefix should be added to the prefix table instead. Then the
HA could authenticate MR as being authorized to send BUs for the delegated
prefix and MR could also send BUs without including explicit prefix
information.

Henrik

		----------------------------------
		Henrik Petander
		Helsinki University of Technology,
		GO/Core Project
		[email-masked]
		Office: +358 (0)9 451 5846
		GSM: +358 (0)40 741 5248
		----------------------------------

---

From: Henrik Petander <[email-masked]>
Date: Thu, 3 Jul 2003 10:52:00 +0300 (EEST)

Henrik

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 3 Jul 2003 14:19:15 +0200 (CEST)

Ralph,

Thanks for writing up the draft.

I noticed a typo in the last paragraph in section 3.1 ("and are may be 
forwarded") but more importantly I think it is unfortunate to use the
term "forwarded" in that context; the packets in question are "sent"
or "originated" by the HA thus they are not forwarded on the tunnel.
I think making this clearer would help given that there has been
some questions on the mailing list on this topic in the past.

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 3 Jul 2003 14:19:15 +0200 (CEST)

Ralph,

  Erik

---

From: Ralph Droms <[email-masked]>
Date: Thu, 03 Jul 2003 08:48:10 -0400

Erik,

In a private communication, I received a recommendation
that section 10.4.4 of draft-ietf-mobileip-ipv6-23.txt
might be a more relevant reference to cite in section
3.1:

10.4.4 Stateful Address Autoconfiguration

    This section describes how home agents support the use of stateful
    address autoconfiguration mechanisms such as DHCPv6 [29] from the
    mobile nodes.  If this support is not provided, then the M and O bits
    must remain cleared on the Mobile Prefix Advertisement Messages.  Any
    mobile node which sends DHCPv6 messages to the home agent without
    this support will not receive a response.

    If DHCPv6 is used, packets are sent with link-local source addresses
    either to a link-scope multicast address or a link-local address.
    Mobile nodes desiring to locate a DHCPv6 service may reverse tunnel
    standard DHCPv6 packets to the home agent.  Since these link-scope
    packets cannot be forwarded onto the home network it is necessary for
    the home agent to either implement a DHCPv6 relay agent or a DHCPv6
    server function itself.  The arriving tunnel or IPsec SA of DHCPv6
    link-scope messages from the mobile node must be noted so that DHCPv6
    responses may be sent back to the appropriate mobile node.  DHCPv6
    messages sent to the mobile node with a link-local destination must
    be tunneled within the same tunnel header used for other packet
    flows.

Rewriting 3.1 to read, in essence:

   "Do what it says in section 10.4.4 of the mobile IPv6 specification"

would clarify the issue.

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Thu, 03 Jul 2003 08:48:10 -0400

Erik,

would clarify the issue.

- Ralph