Subject: RE: [nemo] New draft on prefix delegation

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Tue, 19 Oct 2004 17:41:59 +0200

> -----Original Message-----
> From: Alexandru Petrescu [mailto:[email-masked]]
> Sent: mardi 19 octobre 2004 15:01
> To: T.J.Kniveton
> Cc: IETF NEMO WG; Pascal Thubert (pthubert)
> Subject: Re: [nemo] New draft on prefix delegation
> 
> Hi TJ, Pascal, thank you for putting up this draft proposing to
request
> assignment of prefixes with a BU and assignment confirmation with
BAck.
>   This is an interesting idea.

:)

> Other methods could be DHCP, and even piggybacking with Mobile Prefix
> Discovery or with Dynamic Home Agent Address Discovery, etc.  I'm
> tempted to favor DHCP, see below.
>
You mean DHCPv6PD right? Well, Ralph's draft is more valid then ever. In
fact, it's a WG doc. 

Here, we are looking at a NEMO based alternative, for instance should PD
be overkill in a given deployment. For instance, prefixes might be
attributed be a provisioning system and available to the HA via AAA. 

One value of the NEMO approach is agnostic to the backend installation.

> T.J.Kniveton wrote:
> > Pascal and I have put together a draft that talks about how prefix
> > provisioning and delegation can happen at the NEMO protocol level.
> > This is intended to be a complementary process to what Ralph has
> > described, that happens at the back end and DHCPv6 servers. Ideally,
> >  if the WG thinks this approach is good, we would like to better
> > integrate the DHCPv6 back end approach (and possibly others, if
> > proposed).
> 
> Would a NEMO-PD-enabled HA use a DHCPv6 server to manage the prefix
> allocation? I suppose this is what you mean by "integrate the DHCPv6
> back end approach".
> 
> I personally would go for an entirely DHCP-based solution. Allocating
> and freeing prefixes (and addresses) is usually large programs, risky
to
> run in the kernel space. HA is usually in kernel, DHCP server in app
> space. Exceptions there are to this, ok, but still.

You mean, it's easier for the MR then for the HA to be a DHCP client?

> DHCP has other advantages as well. It already has hierarchical
concepts
> (Server and Relay), while HA has not. This could be used with a large
> moving network served by only a MR and that has many internal FR's
> (fixed). Using DHCP, MR may act as a Client and request a short prefix
> from its home DHCP Server and simultaneously act as a Relay (or
Server)
> and assign a longer prefix to its FR's acting respectively as Clients.
> 
> On the contrary, delegating prefixes in the BU/BAck makes it
impossible
> for FR's to acquire a prefix, since they don't run Mobile IPv6.

You go it right that we thought that the HA might be a PD client. We are
looking for some help from Ralph on the back end consideration section
to detail exactly how that could work.

In that case, the FR can benefit from PD as well.

> An additional advantage of DHCP is reusing the complex management
> software that a DHCP does for addresses (allocate, free, re-allocate,
> manage fragmentation), etc.  HA has no such functionality that could
be
> reused.
Right. The right choice depends a lot on the provisioning. If choice
there is :)

> > CorId: A Correlator that is set by the MR in order to associate a
MNP
> >  request with the prefix given in the confirmation.  There can be at
> > most one active prefix associated with each Correlator.  This
> > mechanism ensures the uniqueness of the allocation of a prefix,
> > should either the BU or the BA be lost in transit.
> 
> In order to guarantee uniqueness of the assignment, the association
> should base also on the Home Address because different MR's may
generate
> same CorID.  With DHCP, this "uniqueness" is based on the MAC address
> and with a Transaction ID.

Right. If it's unclear then it's an issue against the doc. Cool.

> 
> With DHCP there are options for releasing addresses.  On the contrary
> BU-BAck PD does not have a feature to release a prefix.  Releasing is
> important, because if an MR goes asleep another MR can re-use that
prefix.

Yes, there is. But we mapped things to the binding lifecycle as opposed
to making a separate lifecycle. Tighter integration, you know :)

> 
> With DHCP there are options for going in "dormant" mode and back up
> again, minimizing the amount of messages exchanged.
> 
> With DHCP there are possibilities to update the DNS as well (although
no
> prefixes in the DNS, but gateway addresses may be needed).

Right. HA doing DHCPv6PD client for transient prefixes could make a lot
of sense. Managing a local pool could do the job too... For persistent
prefixes, I guess it might rather depend on the AAA system, though.
Let's see what inputs we get from the ML.

Pascal

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 19 Oct 2004 18:19:37 +0200

Pascal Thubert (pthubert) wrote:
>> Other methods could be DHCP, and even piggybacking with Mobile 
>> Prefix Discovery or with Dynamic Home Agent Address Discovery, etc.
>>  I'm tempted to favor DHCP, see below.
>> 
> You mean DHCPv6PD right? Well, Ralph's draft is more valid then ever.
>  In fact, it's a WG doc.

You mean draft-droms-nemo-dhcpv6-pd-01.txt is a WG item?  There are
aspects in that draft that are not necessary in order to delegate
prefixes from HA to MR (Tree Options, MR obtaining a prefix from AR, etc.)

And there are NEMO-relevant aspects that are not mentioned in that
draft.  For example, when MR requests a DP it should be sent on the same
MR-HA tunnel interface, and not "on the interface associated associated
with the upstream router".  Moreover, MR MUST NOT perform Delegating
Router Solicitation operations of RFC3315 while not at home.

draft-droms-pd-nemo:
> For example, in the case of Basic Network Mobility Support [6], the 
> HA would add an entry in its binding cache registering the delegated
>  prefix to the MR to which the prefix was delegated.

No!  Adding an entry in the BC should be a result of receiving a BU and
not of assigning a prefix, IMHO.  However, HA assigning a prefix to MR
SHOULD result in a route added in the HA and a route added in the MR.

>> With DHCP there are options for releasing addresses.  On the 
>> contrary BU-BAck PD does not have a feature to release a prefix. 
>> Releasing is important, because if an MR goes asleep another MR can
>>  re-use that prefix.
> 
> Yes, there is. But we mapped things to the binding lifecycle as 
> opposed to making a separate lifecycle.

I think the MR should still have the opportunity to trigger the release
of a MNP, instead of waiting for a timeout.

Alex

---

From: "T.J.Kniveton" <[email-masked]>
Date: Tue, 19 Oct 2004 13:44:34 -0700

The reason why we wrote this draft are:

1) We want a way for the MR to signal to the HA that it wants either 
(a) a transient prefix to be used for the lifetime of its binding, 
similar to how DHCP would hand out an address, or (b) for a persistent 
prefix to be provisioned at the HA, which the MR can then use for 
subsequent bindings as well.

2) We thought that doing a NEMO-based flow might save on messages, and 
might also give more information and status codes that wouldn't be 
relevant for DHCP.

3) DHCPv6 could be used, but might not be present or implemented in all 
deployments, so this would offer a way to do allocation and delegation 
without necessitating DHCP.

4) We thought that it would not be very difficult to integrate this 
type of solution with a DHCPv6-based solution at the router/HA part.

-TJ

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 19 Oct 2004 22:18:59 -0700

Alexandru Petrescu wrote:
>>> Discovery or with Dynamic Home Agent Address Discovery, etc.

I agree.

Vijay

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 20 Oct 2004 12:27:31 +0200

Pascal Thubert (pthubert) wrote:

>> I personally would go for an entirely DHCP-based solution. 
>> Allocating and freeing prefixes (and addresses) is usually large 
>> programs, risky to run in the kernel space. HA is usually in 
>> kernel, DHCP server in app space. Exceptions there are to this, ok,
>>  but still.
> 

I just meant that address/prefix allocation and keeping track of them is
usually complex software with large data structures, pertaining to run
in userspace, as UDP application level, something that a DHCP Server
does.  And not intended to run in the kernel space, where a HA usually runs.

I didn't mean that either MR or HA is easier to be a DHCP Client.

>> software that a DHCP does for addresses (allocate, free, 
>> re-allocate, manage fragmentation), etc.  HA has no such 
>> functionality that could be reused.
> 

"Provisioning"?

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 20 Oct 2004 12:35:30 +0200

T.J.Kniveton wrote:
> similar to how DHCP would hand out an address, or (b) for a
> persistent prefix to be provisioned at the HA, which the MR can then
> use for subsequent bindings as well.

TJ, a "transient" concept goes against the "continuity" concept of
Mobile IPv6.  An MR would not be interested in "transient" prefixes
because that gives "transient" Home Addresses to LFN, meaning
interrupting communications when changing the prefix.  Or otherwise, did
you also think about binding the "transient" prefix to the "persistent"
prefix? (Care-of Prefix and Home Prefix).

> 2) We thought that doing a NEMO-based flow might save on messages,
> and might also give more information and status codes that wouldn't
> be relevant for DHCP.

This may be true.  DHCP exchange is usually 4 message exchange, BU/BAck
is only 2.  DHCP provides discovery, while BU/BAck no.  I doubt there's
no room for extension in DHCP messages though, to support MNP-delegation
related parameters.

> 3) DHCPv6 could be used, but might not be present or implemented in
> all deployments, so this would offer a way to do allocation and
> delegation without necessitating DHCP.

This may be true, but the modularity concepts suggest to use a simple
tool for such task: Mobile IPv6 for continuity, DHCP for allocation, etc.

> type of solution with a DHCPv6-based solution at the router/HA part.

Ok.

Alex