Subject: [nemo] I-D ACTION:draft-ietf-nemo-dhcpv6-pd-01.txt

From: [email-masked]
Date: Thu, 02 Mar 2006 15:50:02 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Mobility Working Group of the IETF.

	Title		: DHCPv6 Prefix Delegation for NEMO
	Author(s)	: R. Droms, P. Thubert
	Filename	: draft-ietf-nemo-dhcpv6-pd-01.txt
	Pages		: 11
	Date		: 2006-3-2
	
One aspect of network mobility support is the assignment of a prefix
   or prefixes to a Mobile Router (MR) for use on the links in the
   Mobile Network.  DHCPv6 prefix delegation can be used for this
   configuration task.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-nemo-dhcpv6-pd-01.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-nemo-dhcpv6-pd-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-nemo-dhcpv6-pd-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Vijay Devarapallli" <[email-masked]>
Date: Fri, 3 Mar 2006 11:38:10 -0800

hi,

the draft looks good. I think its ready for a WG
last call.

however, I noticed that a whole new section on
extending dynamic home agent address
discovery has been included. I wonder if this
necessary. we are adding a lot of new features
to MIPv6 and NEMO. I dont think we should be
extending DHAAD every time we define a new
feature/extension. and there has also been a
talk about deprecating DHAAD (I disagree with
deprecating DHAAD). there is also a lot of work
going on in the MIP6 WG on bootstrapping a
mobile node. this includes configuring the right
home agent for the right mobile node.

section 3.5 by itself is fine with me.

section

Vijay

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 09 Mar 2006 17:03:33 +0100

Vijay Devarapallli wrote:
> [...] and there has also been a talk about deprecating DHAAD (I
> disagree with deprecating DHAAD).

I disagree too with deprecating DHAAD.

I think there is one draft dhaad-harmful.

But there is draft-arkko-mip6-3775bis-ndmobext-00 which clearly mentions
the HA list and it being maintained by DHAAD.

There is at least one implementation of non-anycast DHAAD which works 
just fine (although not yet secure).

Alex

---

From: Francis Dupont <[email-masked]>
Date: Fri, 10 Mar 2006 19:09:48 +0100

> disagree with deprecating DHAAD).
   
=> it seems it was a good idea to change the subject (:-)

=> there are two basic issues with DHAAD:
 - the needed function is more HA assignment than HA discovery.
 - the current anycast DHAAD mechanism can't be made secure.
Please note the current DHAAD is optional.

=> yes, I am its editor. The proposal is to switch to the DNS SRV RR
from the bootstrapping DT. BTW I believe it is useful to work on
all kinds of HA switching mechanisms too.

=> is your argument about the function or about the mechanism?

=> this comment suggests the function.

Regards
   
[email-masked]

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 16 Mar 2006 18:48:36 +0100

>  - the needed function is more HA assignment than HA discovery.

I don't see the difference (?).

> Please note the current DHAAD is optional.

And if the "anycast" part is removed from the DHAAD mechanism 
altoghether then it would become more securisable, I believe.

> all kinds of HA switching mechanisms too.

This may bind an IP discovery mechanism to the existence of above IP 
(DNS) data presence.  It seems unreal for the IP discovery mechanism to 
need level-7 data be present.  In a similar mechanism which is DHCP, 
discovery works ok without DNS data being present, and the DNS data can 
be updated by DHCP after it has finished its discovery phase.

> => is your argument about the function or about the mechanism?

I am not sure I understand the difference between "function" and 
"mechanism" in this context.

> => this comment suggests the function.

I suggest that there is at least one implementation with rfc3775 DHAAD 
messaging (RAs and DHAAD) that works just fine.  It's true that it uses 
"anycast"-format addresses.  But these addresses get no special 
"anycast" treatment by the stack.  It's just that the dedicated 
"anycast" address is assigned to several same-link HAs and all the HAs 
receive the DHAAD Request.  However, only one HA replies back.

Alex

---

From: Francis Dupont <[email-masked]>
Date: Fri, 17 Mar 2006 23:39:42 +0100

=> the difference lays about where is the controlling side and
how the control is performed.

   
=> the anycast phase can't be made secure but:
 - the first phase can't be made secure with or without anycast when
  there is no pre-existent security association.
 - the final result is always secure (when IPsec is correctly used
  of course), i.e., it is not possible to accept a fake HA.

=> do you propose to use the DHCP way of service discovery in a global
scale (:-)?

   
=> function: what it is, mechanism: how the function is provided.

regards

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 20 Mar 2006 03:56:12 +0100

> how the control is performed.

Both behaviours exist somehow in MIP6.  The MN-initiated behaviour is 
when MN sends DHAAD Request, or MPD Solicitation or BU.  The 
HA-initiated behaviour is when HA sends BRR (Binding Refresh Request) to 
MN.  For this HA-initiated behaviour the HA could use extensions of BRR 
or BRR-like new messages ("HA trigger"?) to request MN to perform DHAAD.

>   there is no pre-existent security association.

Agree partially.  What we call the "first" phase (the real first 
discovery message) _can_ be made relatively secure if anycast is not 
used and if pre-shared secrets exist.

It's also true that one can't claim to make discovery secure without any 
pre-shared secrets _or_ without any form of public keys plus security 
infrastructure everywhere.

>   of course), i.e., it is not possible to accept a fake HA.

Sounds like a valid secure bootstrapping requirement.

> => do you propose to use the DHCP way of service discovery in a global

Yes it could, in the same way that MIP6 is a "global" mobility protocol 
and in the same way that MPD is a ND that runs "globally" over the 
network (instead of on a link).

DHCP over the MN-HA tunnel has been suggested by several drafts, at 
least one in NEMO

> => function: what it is, mechanism: how the function is provided.

Ok, I see.  The function is discovery of HA and the mechanism could be a 
modified DHAAD.

Alex

---

From: Francis Dupont <[email-masked]>
Date: Mon, 20 Mar 2006 17:49:13 +0100

=> for the second HA-switch is the proper solution. But HA-switch doesn't
work before the home registration... so HA-assignment is not a subcase
of HA-reassignment.

   
=> pre-shared secrets == pre-existent SA.

=> we don't use the same words but I believe we agree.

   
=> I am strongly against this because of the global multicast.

=> DHCP over the tunnel is another thing. I agree it will be necessary
one day (and perhaps pretty soon) but of course it doesn't work in
first phases of bootstrapping (i.e., when the tunnel not yet exists).

Regards