Subject: Re: [MEXT] Re: [nemo] I-D Action:draft-ietf-nemo-dhcpv6-pd-03.txt

From: Ralph Droms <[email-masked]>
Date: Thu, 6 Dec 2007 22:09:18 -0500

Unless someone knows of specific revisions that should be made now,  
I'll republish as draft-droms-mext-dhcpv6-pd--00 Mon, 12/10.

- Ralph

On Dec 6, 2007, at Dec 6, 2007,10:04 PM, [email-masked]  
wrote:

>
> Ralph,
>
> > BTW, I'm not sure of the process around this specific case of WG
> > reorg; should I rebpulish as ietf-mext-...-00, droms- 
> mext-...-00, ???
>
> Since we are only chartered to produce one solution for prefix  
> delegation and we didn't yet reached consensus on the choice of a  
> solution (e.g. DHCP, NEMO extensions) I'd rather have you submit  
> this draft as draft-droms-mext-*-00.
>
> --julien
>
>
> Créez votre adresse électronique [email-masked]
> 1 Go d'espace de stockage, anti-spam et anti-virus intégrés.

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

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 6 Dec 2007 19:12:15 -0800

Ralph,

Maybe have a look at 'draft-templin-autoconf-dhcp-10.txt'
and see if there is anything in there relating to prefix
delegation you can use. (I still need to read draft-droms,
so forgive me for not being able to point out specifics
at this moment.)

Thanks - Fred
[email-masked]

> -----Original Message-----
> From: Ralph Droms [mailto:[email-masked]] 
> Sent: Thursday, December 06, 2007 7:09 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [MEXT] Re: [nemo] I-D 
> Action:draft-ietf-nemo-dhcpv6-pd-03.txt
>

---

From: [email-masked]
Date: Fri, 7 Dec 2007 04:04:58 +0100 (CET)

Ralph,

> reorg; should I rebpulish as ietf-mext-...-00, droms-mext-...-00, ???

Since we are only chartered to produce one solution for prefix delegation and we didn't yet reached consensus on the choice of a solution (e.g. DHCP, NEMO extensions) I'd rather have you submit this draft as draft-droms-mext-*-00.

--julien

---

From: "Teco Boot" <[email-masked]>
Date: Fri, 7 Dec 2007 18:03:28 +0100

On solution space, why not evaluate running a DHCP server on the MR?
Pro:
- less overhead on MRHA tunnel
- no dependency on MRHA tunnel
Contra:
- needs delegation of prefixes and options, this requires an extension on
DHCPv6PD

We could ask HDC WG to improve DHCP-PD for autoconfigure "slave" DHCP
servers. This would be useful in the Autoconf space also. And maybe in many
other cases.

Teco.

> -----Oorspronkelijk bericht-----
> Van: Templin, Fred L [mailto:[email-masked]]
> Verzonden: vrijdag 7 december 2007 4:12
> Aan: Ralph Droms; [email-masked]
> CC: [email-masked]
> Onderwerp: RE: [MEXT] Re: [nemo] I-D Action:draft-ietf-nemo-dhcpv6-pd-
> 03.txt
> 
> Ralph,
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 7 Dec 2007 09:08:47 -0800

Teco,

Sure, the MR could run DHCP server over its ingress
interfaces, but then turn around and act as a DHCP
client on its egress interfaces and/or tunnel back
to the home network. I'm pretty sure that sort of
arrangement is an anticipated deployment model?

Fred

> From: Teco Boot [mailto:[email-masked]] 
> Sent: Friday, December 07, 2007 9:03 AM
> To: Templin, Fred L; 'Ralph Droms'; [email-masked]
> Cc: [email-masked]
> Subject: RE: [MEXT] Re: [nemo] I-D

---

From: Francis Dupont <[email-masked]>
Date: Fri, 07 Dec 2007 18:31:48 +0100

In your previous mail you wrote:

=> to serve which nodes? And don't forget the DHCP service is designed
to be local, i.e., there is no tree of servers or things like that.

[email-masked]

---

From: "Teco Boot" <[email-masked]>
Date: Fri, 7 Dec 2007 18:57:25 +0100

> Van: [email-masked] [mailto:[email-masked]]
> Verzonden: vrijdag 7 december 2007 18:32
> Aan: Teco Boot
> CC: 'Templin, Fred L'; 'Ralph Droms'; [email-masked];
> [email-masked]
> Onderwerp: Re: [MEXT] Re: [nemo] I-D Action:draft-ietf-nemo-dhcpv6-pd-
> 03.txt
> 
> => to serve which nodes? 

To serve LFN.

> And don't forget the DHCP service is designed

Yes, but with DHCPv6PD we extend this. 
With prefix delegation, the MR supports LFN SLAAC. 
The question is how to support DHCP on Mobile Network. Using relay or
running DHCP on MR. For the latter, we have a tree of servers and we have to
solve the DHCP configuration problem.

Teco.

---

From: Francis Dupont <[email-masked]>
Date: Fri, 07 Dec 2007 19:20:21 +0100

To serve LFN.
   
=> this has nothing to do with NEMO (the M in MR) but with how a router
(the R in MR) manages locally its (sub)network(s).

=> I disagree and I strongly object to change DHCPv6 into a network
management tool: DHCPv6-PD delegates a prefix to a router and this router
can do what it wants with the prefix.

=> it should not, this is the meaning of "across an administrative
boundary".

   running DHCP on MR.

=> the whole idea about prefix delegation is delegation (cf RFC 3769)
so IMHO the solution is to run DHCP on the MR

   For the latter, we have a tree of servers and we have to
   solve the DHCP configuration problem.
   
=> so in fact the question is how the NEMO could not fit into the
RFC 3769 / RFC 3633 model and if yes how the DHCPv6-PD has to be
re-designed to support the needed extra features.

Regards

PS: RFC 3633 quote to start with:

   This mechanism is intended for delegating a long-
   lived prefix from a delegating router to a requesting router, across
   an administrative boundary, where the delegating router does not
   require knowledge about the topology of the links in the network to
   which the prefixes will be assigned.

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 07 Dec 2007 11:45:17 -0800

> re-designed to support the needed extra features.

Important is the sequence of operations.  One constraint is that a MR 
can't send BU-MNP before having received that MNP, and before having the 
HA address.

Other constraint is in implementations of NEMO explicit mode how to make 
sure the prefix received from DHCP is put in the explicit BU (somebody 
already raised this).

Alex

>    which the prefixes will be assigned.

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