Subject: RE: [nemo] RE: comments on draft-ietf-nemo-prefix-delegation-00.txt

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Tue, 12 Dec 2006 11:58:56 +0100

Hi Vijay

>>
>> I performed some clean up and republished the draft, mostly as it
was,
>> in order to restart the work on this dormant WG doc.
>
>Do we still need this work? Perhaps DHCPv6-based
>prefix delegation is sufficient for NEMO?

[Pascal] This was discussed before and at this point, the draft is
accepted as a WG document. For the record, we kept text in the draft
that explains why it is there in parallel to DHCP based. This is
detailed in section 4.4 of:
http://www.ietf.org/internet-drafts/draft-ietf-nemo-prefix-delegation-01
.txt 

Pascal

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 12 Dec 2006 14:02:06 +0100

Pascal, Vijay, I'm not sure whether the MIP-based prefix allocation
method is or not useful.  But this discussion helps me see where the
DHCP-based prefix delegation allocation lacks - may need improvement.

Pascal Thubert (pthubert) wrote:
>>>  was, in order to restart the work on this dormant WG doc.
>> Do we still need this work? Perhaps DHCPv6-based prefix delegation 
>> is sufficient for NEMO?
> 

which says:
> Yet, in a deployment where the MNPs are preassigned to the MR, a AAA
>  server, interfacing with the HA, and eventually coupled with a 
> provisioning system in its back end, can provide the required service
>  for assigning and authorizing the prefixes to the MRs; in such a 
> case, the value of implementing a DHCPv6PD server is highly arguable.
>  It is more generic to let the HA handle the backend interfaces on 
> behalf of the MR and expose a consistent NEMO interface for all 
> deployments.

This makes no sense to support MIP-based prefix allocation.

For one, AAA doesn't assign prefixes, but addresses.

The second aspect is that even if AAA allocated prefixes some day then
it wouldn't need MIP to achieve that.  It would do it by itself.

It makes no sense to say that DHCP-based prefix allocation is not needed
because AAA does it.  It doesn't.

There may be an opportunity to extend AAA to do it though.  (not sure
how auhtorization of a prefix would work).

> Delegating Router: A collocated Delegating Router function may not be
>  available for all implementation of NEMO Home Agent.  In particular,
>  some implementations are server based.

And a AAA agent would be available on same HA?

> Operational overhead: Depending on the mechanism that is used to 
> attribute the MNPs to the MRs, the Delegating function, even if 
> available, might be a costly overhead.  Rather, an embedded, back- 
> end agnostic flow might be a desirable option.

You mean AAA?  Is that less costly than DHCP?  Can't DHCP Relay/Server
mechanisms be equated to 'backend'?

> Movement overhead: Some flows, for instance local mobility 
> management, might require a prefix delegation as part of the handling
>  of the movement.  Segregating the delegation from the binding adds a
>  round trip delay to the recovery from the movement.

That's a different thing.  I think you hint netlmm?  I am not sure what
netlmm is currently.  But netlmm done with dhcp may make sense.  Netlmm
done with mip (pmip) may have incompatibilities with mip.

In both cases, extensions to both DHCP and MIP are needed if we talk
netlmm.  We can't just say that MIP does it better.  It's unknown currently.

> Binding Lifetime: It might be useful to associate implicitly the 
> lifetime of a delegated prefix with that of the binding.  This pleads
>  for a design that places the Home Agent function in the flow by 
> construction.

Yes, it is highly desirable to have binding lifetime equal dhcp lease
time.  This can be achieved with a proper interface between dhcp and mip.

> Authentication Mechanism: While NEMO basic Support protects its own 
> flows, there is no mandate to secure the tunneled packets.

I don't get this.  I understand NEMOv6 uses IPsec between MR and HA for
the HoA and CoA and HA@.  Why should the inner (tunneled) packets be
secured?  Why lack of this requirement is supporting the MIP-based
prefix allocation?

DHCP allocation can work securely.

> Back-end interaction: If a prefix is attributed to a MR for a 
> duration that exceeds that of its binding, this information needs to
>  be shared with all HAs, at least for authorization purposes.

This can be achieved by all HAs on link be Relays, although I don't know
  whether a Relay can be a Delegating Router.

Secondary DHCP Servers may work too.

> This requires a specific backend integration that does not exist in 
> the Prefix Delegation Function, for instance via a AAA server.

Not sure what exactly is this function?  What is that AAA server can do
that the DHCP server can't do, in order to share the prefix info amongst
  HAs?

Alex

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 12 Dec 2006 08:17:33 -0800

> http://www.ietf.org/internet-drafts/draft-ietf-nemo-prefix-delegation-01

It is never late to ask such questions. I asked
because nothing was done on this draft for over
a year. And it got published again with the
exact same text, which means no work was done on
it for a while.

Moreover, there seems to be consensus on doing
prefix delegation using DHCPv6.

Vijay