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

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Thu, 14 Dec 2006 17:21:09 +0100

Hi Alex:
>This makes no sense to support MIP-based prefix allocation.
>
>For one, AAA doesn't assign prefixes, but addresses.

[Pascal] The Assign Address Anly protocol :)

On the constructive side, I'd say that the radius attributes for NEMO (:
the protocol, not the user :) are still to be defined - maybe extending
RFC 2868 for NEMO tunnels? If someone is interested in moving forward
with that effort, please raise your hand!

NEMO requires that the HA checks the MNP in explicit prefix mode. One
way of doing that for the HA is to obtain the MNP(s) from a AAA server,
for instance using attribute 26 for the lack of a standard way. 

For instance, both the Home Address and the MNP can be assigned
incrementally and stored in an LDAP directory by the ISP provisioning
system (part of Operations Support System, OSS) when the MR account is
created. AAA does not assign the MNPs, it enables the HA to retrieve
them from some LDAP directory over RADIUS. 

Even though the interaction between the HA and the backend is off topic
for the draft, this example illustrate how the draft enables this very
traditional ISP provisioning model for the case of NEMO. As a result, a
NEMO MR can be shipped to a customer with minimum information and be
bootstrapped upon the first power-on sequence from the HA.

Pascal

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 14 Dec 2006 08:57:24 -0800

> with that effort, please raise your hand!

Nope. We should be extending the following drafts.
http://www.ietf.org/internet-drafts/draft-ietf-mip6-radius-01.txt
http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-01.txt

Vijay

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 14 Dec 2006 20:28:03 +0100

Pascal Thubert (pthubert) wrote:
> On the constructive side, I'd say that the radius attributes for NEMO
>  (: the protocol, not the user :) are still to be defined - maybe 
> extending RFC 2868 for NEMO tunnels? If someone is interested in 
> moving forward with that effort, please raise your hand!
> 
>  way of doing that for the HA is to obtain the MNP(s) from a AAA 
> server, for instance using attribute 26 for the lack of a standard 
> way.

Well, the requirement is to check against the prefix table, not against
a backend.

>  system (part of Operations Support System, OSS) when the MR account 
> is created. AAA does not assign the MNPs, it enables the HA to 
> retrieve them from some LDAP directory over RADIUS.

This sounds as something it could be work on.

But, LDAP is not caring abouot addresses and prefixes to be assigned to
entities.  It cares about other higher level variables such as user
names, passwords, wellknown dns servers and gateways, etc.

> Even though the interaction between the HA and the backend is off 
> topic for the draft, this example illustrate how the draft enables 
> this very traditional ISP provisioning model for the case of NEMO.

Some ISPs use DHCPv3 Secondary servers, not sure whether they call them
'backend', but they do maintain a coherent pool of leases.

So the backend provisioning model can be provided by DHCP too.

> As a result, a NEMO MR can be shipped to a customer with minimum 
> information and be bootstrapped upon the first power-on sequence from
>  the HA.

Same if it were DHCP pd.

This makes think the MIP6 split bootstrapping protocol doesn't deliver
the MNP to the MR part of MN...

Alex