Subject: [MEXT] Next steps on prefix delegation

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 25 Nov 2007 12:25:31 +0100

Hi all,

With respect to the NEMO prefix delegation issue, it is my opinion  
that it would be preferred to have a single prefix delegation  
solution rather than two. Moreover, that we should have strong  
technical reasons to do more than one solution since this variety of  
mechanisms without strong reasons adds needless complexity.

So, my first question to the working group is: do you think there are  
strong technical reasons to have more than one solution for prefix  
delegation?

If no, then which would be the preferred approach for prefix  
delegation and why?

Out goal is to try to wrap up this discussion in the next meting

Thanks, marcelo

_______________________________________________
MEXT mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mext

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 25 Nov 2007 12:40:19 +0100

Hi all,

in the DIME working group we have a document that provides the Diameter 
interworking for prefix delegation.
Here is the document:
http://tools.ietf.org/wg/dime/draft-sarikaya-dime-prefix-delegation-ps-00.txt

It would help us in DIME if members of this group could give us some 
feedback.

Ciao
Hannes

---

From: Alexandru Petrescu <[email-masked]>
Date: Sun, 25 Nov 2007 14:15:57 +0100

marcelo bagnulo braun wrote:
> Hi all,
> 
> With respect to the NEMO prefix delegation issue, it is my opinion that 
> it would be preferred to have a single prefix delegation solution rather 
> than two. Moreover, that we should have strong technical reasons to do 
> more than one solution since this variety of mechanisms without strong 
> reasons adds needless complexity.
> 

I really hate that question :-) because you're not saying the 
implications.  (sorry Marcelo nothing personal :-)  I also understand 
that one solution is what standards are about :-)

> If no, then which would be the preferred approach for prefix delegation 
> and why?

The following is not on the "if no" branch.  It's just support 
argumentation for the DHCPv6-based Prefix Delegation for allocating a 
prefix to the Mobile Router from an entity in the home network.

-DHCP can be reused almost zero modifications (really 0 in some cases).
-DHCP has interactions with DNS, this could be used as an advantage
  in the case of delegation of responsibility of reverse resolution.
-allocating prefixes and addresses with MIP6 goes much beyond the
  typical MIP6 capabilities and design.
-leases and timers of allocated addresses: DHCP has built-in, MIP6 would
  need to develop.
-reliability: DHCP Server have graceful failover mechanisms with respect
  to allocated prefixes.  MIP6 would have to develop with respect to
  allocated prefixes.
-potential incoherencies with respect to other MIP6 extensions (PMIPv6
  looks at allocating an address/prefix, some other MIP6-related
  bootstrapping draft IIRC).

Alex

> Out goal is to try to wrap up this discussion in the next meting

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 25 Nov 2007 14:29:00 +0100

Hi Alex,

El 25/11/2007, a las 14:15, Alexandru Petrescu escribió:

>> technical reasons to do more than one solution since this variety  
>> of mechanisms without strong reasons adds needless complexity.
>> So, my first question to the working group is: do you think there  
>> are strong technical reasons to have more than one solution for  
>> prefix delegation?
>
> implications.

What are the implications you are referring to?

regards, marcelo

> (sorry Marcelo nothing personal :-)  I also understand that one  
> solution is what standards are about :-)
>
> argumentation for the DHCPv6-based Prefix Delegation for allocating  
> a prefix to the Mobile Router from an entity in the home network.
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Sun, 25 Nov 2007 14:38:15 +0100

> What are the implications you are referring to?

Do you imply that if we agree there should be one solution and that it 
turns out voting leads to the MIP6-based prefix allocation then 
dhcpv6-pd-based prefix allocation for NEMO disappears?

Alex

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 25 Nov 2007 15:04:38 +0100

El 25/11/2007, a las 14:38, Alexandru Petrescu escribió:

>>>> With respect to the NEMO prefix delegation issue, it is my  
>>>> opinion that it would be preferred to have a single prefix  
>>>> delegation solution rather than two. Moreover, that we should  
>>>> have strong technical reasons to do more than one solution since  
>>>> this variety of mechanisms without strong reasons adds needless  
>>>> complexity.
>>>> So, my first question to the working group is: do you think  
>>>> there are strong technical reasons to have more than one  
>>>> solution for prefix delegation?
>>>
> Do you imply that if we agree there should be one solution and that  
> it turns out voting leads to the MIP6-based prefix allocation then  

I am trying not to imply anything, but stating it as much up front as  
i can :-)

We are chartered to work on prefix delegation for NEMO, so we need to  
produce a solution for that problem. In principle, only one solution.  
This means that if we find one solution that provides all the  
features that we consider necessary, yes, we will discard other  
solutions.
It may be the case that we come to the conclusion that we need more  
than one solution based on technical considerations, such as (for  
example) that the different approaches work in different scenarios  
and there is not a single approach that works for all the scenarios  
that we deem necessary to support. However, we must be convinced that  
this is the case and i don't think we are there yet.

hence, my question to the wg.

is this clearer now?

Regards, marcelo

---

From: Alexandru Petrescu <[email-masked]>
Date: Sun, 25 Nov 2007 18:02:27 +0100

marcelo bagnulo braun wrote:
> I am trying not to imply anything, but stating it as much up front as i 
> can :-)
> 
> This means that if we find one solution that provides all the features 
> that we consider necessary, yes, we will discard other solutions.
> It may be the case that we come to the conclusion that we need more than 
> one solution based on technical considerations, such as (for example) 
> that the different approaches work in different scenarios and there is 
> not a single approach that works for all the scenarios that we deem 
> necessary to support. However, we must be convinced that this is the 
> case and i don't think we are there yet.
> 

YEs, it is clearer, thanks for the explanation.

My answer to the question then is: yes, in principle one solution is. 
If on technical considerations and different scenarios then we need to 
support the other as well.

Alex

---

From: Vijay Devarapalli <[email-masked]>
Date: Sun, 25 Nov 2007 09:16:43 -0800

Well, this document seems to assume (or make a case) that the AAA
manages the prefixes. We *do not* recommend that model. It is
typically either the home agent or a DHCP server co-located with
the home agent that manages the prefixes.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Sun, 25 Nov 2007 10:04:37 -0800

> the home agent that manages the prefixes.

One minor clarification. By co-location, I did not mean that the HA
and the DHCP server should be implemented on the same box.

Vijay

> 
> Vijay
> 
> Hannes Tschofenig wrote:
>> Hi all,
>>
>> in the DIME working group we have a document that provides the 
>> Diameter interworking for prefix delegation.
>> Here is the document:

---

From: Sri Gundavelli <[email-masked]>
Date: Sun, 25 Nov 2007 10:19:24 -0800 (PST)

Comments:

- The document is making a case that AAA should manage the
   prefix delegation aspect, just as how it can manage an
   address for a node.

In principle, I agree the home agent or other function that
provides mobility can potentially offload the prefix mgmt
function to AAA or other entity. It can use DHCPPD, AAA or a
local pool for managing this.

I agree with the document, that AAA can manage prefixes.

The use of AAA is just one mechanism. Typically, if the addressing
model is assignment of a prefix for a user, any bootstrapping
solution using AAA, can certainly download one more attribute
for the user prefix(es).

But, I'm not sure if we need to have a PS for this, as supposed
to capturing this in a solution document. As this is just a
minor thing in all the details related to address mgmt function.

Sri

---

From: "Frank Xia" <[email-masked]>
Date: Sun, 25 Nov 2007 21:38:38 -0600

Hi Vijay

AAA servers  managing address pool is one of the basic funtions in the industry.   

In the point-to-point scenario, different MNs have different prefixes.  That is ,
prefix managing is the natural extension for the address management.

Please see other  inline response...

BR
Frank

----- Original Message ----- 
From: "Vijay Devarapalli" <[email-masked]>
To: "Hannes Tschofenig" <[email-masked]>
Cc: <[email-masked]>
Sent: Sunday, November 25, 2007 11:16 AM
Subject: Re: [MEXT] Prefix delegation & Diameter Interaction

> the home agent that manages the prefixes.
Frank=>It is sure that home agent  or built-in DHCP server can manage
prefixes.   This is local prefix management mode.  IMHO,  it is not optimal. 
If we think that  prefix management is the extension of address management,
it is easy to think about remote prefix management mode.

---

From: "T.J. Kniveton" <[email-masked]>
Date: Sun, 25 Nov 2007 23:25:07 -0800

marcelo bagnulo braun wrote:
> example) that the different approaches work in different scenarios and 
> there is not a single approach that works for all the scenarios that 
> we deem necessary to support. However, we must be convinced that this 
> is the case and i don't think we are there yet.

Yes, it is the case that the two solutions are based on different 
technical considerations, and that they work in different scenarios. 
They have different properties, and require different levels of 
implementation complexity to achieve them. Making an informed decision 
would require understanding these trade-offs, ideally by implementing 
one or both. The reason that Pascal and I wrote the NEMO delegation 
method was that we felt there were important cases that were not 
necessarily addressed by requiring the DHCPv6-based method.

Since the group originally decided to do both, it will require further 
input to determine what's the best course of action. That is input that, 
unfortunately, I was not able to tease out of the participants so far. 
Maybe that will be different in Vancouver.

TJ

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 26 Nov 2007 08:34:07 +0100

Right:

Please note that draft-ietf-nemo-prefix-delegation came after the
DHCP-PD work. 
So we had to explain why we did this and were prepare to get the
question over again. 
This is why the document has strong requirement and rationale sections
(3 and 4). 
In particular, please have a look at: "4.4.  Why not Alternate standard
based solutions? "

Note also that the draft does not prevent using DHCP-PD in the back end.
In fact, that is recommended.
What the draft does is enable the HA to proxy the PD just the way it
proxies the ND.
This saves exchanges, makes flows simpler, and maintains back end states
when the MR is not reachable. 

Pascal

>-----Original Message-----
>From: T.J. Kniveton [mailto:[email-masked]]
>Sent: Monday, November 26, 2007 8:25 AM
>To: marcelo bagnulo braun
>Cc: [email-masked]
>Subject: Re: [MEXT] Next steps on prefix delegation
>
and

---

From: "Alper Yegin" <[email-masked]>
Date: Mon, 26 Nov 2007 14:52:30 +0200

Vijay,

Can you explain why you do not recommend AAA-assignment of prefixes?

Alper

> From: Vijay Devarapalli [mailto:[email-masked]]
> Sent: Sunday, November 25, 2007 7:17 PM
> To: Hannes Tschofenig
> Cc: [email-masked]

---

From: Julien Laganier <[email-masked]>
Date: Mon, 26 Nov 2007 14:28:27 +0100

Folks,

Please see below:

> Out goal is to try to wrap up this discussion in the next meting

I would like to complement Marcelo's question with some more questions 
from my side. I am quoting below one of the Architectural Principles of 
the Internet [RFC1958]:

   3.2 If there are several ways of doing the same thing, choose one.
   If a previous design, in the Internet context or elsewhere, has
   successfully solved the same problem, choose the same solution unless
   there is a good technical reason not to.  Duplication of the same
   protocol functionality should be avoided as far as possible, without
   of course using this argument to reject improvements.

In light of this, it seems to me that we should select one mechanism 
only for prefix delegation in the context of NEMO. If DHCPv6-PD would 
work, it seems that it should be the only solution adopted. Things are 
not that simple however and it is possible that very good reasons 
justify the specification of a new mechanism for prefix delegation in 
the context of NEMO. 

To help the WG understand the tradeoffs involved and make an educated 
choice, I'd like to ask the following questions:

   o What could possibly make the existing DHCPv6 PD unsuitable to be
     used for NEMO PD? 

   o In case DHCPv6 is suitable but introduces limitations in the
     context of NEMO that makes it desirable to standardize another
     prefix delegation mechanism for NEMO, what would be the
     limitations?

Once we have answered these questions I believe the WG will be in the 
best position to make the best choice.

Cheers,

--julien

---

From: RYUJI WAKIKAWA <[email-masked]>
Date: Tue, 27 Nov 2007 00:58:38 +0900

Hi Julien and all,

Agree that solo solution is always better, but I support both  
solutions for MNP delegation.

DHCP PD is simple solution, but it requires DHCP functionalities at HA  
and MR.
DHDP PD seems practical when MR boots up in home network.
However, when MR boots up in foreign network, MR must creates a tunnel  
to send any DHCP messages.
It means it takes several message exchanges between MR and HA to get  
MNP in bootstrap.

PMIP uses similar way of NEMO PD to assign prefix to MN during binding  
registration.
If MR uses IKE for HoA assignment, it can setup a tunnel and obtain  
its MNP simultaneously by initial BU.

We have to remember that MR is also MIP6-MN.  MIP6 WG standardized  
several ways to assign HoA to  MN.

Another question is that shall we have a mechanism to assign HoA and  
prefix at the same time?
We should update both documents or write another document how NEMO  
bootstrap work
with MIP6 bootstrap mechanisms.

There are certainly pros & cons. Operator should select one.

regards
ryuji

---

From: Julien Laganier <[email-masked]>
Date: Mon, 26 Nov 2007 19:22:41 +0100

Hello Ryuji,

I'd still like the questions I've asked to be answered, but anyway: 

<chair hat off>:

On Monday 26 November 2007, RYUJI WAKIKAWA wrote:
> DHCP PD is simple solution, but it requires DHCP functionalities at
> HA and MR.
> However, when MR boots up in foreign network, MR must creates a
> tunnel to send any DHCP messages.

Since booting a node typically consumes quite some time it seems the 
delay incurred by an additional message exchange could be considered as 
neglogible.

> PMIP uses similar way of NEMO PD to assign prefix to MN during
> binding registration.

This discussion is about NEMO prefix delegation; AFAICT PMIP doesn't 
require *delegation* of prefixes, thus it is not a good comparison 
w.r.t. this discussion.

> its MNP simultaneously by initial BU.

As I said above if the MR is booting up I don't see the MNP assignment 
as time critical.

> several ways to assign HoA to  MN.

Well, first of all it is not because one choice was made in one 
situation that this choice applies in every other situation.

In this specific case the HoA assignment is an *address* *assignment*, 
and we're talking here about *prefix* *delegation*.

What makes the two fundamentally dissimilar is that to assigns addresses 
you can use stateless or statefull mechanism, whereas to delegate a 
prefix a stateful mechanism is required.

Thus I do not see the comparison between MIPv6 HoA assignment and NEMO 
PD as relevant.

> Another question is that shall we have a mechanism to assign HoA and

I don't think so, this looks like an optimization on something that 
isn't time critical anyway. What would be the point of coupling these 
two, maybe I'm missing something. Modularity is a feature IMHO.

> bootstrap work with MIP6 bootstrap mechanisms.
>

Well, one thing I'm sure is that having two mechanisms is a drawback 
since it might require coordination between vendors and administrators 
on the operator and MN sides. When a single mechanism is present no 
such coordination is needed.

Cheers,

--julien

> > I would like to complement Marcelo's question with some more
> > questions from my side. I am quoting below one of the Architectural
> > Principles of
> > the Internet [RFC1958]:
> >
> >    3.2 If there are several ways of doing the same thing, choose
> > one. If a previous design, in the Internet context or elsewhere,
> > has successfully solved the same problem, choose the same solution
> > unless
> >    there is a good technical reason not to.  Duplication of the
> > same protocol functionality should be avoided as far as possible,
> > without
> > In light of this, it seems to me that we should select one
> > mechanism only for prefix delegation in the context of NEMO. If
> > DHCPv6-PD would work, it seems that it should be the only solution
> > adopted. Things are not that simple however and it is possible that
> > very good reasons justify the specification of a new mechanism for
> > prefix delegation in the context of NEMO.
> >
> > To help the WG understand the tradeoffs involved and make an
> > educated choice, I'd like to ask the following questions:
> >
> >    o What could possibly make the existing DHCPv6 PD unsuitable to
> > be used for NEMO PD?
> >
> > Once we have answered these questions I believe the WG will be in
> > the best position to make the best choice.
> >
> > Cheers,
> >
> > --julien
> >

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 26 Nov 2007 10:39:51 -0800

> Can you explain why you do not recommend AAA-assignment of prefixes?

We have been through this many times on the MIP6 mailing list.
The earlier discussions were based on AAA assigning the home
address. We have always concluded otherwise. I don't see much
different between AAA managing home prefixes and home addresses.
I am not planning to rehash those discussions.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 26 Nov 2007 10:53:31 -0800

>    o What could possibly make the existing DHCPv6 PD unsuitable to be

Having to implement a DHCPv6 relay functionality on the home agent
is one issue. And many folks don't seem to be too comfortable with
running DHCPv6 over the tunnel between the mobile router and the
home agent.

There is a parallel discussion going on on the MIP4 mailing list
about using DHCP.
http://www1.ietf.org/mail-archive/web/mip4/current/msg02727.html

>      prefix delegation mechanism for NEMO, what would be the

It will work. The issue is more about which solution is more easily
implementable/deployable. For example, it is quite straight forward
for the mobile router to request for a mobile network prefix in the
binding update and get a prefix in the binding ack. The home agent
just needs to have a local pool of mobile network prefixes.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 26 Nov 2007 11:04:58 -0800

> AAA servers  managing address pool is one of the basic funtions in the industry.   

Thats news to me. AFAIK, static home addresses are stored in
the subscription profile of the user. Home addresses allocated
dynamically typically from the home agent.

Vijay

---

From: Frank Xia <[email-masked]>
Date: Mon, 26 Nov 2007 13:31:59 -0600

Hi Vijay

AAA servers can  manage static address pool which is discribed in your email.

At the same time, AAA servers can manage dynamic static address pool.  For
example, AAA servers allocate  dynamic addresses for  each PPP sessiones.

BR
Frank

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 26 Nov 2007 20:45:52 +0100

Hi Vijay,

maybe you can provide some pointers to past discussions and conclusions. 
You cannot expect that everyone follows all mailing lists and now this 
work is being proposed for DIME.

Ciao
Hannes

PS: I once had comments for a QoS document and I got the following 
response "I don't have time to give you a tutorial on this QoS issue. We 
discussed this at length in face-to-face meeting at the IETF XYZ meeting."

The document got delayed for more than a year when the same questions 
showed  up later again....

Vijay Devarapalli wrote:
>>>> http://tools.ietf.org/wg/dime/draft-sarikaya-dime-prefix-delegation-ps- 
>>>>
>>> 00.txt
>>>>

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 26 Nov 2007 21:42:23 +0100

> work is being proposed for DIME.

Sorry for intruding... it's difficult for someone to dig archives, as 
much as it is for you.

I share the part of Vijay's view that somehow somewhere in the MIP6 
discussions (was that during MIP WG?  MIP6 WG?  playground at SUN? 
ietf.org list?) and during the meeting minutes it was pretty clear that 
the MN's Home Address would not be allocated by the AAA system.  MIP6 
would be supposed to work with any system to allocate addresses.  That's 
my personal rememberings.

Not to correct in any way, just to share a view.

Alex

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 26 Nov 2007 21:46:59 +0100

Quick comment:

Alexandru Petrescu wrote:
> Hannes Tschofenig wrote:
>> Hi Vijay,
>>
>> maybe you can provide some pointers to past discussions and 
>> conclusions. You cannot expect that everyone follows all mailing 
>> lists and now this work is being proposed for DIME.
>
Are you saying that it is as difficult for me to find the pointer to the 
discussion as it is for Vijay?
When I participated in discussions then I typically remember the context 
and roughly the time when they happened. This makes it easier to find it.

Ciao
Hannes

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 26 Nov 2007 12:54:23 -0800 (PST)

On Mon, 26 Nov 2007, Hannes Tschofenig wrote:

>>  Sorry for intruding... it's difficult for someone to dig archives, as much
>>  as it is for you.
> When I participated in discussions then I typically remember the context and 
> roughly the time when they happened. This makes it easier to find it.
>

But, if the discussion took place so long ages ago. May be its
worth revisiting that and to  ensure the assumptions that were
used for arriving at that conclusion are still valid. Or, some
one can atleast state one or two arguments from that discussion,
if at all, if they remember those.

Sri

---

From: "T.J. Kniveton" <[email-masked]>
Date: Mon, 26 Nov 2007 13:17:28 -0800

I think that Ryuji's message shows that:

If you want to select one prefix delegation mechanism for NEMO, and have 
it fit a situation where a mobile network is away from the home 
infrastructure, and have the number of messages passed be reasonably 
low, with low complexity...

then, more engineering work is needed.

As I said before, there is a reason that there are two drafts instead of 
one. If you consider this "several ways of doing the same thing" as per 
RFC 1958, then more work will be necessary to create one way of doing it 
that works well.

If, on the other hand, you want to make the assumption that any network 
with NEMO will have DHCP deployed, and you are not concerned about 
bootstrapping a tunnel to the home network to exchange DHCP messages, 
then DHCP is the way to go. But in this case, the minimum effort needed 
would be to lay out the assumptions and have some consensus in the group 
that this is a reasonable engineering compromise.

TJ

---

From: "T.J. Kniveton" <[email-masked]>
Date: Mon, 26 Nov 2007 13:44:31 -0800

Since Julien brought up RFC 1958, let's talk a little bit more about 
Internet engineering philosophy:

IPv6 was designed so that a node can obtain an address by:

1. Stateless configuration. The node receives a router advertisement and 
constructs an address by appending its own suffix, using neighbor 
discovery to ensure it's unique.

2. Stateful configuration. An authoritative DHCP infrastructure is in 
place, and the end node queries the DHCP server(s), and it receives an 
address, and other associated configuration data.

(Note: these are two methods for accomplishing the same goal.)

Now throughout the Mobile IP(v6) engineering effort, there has been a 
largely unspoken assumption that we should continue to use a stateless 
configuration paradigm. That is why we have things like Dynamic Home 
Agent Address Discovery, Mobile Prefix Solicitation/Advertisements, 
bootstrapping, etc. Otherwise, we would just rely on a big DHCP brain in 
the sky to tell the end node all of its configuration information. The 
way I see it, using option #1 means that we are furthering the Internet 
protocol capabilities while remaining consistent with the long-standing 
ideal that the intelligence lies in end nodes, not in the network.

In writing the prefix delegation draft, it was my intention to continue 
the above-mentioned ideal, and allow nodes to request a prefix directly 
from whence they are being managed in some cases (such as where Vijay 
pointed out), in the HA.

[Note: I do not agree with your supposition that receiving a prefix is 
tantamount to stateful address configuration: when I bind a home address 
to a care-of address, or assign myself a care-of address using stateless 
address autoconfiguration, neither one involves the use of DHCP.]

So, the question is this: do we want to continue the evolution of the 
protocol suite that includes IPv6, Mobile IPv6, and NEMO, and have a 
mechanism for requesting use of a prefix, or do we want to say, well, 
this is too complicated; if you want to do this, you are going to need 
to install a DHCP infrastructure.?

So far, it seemed logical to describe both methods and allow people to 
decide how they want to implement a system. However, if we are 
restricted to standardizing one method, more study is needed of 
realistically deployable systems to determine which direction is better 
to go in, and to understand the implications. I have been waiting a 
couple years and have not seen these prefix delegation schemes be 
implemented yet, so further study, IMHO, is necessary before declaring 
that "DHCP makes sense" or "most IPv6 networks will have DHCPv6 services 
deployed" and we should just go that direction.

TJ

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 26 Nov 2007 22:58:33 +0100

Sri Gundavelli wrote:
>>> conclusions. >  You cannot expect that everyone follows all mailing 
>>> lists and now this >  work is being proposed for DIME.
>>>
>> Are you saying that it is as difficult for me to find the pointer to 
>> the discussion as it is for Vijay?
>> When I participated in discussions then I typically remember the 
>> context and roughly the time when they happened. This makes it easier 
>> to find it.
>>
> 

For example, some thing I remember vaguely.  But there are surely many 
other people here with more rememberings.

If MIP6 doesn't rely on a mechanism to auto-configure an address, and 
works independently of it - then some people could plug AAA with MIP6, 
others could plug SLAAC with it.  Or similar.

So, if one would go along same lines, one wouldn't build AAA into MIP6 
for delivering the home prefix to the MR.

A related question: when a PDA router connects to a IPv6 infrastructure, 
and obtains a prefix with Diameter, or ppp, from the AAA infrastructure 
- would it _have_ to run NEMO-extended-MIP6?  Maybe not.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 26 Nov 2007 23:40:14 +0100

T.J. Kniveton wrote:
> 1. Stateless configuration. The node receives a router advertisement
>  and constructs an address by appending its own suffix, using
> neighbor discovery to ensure it's unique.
> 
>  place, and the end node queries the DHCP server(s), and it receives
>  an address, and other associated configuration data.
> 
>  largely unspoken assumption that we should continue to use a 
> stateless configuration paradigm. That is why we have things like 
> Dynamic Home Agent Address Discovery, Mobile Prefix 
> Solicitation/Advertisements, bootstrapping, etc.

I agree with these and I support both of them.

> Otherwise, we would just rely on a big DHCP brain in the sky to tell
>  the end node all of its configuration information.

Well I share your view of prefering distributed systems, and at the same 
time there must be somebody up there already telling the deployed 
routers what to put in their RAs and on their interfaces.

> The way I see it, using option #1 means that we are furthering the 
> Internet protocol capabilities while remaining consistent with the 
> long-standing ideal that the intelligence lies in end nodes, not in 
> the network.
> 
> In writing the prefix delegation draft, it was my intention to 
> continue the above-mentioned ideal, and allow nodes to request a 
> prefix directly from whence they are being managed in some cases 
> (such as where Vijay pointed out), in the HA.
> 
> [Note: I do not agree with your supposition that receiving a prefix 
> is tantamount to stateful address configuration: when I bind a home 
> address to a care-of address, or assign myself a care-of address 
> using stateless address autoconfiguration, neither one involves the 
> use of DHCP.]

HA another stateful Server?  I suppose yes: It
simply must maintain states about that allocated prefix so not to
allocate it to somebody else.  Would HA run extended-DAD to make sure 
nobody on the home link uses the prefix it's about to allocate?  For a 
start I don't know how to relate two prefixes one to another: are they 
equal?  are they aggregated?

>  mechanism for requesting use of a prefix, or do we want to say, 
> well, this is too complicated;

Hehe

> if you want to do this, you are going to need to install a DHCP
> infrastructure.?
 >
> So far, it seemed logical to describe both methods and allow people 
> to decide how they want to implement a system. However, if we are 
> realistically deployable systems to determine which direction is 
> better to go in, and to understand the implications. I have been 
> waiting a couple years and have not seen these prefix delegation 
> schemes be implemented yet,

Not sure what you mean... but Dibbler seems to be doing DHCPv6-PD.

I do share many of the opinions you expressed above.

Alex

> so further study, IMHO, is necessary 
> before declaring that "DHCP makes sense" or "most IPv6 networks will
>  have DHCPv6 services deployed" and we should just go that direction.

> 
> 
> TJ
> 
> _______________________________________________ MEXT mailing list 
> [email-masked] https://www1.ietf.org/mailman/listinfo/mext
>

---

From: Romain KUNTZ <[email-masked]>
Date: Mon, 26 Nov 2007 23:44:18 +0100

Hi Julien, Ryuji,

>> bootstrap work with MIP6 bootstrap mechanisms.

Yes that point was raised in one of the original mail that started  
this discussion.
The MIP6 bootstrapping work defined 2 scenarios: split and integrated.  
In the split case, the Mobility Service Authorizer is separated from  
the Mobility Service Provider. It relies on a backend AAA architecture  
where the HA contacts the MSA to authenticate the MN and authorize the  
mobility service. When delegating prefixes in the split scenario, the  
HA would also need to rely on that architecture, e.g. to authorize a  
prefix that the MR claims. It would thus make sense to build a  
delegation mechanism partly based on the MIP6 work.

Different point: I'd also like to add that draft-ietf-nemo-prefix- 
delegation raises some issue when the MR boots in the home network :  
how does the MR gets a prefix as long as it does not send BU?

Cheers,
romain

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 26 Nov 2007 15:44:25 -0800 (PST)

On Mon, 26 Nov 2007, Alexandru Petrescu wrote:

> For example, some thing I remember vaguely.  But there are surely many other 
> people here with more rememberings.
>
> If MIP6 doesn't rely on a mechanism to auto-configure an address, and works 
> independently of it - then some people could plug AAA with MIP6, others could 
> plug SLAAC with it.  Or similar.
>
> So, if one would go along same lines, one wouldn't build AAA into MIP6 for 
> delivering the home prefix to the MR.
>

Thanks Alex for the info. In such configurations of physical home
link and when the MN can use SLAAC to configure an address and with
little involvement of MIP6, keeping an external entity out of this,
would probably make sense. Would that be the same when the links
are virtual and when the address is a prefix, the assignment is always
from the HA and how it obtains that info, can be through multiple
ways, including DHCP-PD and AAA for cases of static HNP in a user
profile. All though, DHCP-PD makes lot of sense for prefix/address
mgmt, but the ability to bootstrap just from a profile with static
address might be required.

> A related question: when a PDA router connects to a IPv6 infrastructure, and 
> obtains a prefix with Diameter, or ppp, from the AAA infrastructure - would 
> it _have_ to run NEMO-extended-MIP6?  Maybe not.
>

No, in such case the prefix is anchored on that PDA.

Sri

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 26 Nov 2007 16:17:44 -0800

Romain KUNTZ wrote:
> Yes that point was raised in one of the original mail that started this 
> discussion.
> In the split case, the Mobility Service Authorizer is separated from the 
> Mobility Service Provider. It relies on a backend AAA architecture where 
> the HA contacts the MSA to authenticate the MN and authorize the 
> mobility service. When delegating prefixes in the split scenario, the HA 
> would also need to rely on that architecture, e.g. to authorize a prefix 
> that the MR claims. It would thus make sense to build a delegation 
> mechanism partly based on the MIP6 work.
> 
> Different point: I'd also like to add that 
> draft-ietf-nemo-prefix-delegation raises some issue when the MR boots in 
> the home network : how does the MR gets a prefix as long as it does not 
> send BU?

It cannot. We need to take a closer look at booting up in the home link.
There are other issues as well.

Vijay

---

From: "Teco Boot" <[email-masked]>
Date: Tue, 27 Nov 2007 09:38:23 +0100

Hi,

I want to better understand this discussion.

I think we want to define a protocol for getting a prefix to be used for
MNP, correct?
This cannot be provided by stateless configuration, correct? Prefixes are
always managed. ULA are somewhat the exception, I prefer keeping this is
out-of-scope.

So we need some kind of authority, providing prefixes. And MRs request
prefixes. In all configuration databases, state of all leases is maintained.

Now we need a protocol for requesting and delegation prefixes. Maybe we want
some nesting, e.g. a MR may delegate prefixes downwards. For a protocol
point of view, this is not important.

Currently, we have some mechanisms, like DHCP-PD and some AAA protocols for
the same functionality. All protocols shall manage prefixes consistent, e.g.
uniqueness, expiration timers etc.

Now the question is, do current protocols fit requirements for Mobile
Routers requesting prefixes. If not, we can design new protocols or extent
current protocols. I think there should not be any limitation on running
multiple protocols, e.g. a Prefix Delegation Server runs DHCP, DHCP-PD, some
AAA-PD and new PD protocols. Same for MR.

I wanted to make clear there is no separation between DHCP server and other
servers managing prefixes. It is about the protocols being used.

Teco. 

> -----Oorspronkelijk bericht-----
> Van: T.J. Kniveton [mailto:[email-masked]]
> Verzonden: maandag 26 november 2007 22:45
> Aan: Julien Laganier
> CC: [email-masked]
> Onderwerp: Re: [MEXT] Next steps on prefix delegation
>

---

From: "George Tsirtsis" <[email-masked]>
Date: Tue, 27 Nov 2007 10:20:46 +0000

I agree with Sri here,

If someone thinks that this issue is done and dusted then he can
summarize the strong technical points against use of AAA for address
allocation.

>From my side, I feel that the whole discussion is a bit pointless and
slightly on the wrong track. I say that because AAA servers have been
able to return IPv4/IPv6 addresses and prefixes since forever. Whether
these addresses are then statically part of someones subscription
profile or are dynamically allocated by some pool available to the AAA
server is implementation specific. Obviously this AAA capability can
be linked in the AR/HA/LMA with MIPv6/NEMO/PMIPv6 or whatever other
protocol one requires....this is nothing new either. So, reading
draft-sarikaya-dime-prefix-delegation, I do not really learn anything
I do not already know how to do.

So the question for this group is whether documenting the exact
(albeit obvious) interactions e.g., between AAA and MIPv6/NEMO/PMIP
for PD, is useful or not. If it is useful then, is it also something
the IETF recommends or not?

I generally find such documents only semi-useful and at best IMHO they
can be informational or BCP if we think we really have a specific
recommendation about how multiple protocols should be linked.

My 2 (Canadian) cents
George

---

From: "George Tsirtsis" <[email-masked]>
Date: Tue, 27 Nov 2007 10:44:17 +0000

Hi All,

We may want to remember that Mobile IP and Address allocation has
always been a "chicken and egg" issue. Ideally, we would keep these
two processes entirely separated so that one mechanism is chosen for
address allocation and then another mechanism is used to redirect
traffic to the mobile's current location. In practice, however, this
can only be done if the MN always powers up at home link, in which
case either stateless autoconf or DHCP can be used *before* MIP needs
to be bootstrapped and used.

This breaks down when the MN boots up on a foreign link since our
basic address allocation mechanism only provide local addresses. Now
because mobility in the Internet is an afterthought >sigh< we ended up
with a bunch of different mechanisms with allocating HoAs on foreign
links. These include at least DHCP, IKE and MIP as well as
combinations of them for primary HoA and subsequent/additional address
and prefix allocation.

So DSMIPv6 for example, has the capability to allocate an IPv4 address
or prefix as part of the protocol. I do not see how it makes sense to
prevent the same DSMIPv6 HA to allocate an IPv6 address/prefix as
well. IKEv2 is also being extended to be able to do the same thing.
DHCP-PD can of course also be used on top of either of these, or even
in series with these.

Maybe we can then resign to the fact that multiple mechanisms for this
are a reality and let the market figure out what is useful and when.
Lets just remember not to create yet another way of doing this any
time soon ;-)

Regards
George

---

From: Julien Laganier <[email-masked]>
Date: Tue, 27 Nov 2007 15:27:40 +0100

Hello TJ,

On Monday 26 November 2007, T.J. Kniveton wrote:
> and constructs an address by appending its own suffix, using neighbor

While I agree that the high level goal is the same: assigning an address 
to an interface, there are in facts two distinct goals that 
fundamentally differ in terms of the characteristics of the assigned 
address.

With stateless configuration the address is assigned by the node, while 
in stateful configuration the address is assigned by the network.

This fundamental difference makes it necessary to have two different 
methods, to achieve two different goals.

> Solicitation/Advertisements, bootstrapping, etc. Otherwise, we would
> just rely on a big DHCP brain in the sky to tell the end node all of
> its configuration information. The way I see it, using option #1
> means that we are furthering the Internet protocol capabilities while
> remaining consistent with the long-standing ideal that the
> intelligence lies in end nodes, not in the network.

I am not sure about the assumptions made during development of Mobile IP 
but given the existence of two mode of operations for address 
assignment it seems natural that Mobile IP does not disallow any of 
them. I am not sure either that one mode is kind of better than the 
other. 

I also think this is somewhat orthogonal to the discussion of prefix 
delegation for NEMO, see more below.

> (such as where Vijay pointed out), in the HA.

I do not think the comparison between address assignment and prefix 
delegation is pertinent.

While we agree that there are two ways to assign addresses: stateless 

> using stateless address autoconfiguration, neither one involves the

I do not understand the comparison. 

Delegating prefixes requires the delegating entity to keep state about 
which prefix were delegated to whom. Therefore it is stateful.

> this is too complicated; if you want to do this, you are going to
> need to install a DHCP infrastructure.?

I do not see the antagonism between the two choices -- the mechanism to 
request use of a prefix in NEMO could well be DHCPv6 PD, in which case 
the two choices coincide.

> schemes be implemented yet, so further study, IMHO, is necessary

I agree with you that this WG need to study the question to make a good 
decision.

Note however that in making a decision the WG is certainly not going to 
state anything w.r.t. to deployment of DHCPv6 on "most IPv6 networks". 
Rather, it can decide to base NEMO prefix delegation on DHCPv6 PD, or 
not. That is the only question related to DHCP that we have to answer 
in this WG, AFAICS.

Cheers,

--julien

---

From: Julien Laganier <[email-masked]>
Date: Tue, 27 Nov 2007 15:32:16 +0100

Hello TJ,

On Monday 26 November 2007, T.J. Kniveton wrote:
> If you want to select one prefix delegation mechanism for NEMO, and
> have it fit a situation where a mobile network is away from the home

I am not really sure about what Ryuji message shows ;) At any rate it 
doesn't answer the two questions I've put forth to try to understand 
if/why a single solution isn't doable (What could possibly make the 
existing DHCPv6 PD unsuitable to be used for NEMO PD? In case DHCPv6 is 
suitable but introduces limitations in the context of NEMO that makes 
it desirable to standardize another prefix delegation mechanism for 
NEMO, what would be the limitations?). Please note that these questions 
were not intended to take side with one proposal or the other but 
rather try to gain understanding so that we have a consensus on what is 
the best choice.

Our charter only calls for a single prefix delegation mechanism to be 
published as proposed standard, and I also think that it is a 
reasonable goal. I'd like the WG to agree on specification  on a single 
mechanism. Thus, this note includes a number of questions.

Before we start to discuss about the number of messages incurred by 
prefix delegation maybe it is worth to asnwer the following question:
   
   o Does the WG thinks that keeping the number of messages exchanged
     for prefix delegation when a MR boots in foreign network low is a 
     requirement?

> As I said before, there is a reason that there are two drafts instead
> of one. If you consider this "several ways of doing the same thing"
> as per RFC 1958, then more work will be necessary to create one way
> of doing it that works well.

I think it is fine for the WG to spend more time if it allows 
specification of a single, unified mechanism.

W.r.t. the work needed to make a single mechanism work well, is there's 
an understanding of the missing parts of either of the proposals:

   o What is missing in the nemo-dhcpv6-pd draft to make it work well?

   o What is missing in the nemo-prefix-delegation draft to make it work
     well?

> If, on the other hand, you want to make the assumption that any
> network with NEMO will have DHCP deployed, and you are not concerned
> about bootstrapping a tunnel to the home network to exchange DHCP
> messages, then DHCP is the way to go. 

That would not only be making an assumption, but in fact making DHCPv6 
PD part of the specification for prefix delegation in NEMO. The second 
part of your sentence also bring one question:

    o What are the issues related to bootstrapping a tunnel to the
      home network to exhange DHCP messages?

> But in this case, the minimum effort needed would be to lay out the
> assumptions and have some consensus in the group that this is a
> reasonable engineering compromise.

Seems like a reasonable way to go.

--julien

> > It means it takes several message exchanges between MR and HA to
> > get MNP in bootstrap.
> >
> > Another question is that shall we have a mechanism to assign HoA
> > and prefix at the same time?
> >> questions from my side. I am quoting below one of the
> >> Architectural Principles of the Internet [RFC1958]:
> >>
> >> unless there is a good technical reason not to.  Duplication of
> >> the same protocol functionality should be avoided as far as
> >> possible, without of course using this argument to reject
> >> improvements.
> >>
> >> adopted. Things are not that simple however and it is possible
> >> that very good reasons justify the specification of a new
> >> mechanism for prefix delegation in the context of NEMO.
> >>
> >>      context of NEMO that makes it desirable to standardize
> >> another prefix delegation mechanism for NEMO, what would be the
> >> limitations?
> >>

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 27 Nov 2007 15:26:51 -0800

Hi Hannes,

Here are some pointers to previous discussions. Took me some time
to find this. IETF archives are not designed for searching.

- http://www1.ietf.org/mail-archive/web/mip6/current/msg06023.html

This thread was about DHCP should be used to assign home address
from the NAS (access router). RADIUS/Diameter is used to deliver
the home address from the AAA to the NAS.

- http://www1.ietf.org/mail-archive/web/mip6/current/msg06554.html

This thread talks about AAA or the HA assigning a home address.

- http://www1.ietf.org/mail-archive/web/netlmm/current/msg02515.html

This thread was on the NETLMM mailing list. It was about AAA managing
prefixes for PMIPv6 instead of the LMA and the AAA delivering the
prefixes to the MAG.

There was quite bit of discussion on this during the Prague meeting.
Mostly hallway discussions. Don't have pointers to that. This was
just after the WG last call for draft-ietf-mip6-hiopt.

There might have been more, but can't spend any more time on this.
Sorry. Anyway, AFAIK, we have always concluded that the home agent
or some other entity on the home link (DHCP server) manages the
home addresses and the home prefixes.

George, Sri, you guys had also sent emails asking for pointers.
Patience please. It takes quite a bit of time to search through
the archives.

Vijay

---

From: "T.J. Kniveton" <[email-masked]>
Date: Tue, 27 Nov 2007 16:37:15 -0800

FYI, if it helps in your search.. I have all of the MIP, MIP6, MIP4, 
NEMO, MIPSHOP,.. working group messages archived on my email server for 
a number of years. It also has anonymous IMAP and a webmail interface so 
you can search using your mail client (IMAP/POP) or the web.

If you want to use that just let me know and I'll give you instructions. 
It can make searching significantly faster.

TJ

Vijay Devarapalli wrote:
>> response "I don't have time to give you a tutorial on this QoS issue. 
>> We discussed this at length in face-to-face meeting at the IETF XYZ 
>> meeting."
>>

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 27 Nov 2007 16:39:02 -0800

> It can make searching significantly faster.

That would be awesome. Thanks

Vijay