Subject: [dhcwg] CGAs and DHCP

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 18 Mar 2008 09:49:23 -0700

Hello,

You all have recently written about CGA interactions with DHCP:

http://www.ietf.org/internet-drafts/draft-xia-dhc-host-gen-id-00.txt
http://www.ietf.org/internet-drafts/draft-van-beijnum-cga-dhcp-interacti
on-00.txt

I have been proposing the use of CGAs with DHCP since May 2006
in several of my proposals (the latter of which is still active):

http://www.tools.ietf.org/html/draft-templin-autoconf-netlmm-dhcp-00
http://tools.ietf.org/html/draft-ietf-netlmm-mn-ar-if-01
http://www.ietf.org/internet-drafts/draft-templin-autoconf-dhcp-11.txt

My proposals have all spoken about the client proposing a CGA
*address* to the server, which sends a reply indicating
whether/not the address could be delegated (i.e., the same as
what your proposals seem to be saying). I would now like to
specify a means for delegating a fully-qualified *prefix*
(i.e., a /128) that includes a CGA using RFC3633 DHCP prefix
delegation. I see at least two possible methods for doing this:

1) The client receives an RA that contains a prefix information
option (PIO) with prefix length=64 but with 'L' bit set to 0.
The client uses this prefix to generate a CGA (RFC3972) then
proposes this address to the DHCP server as a /128 prefix in
an IA_PD option using DHCPv6 prefix delegation (RFC3633) with
either 2-message or 4-message exchange. The server will send
a reply indicating whether/not the /128 prefix could be
delegated.

2) The client sends a DHCP SOLICIT (4 message exchange) with an
IA_PD option that asks for a /128 prefix to be delegated. The
server ADVERTISEs a /128 prefix that the client interprets as a
/64 prefix concatenated with a 64-bit interface identifier. The
client discards the interface identifier and uses the /64 prefix
to generate a CGA then proposes this address to the DHCP server
as a /128 prefix in an IA_PD option using 2-message exchange
exactly as in 1) above.

My intention has been to write this up in the next version
of the autoconf-dhcp draft, as an alternate option to the
address delegation proposed in the earlier works. But, I was
wondering if this should be coordinated with anything you all
are doing. For example, perhaps this should be included in a
combined document on CGA interactions with DHCP (citing earlier
works) since it doesn't make sense to say essentially the same
things in multiple places.

Thoughts?

Fred
[email-masked]       
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Frank Xia <[email-masked]>
Date: Tue, 18 Mar 2008 12:35:07 -0600

Hi  Fred

At first, I would like to highlight our main procedure is "
configuring a host's IPv6  address which prefix is allocated 
from a DHCPv6 server while it's   interface identifier is independently 
generated by the host"

Then, please see my inline comments...

BR
Frank

----- Original Message ----- 
From: "Templin, Fred L" <[email-masked]>
To: <[email-masked]>; <[email-masked]>; "Iljitsch van Beijnum" <[email-masked]>
Cc: <[email-masked]>; "Templin, Fred L" <[email-masked]>
Sent: Tuesday, March 18, 2008 10:49 AM
Subject: CGAs and DHCP

Hello,

http://www.ietf.org/internet-drafts/draft-xia-dhc-host-gen-id-00.txt
http://www.ietf.org/internet-drafts/draft-van-beijnum-cga-dhcp-interacti
on-00.txt
Frank=>Thank for your review.

Frank=>Probably I looked it too quickly, so that  I can't find explicit  idea similar to
our contribution.  Anyway, I will take a close look.

1) The client receives an RA that contains a prefix information
option (PIO) with prefix length=64 but with 'L' bit set to 0.
The client uses this prefix to generate a CGA (RFC3972) then
proposes this address to the DHCP server as a /128 prefix in
an IA_PD option using DHCPv6 prefix delegation (RFC3633) with
either 2-message or 4-message exchange. The server will send
a reply indicating whether/not the /128 prefix could be
delegated.
Frank=>The prefix is from AR not from DHCP server, as it is 
different from our draft.

2) The client sends a DHCP SOLICIT (4 message exchange) with an
IA_PD option that asks for a /128 prefix to be delegated. The
server ADVERTISEs a /128 prefix that the client interprets as a
/64 prefix concatenated with a 64-bit interface identifier. The
client discards the interface identifier and uses the /64 prefix
to generate a CGA then proposes this address to the DHCP server
as a /128 prefix in an IA_PD option using 2-message exchange
exactly as in 1) above.
Frank=>Fristly, RFC3633 is applicable only for routers, not for
a host.  Secondly, It is probably simpler that a host request a /64 prefix  from a 
DHCP server.  This  idea is similar to ours.

Frank=>I encourage that you contribute to our draft, and
make this work done in DHC group.

Thoughts?

Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 18 Mar 2008 10:51:22 -0700

Hi Frank, 

>-----Original Message-----
>From: Frank Xia [mailto:[email-masked]] 
>Sent: Tuesday, March 18, 2008 11:35 AM
>To: Templin, Fred L
>Cc: [email-masked]; Templin, Fred L; [email-masked]; 
>Iljitsch van Beijnum
>Subject: Re: CGAs and DHCP
>
>Hi  Fred
>

But if the AR and DHCP server are either co-located or
coordinated, it should be OK.

>a host.

I am talking about (requesting router/delegating router) here;
this is in addition to the (host/server) method for CGA address
delegation that I have already described in earlier works.

>Secondly, It is probably simpler that a host request

I think you mean "router"; not "host".

>a /64 prefix  from a 

Prefix delegation of /64 is fine, but I don't want to waste
an entire /64 for every requesting router, since there may
be many of these and each one may only need 1 or a few CGAs;
not 2^64 of them.   

>make this work done in DHC group.

If there is attribution of earlier work (including any work
other than my own) then this may be possible but would like
to hear from others also.

Thanks - Fred

---

From: Frank Xia <[email-masked]>
Date: Tue, 18 Mar 2008 13:34:26 -0600

Hi Fred

Please check my comments below.

BR
Frank
----- Original Message ----- 
From: "Templin, Fred L" <[email-masked]>
To: "Frank Xia" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; "Iljitsch van Beijnum" <[email-masked]>
Sent: Tuesday, March 18, 2008 11:51 AM
Subject: RE: CGAs and DHCP

Hi Frank, 

But if the AR and DHCP server are either co-located or
coordinated, it should be OK.
Frank=>Sure.  But it not necessary to make things complicated.
IMO, There is two explict ways to acquire  a prefix, that is,
a host gets prefix from AR through RA  message, and a host gets prefix
from DHCP server with DHCP protocol.
I would like to make the scearios clear.

Frank=> I am confused with this process.  In our draft,
we only talke about how a HOST get prefix and fomulates its
CGA  address.   The only two entities are involved, that is,
DHCP client and DHCP server.

Anything beyond these is out of  the scope.

Prefix delegation of /64 is fine, but I don't want to waste
an entire /64 for every requesting router, since there may
be many of these and each one may only need 1 or a few CGAs;
not 2^64 of them.   
Frank=>Point-to-point link model is widley adopted in WiMAX
3GPP.  There are enough addresses.
IPv6 address is not strained resource :-)

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 18 Mar 2008 11:53:44 -0700

Hi Frank, 

>Sent: Tuesday, March 18, 2008 12:34 PM
>To: Templin, Fred L
>Cc: [email-masked]; [email-masked]; Iljitsch van Beijnum

When you say "AR", maybe you are targeting a narrower
domain of applicability than the document title implies?
Is this only about the 3GPP, WIMAX, etc. uses?

>DHCP client and DHCP server.

Right; the DHCP client is a requesting router from the
standpoint of the prefix delegation but a host from the
standpoint of the prefix usage. I.e., the requesting
router assigns the prefix to an interface over which
it acts as a host. 

>Anything beyond these is out of  the scope.

Maybe the scope of your document needs to be narrowed,
to talk about only the WIMAX, 3GPP, etc. Or, maybe it
needs to be broadened to talk about the more general
subject of a client (router or host) self-generating an
interface ID and registering it with the DHCP server in
any domain of application. If the former, then maybe
this needs to be taken to a different wg; if the latter,
then maybe it is of more general interest to the DHCP wg.
 
>3GPP.

Again, I think you need to decide whether to constrain
to specific use cases (in which case the title needs to
say so explicitly and an applicability statement added),
or whether to address the general use of self-generated
interface IDs for any domain of applicability. Again,
IMHO the latter may be appropriate for the DHCP wg but
perhaps not the former.

> There are enough addresses.

Sure, the requesting router could just get an entire /64
and go from there w/o bothering the delegating router.
But, the use I am interested in satisfying could entail
quite a large number of requesting routers - all wanting
just one or a few CGAs.

Fred

---

From: Frank Xia <[email-masked]>
Date: Wed, 19 Mar 2008 07:12:48 +0800

Hi Fred

I copy your comments for your convenience.

My point is that we should have a clear scope for the problem.
I think our draft's scope is very specific, as it introduces
prefix assginment and interface identifer separation mechanism to the 
DHC.

"Right; the DHCP client is a requesting router from the
standpoint of the prefix delegation but a host from the
standpoint of the prefix usage. I.e., the requesting
router assigns the prefix to an interface over which
it acts as a host. "
Frank=>it is different from our draft scope.

"Maybe the scope of your document needs to be narrowed,
to talk about only the WIMAX, 3GPP, etc. Or, maybe it
needs to be broadened to talk about the more general
subject of a client (router or host) self-generating an
interface ID and registering it with the DHCP server in
any domain of application. If the former, then maybe
this needs to be taken to a different wg; if the latter,
then maybe it is of more general interest to the DHCP wg."
Frank=>I would like DHC group to have a general procedure
to accomodate the general issue.

BR
Frank

----- Original Message ----- 
From: "Templin, Fred L" <[email-masked]>
To: "Frank Xia" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; "Iljitsch van Beijnum" <[email-masked]>
Sent: Wednesday, March 19, 2008 2:53 AM
Subject: RE: CGAs and DHCP

Hi Frank, 

 

Fred

---

From: Sheng Jiang <[email-masked]>
Date: Wed, 19 Mar 2008 10:24:36 +0800

Hi, Fred,

We are doing the analysis of different approaches to allow SeND and CGAs to be used
in conjunction with DHCP under CSI WG charter
(http://www.ietf.org/html.charters/csi-charter.html). There are two current active
drafts, which have a lot overlap each other. They include a lots contents. What you
have mentioned are also included through we don't go that much design detail as you
do since our intention is a analysis document only. The recommendation for solutions
or extension design may come later as another individual document. 

http://www.ietf.org/internet-drafts/draft-jiang-sendcgaext-cga-config-01.txt
http://www.ietf.org/internet-drafts/draft-van-beijnum-cga-dhcp-interaction-00.txt

Best regards,

Sheng JIANG, Ph.D.

IP Research Department, Networking Research Department, Network Product Line, Huawei
Technologies Co. Ltd.

*-----Original Message-----
*From: [email-masked] [mailto:[email-masked]] 
*On Behalf Of Templin, Fred L
*Sent: Wednesday, March 19, 2008 12:49 AM
*To: [email-masked]; [email-masked]; Iljitsch van Beijnum
*Cc: [email-masked]; Templin, Fred L
*Subject: [dhcwg] CGAs and DHCP
*
*Hello,
*
*You all have recently written about CGA interactions with DHCP:
*
*http://www.ietf.org/internet-drafts/draft-xia-dhc-host-gen-id-00.txt
*http://www.ietf.org/internet-drafts/draft-van-beijnum-cga-dhcp-
*interacti
*on-00.txt
*
*I have been proposing the use of CGAs with DHCP since May 2006 
*in several of my proposals (the latter of which is still active):
*
*http://www.tools.ietf.org/html/draft-templin-autoconf-netlmm-dhcp-00
*http://tools.ietf.org/html/draft-ietf-netlmm-mn-ar-if-01
*http://www.ietf.org/internet-drafts/draft-templin-autoconf-dhcp-11.txt
*
*My proposals have all spoken about the client proposing a CGA
**address* to the server, which sends a reply indicating 
*whether/not the address could be delegated (i.e., the same as 
*what your proposals seem to be saying). I would now like to 
*specify a means for delegating a fully-qualified *prefix* 
*(i.e., a /128) that includes a CGA using RFC3633 DHCP prefix 
*delegation. I see at least two possible methods for doing this:
*
*1) The client receives an RA that contains a prefix 
*information option (PIO) with prefix length=64 but with 'L' 
*bit set to 0.
*The client uses this prefix to generate a CGA (RFC3972) then 
*proposes this address to the DHCP server as a /128 prefix in 
*an IA_PD option using DHCPv6 prefix delegation (RFC3633) with 
*either 2-message or 4-message exchange. The server will send a 
*reply indicating whether/not the /128 prefix could be delegated.
*
*2) The client sends a DHCP SOLICIT (4 message exchange) with 
*an IA_PD option that asks for a /128 prefix to be delegated. 
*The server ADVERTISEs a /128 prefix that the client interprets as a
*/64 prefix concatenated with a 64-bit interface identifier. 
*The client discards the interface identifier and uses the /64 
*prefix to generate a CGA then proposes this address to the 
*DHCP server as a /128 prefix in an IA_PD option using 
*2-message exchange exactly as in 1) above.
*
*My intention has been to write this up in the next version of 
*the autoconf-dhcp draft, as an alternate option to the address 
*delegation proposed in the earlier works. But, I was wondering 
*if this should be coordinated with anything you all are doing. 
*For example, perhaps this should be included in a combined 
*document on CGA interactions with DHCP (citing earlier
*works) since it doesn't make sense to say essentially the same 
*things in multiple places.
*
*Thoughts?
*
*Fred
[email-masked]       
*_______________________________________________
*dhcwg mailing list
[email-masked]
*https://www.ietf.org/mailman/listinfo/dhcwg
*