Subject: [nemo] Comments on draft-droms-nemo-dhcpv6-pd-00.txt

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 22 Oct 2003 19:32:21 +0200

Hi Ralph,

I have some comments with respect to draft-droms-nemo-dhcpv6-pd-00.txt
where it is explained how to use DHCPv6PD between MR and its HA, in a
NEMO (Network Mobility) context.

> The network mobility requirements document [7] defines a solution for
>  mobile IPv6 networks based on the mobile IPv6 protocol [4].

In fact, the requirements document 7 defines just that, and it
prefigures the form of a solution, yes.  And there is a WG item basic
support solution for Mobile IPv6 moving networks
draft-ietf-nemo-basic-support-01.txt

> The requirements for basic network mobility support [8]

[8] draft-wakikawa will probably be outdated, but there is the WG item
mentioned above.  That does not have reqs, so it would be sufficient to
cite 7 instead of 8.

> The HA (acting as the DR) is provisioned with prefixes to be assigned
>  using any of the prefix assignment mechanisms described in the 
> DHCPv6PD specifications.

So the HA will have forwarding information (routes?) in its forwarding
information table (routing table?) with entries for each one of these
prefixes to be delegated, and pointing towards the MR's Home Address,
right?  Maybe those routes will be added at HA only when HA receives a
DHCP Request and only if it replies positively?

In this case, let's look at the overall picture when MR is away from
home and bootstraps and does not have a Mobile Network Prefix (MNP)
allocated.

1- it sends a DHCP request through the tunnel to obtain prefix MNP
2- HA receives this request, allocates one MNP and adds entry in routing
    table.
3- HA sends positive reply to MR and sends it the MNP too.
4- MR sends NEMO BU to HA informing it about this prefix.
5- HA sends back a NEMO Binding Acknowldegement to MR.

It is obvious that messages 4 and 5 are not absolutely needed for
forwarding to work if the message 1 contained some optional bits saying
that this is an MR away from home.

> 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.

In the current nemo basic spec there are actually three ways in which HA
structures are modified: implicit (the prefix is not in the BU, but is
present in the rHA outing table), "explicit network" (the prefix is in
the BU) and "explicit prefix len" (where only the prefix length is sent,
to be applied to the HoA of the address of MR's interface connecting to
the moving network; its egress connects to the home link).

So, I guess that if MR uses implicit mode to update BC of HA, then HA
uses whatever prefix information it has in its routing table.  Whether
that information comes from DHCPv6PD or from a routing protocol like
OSPF, MR does not care.

But, if MR uses explicit network mode to inform its HA about an MNP to
be put in its routing table (or its BC) then that MNP MUST NOt conflict
with the MNP assigned by DHCPv6PD.

Same contention must be avoided if "explicit prefix length" mode is used.

What do you think?

Alex
GBU