Dynamic Host Configuration (dhc)

headers sudurais a | 1 Jul 2011 17:01

_______________________________________________
dhcwg mailing list
dhcwg <at> ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg

Sudurais,

> Thanks. I meant, Solicit packet. 
> 
> Why such a restriction imposed ?. 

the proposed 'solution' to that problem is to use a local relay (same node as the client).
http://tools.ietf.org/html/draft-guo-softwire-6rd-ipv6-config-02

cheers,
Ole

> On Thu, Jun 30, 2011 at 8:50 AM, Ted Lemon <Ted.Lemon <at> nominum.com> wrote:
> On Jun 27, 2011, at 7:29 PM, sudurais a wrote:
>> If DHCPv6 client does unicast DISCOVER packet to server and uses unicast for all of its communication
with server, will it be a problem in server side ?. Is server mandates client should be sending packets with
bcast/mcast address as destination address in DHCP discover or request packets ?.
> 
> The server is expected to ignore any such packets.   I presume that you mean "Solicit," not "DISCOVER,"
since there is no "DISCOVER" packet in DHCPv6.
> 
> 
> _______________________________________________
> dhcwg mailing list
> dhcwg <at> ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg

Hi, all,

A new draft draft-jiang-dhc-addr-registration-01 has been submitted to DHC WG. This document follows
the WG consensus on the requirement of address registration
(draft-jiang-6man-addr-registration-req). The requirement part from is document of
draft-jiang-6man-addr-registration-req has been integrated into this new draft.

Any comments are welcome!

Best regards,

Sheng

> -----Original Message-----
> From: internet-drafts <at> ietf.org [mailto:internet-drafts <at> ietf.org]
> Sent: Monday, July 04, 2011 4:24 PM
> To: Jiangsheng
> Cc: phdgang <at> gmail.com; Jiangsheng
> Subject: New Version Notification for draft-jiang-dhc-addr-
> registration-01.txt
> 
> A new version of I-D, draft-jiang-dhc-addr-registration-01.txt has been
> successfully submitted by Sheng Jiang and posted to the IETF repository.
> 
> Filename:	 draft-jiang-dhc-addr-registration
> Revision:	 01
> Title:		 A Generic IPv6 Addresses Registration Solution Using
> DHCPv6
> Creation date:	 2011-07-01
> WG ID:		 Individual Submission
> Number of pages: 11
> 
> Abstract:
>    In the IPv6 address allocation scenarios, host self-generated
>    addresses are notionally conflicted with the network managed address
>    architecture. These addresses need to be registered in the
> networking
>    management plate for the purposes of central address administration.
>    This document introduces a generic address registration solution
>    using DHCPv6, and defines one new ND option and three new DHCPv6
>    options.
> 
> 
> 
> 
> The IETF Secretariat

_______________________________________________
dhcwg mailing list
dhcwg <at> ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg

Hi:

Without judging whether I think this is a good or bad idea, I will point
out that one (IMHO) major flaw is that there is no "lifetime" associated
with these registrations. Do they last for a day or forever?

Without this, there is no way to reclaim an address or know when it is
stopped being needed (because no re-registration occurs). Over time
without this, the DHCPv6 server would have to remember more and more
addresses and hence fill its database (both on disk and in memory) with
more and more addresses.

This does mean that the client would have to periodically re-register
the address.

And, then that begs the question as to whether this is worth it -- why
not just use DHCPv6 in the first place? Many servers allow the client to
hint at the address (and if not in use and assuming server policy allows
the hint to be used), that address is "leased" to the client.

Investing in updating hosts to implement this work could likely be
better spent in implementing DHCPv6?

Also, RFC 4862 addresses are ones that the DHCPv6 server can easily be
programmed to avoid - as they are EUI-64 based and therefore have the
universal/local bit set to indicate that these are universal addresses
(a DHCPv6 server really shouldn't be generating addresses with the
universal bit set -- except it is attempting to mimic stateless
assignments). That's also why RFC 4941 clearly states:

   3.  Take the leftmost 64-bits of the MD5 digest and set bit 6 (the
       leftmost bit is numbered 0) to zero.  This creates an interface
       identifier with the universal/local bit indicating local
       significance only.

And, RFC 4941 generated addresses could "conflict" with other RFC 4941
generated addresses (by a different client) and DAD can be used to
handle these cases -- a new address is then generated.

So, that really only leaves CGA addresses as a "problem space"? I don't
know/recall enough about whether these could or are already handled in
other ways, but they have to co-exist with RFC 4941 addresses too (for
example in cases where the techniques proposed in this draft are not
available).

- Bernie

-----Original Message-----
From: dhcwg-bounces <at> ietf.org [mailto:dhcwg-bounces <at> ietf.org] On Behalf
Of Jiangsheng
Sent: Tuesday, July 05, 2011 3:41 AM
To: dhcwg <at> ietf.org WG
Subject: [dhcwg] FW: New Version Notification for
draft-jiang-dhc-addr-registration-01.txt

Hi, all,

A new draft draft-jiang-dhc-addr-registration-01 has been submitted to
DHC WG. This document follows the WG consensus on the requirement of
address registration (draft-jiang-6man-addr-registration-req). The
requirement part from is document of
draft-jiang-6man-addr-registration-req has been integrated into this new
draft.

Any comments are welcome!

Best regards,

Sheng

> -----Original Message-----
> From: internet-drafts <at> ietf.org [mailto:internet-drafts <at> ietf.org]
> Sent: Monday, July 04, 2011 4:24 PM
> To: Jiangsheng
> Cc: phdgang <at> gmail.com; Jiangsheng
> Subject: New Version Notification for draft-jiang-dhc-addr-
> registration-01.txt
> 
> A new version of I-D, draft-jiang-dhc-addr-registration-01.txt has
been
> successfully submitted by Sheng Jiang and posted to the IETF
repository.
> 
> Filename:	 draft-jiang-dhc-addr-registration
> Revision:	 01
> Title:		 A Generic IPv6 Addresses Registration Solution
Using
> DHCPv6
> Creation date:	 2011-07-01
> WG ID:		 Individual Submission
> Number of pages: 11
> 
> Abstract:
>    In the IPv6 address allocation scenarios, host self-generated
>    addresses are notionally conflicted with the network managed
address
>    architecture. These addresses need to be registered in the
> networking
>    management plate for the purposes of central address
administration.
>    This document introduces a generic address registration solution
>    using DHCPv6, and defines one new ND option and three new DHCPv6
>    options.
> 
> 
> 
> 
> The IETF Secretariat
_______________________________________________
dhcwg mailing list
dhcwg <at> ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg

On Jul 5, 2011, at 11:16 PM, Bernie Volz (volz) wrote:
> And, then that begs the question as to whether this is worth it -- why
> not just use DHCPv6 in the first place? Many servers allow the client to
> hint at the address (and if not in use and assuming server policy allows
> the hint to be used), that address is "leased" to the client.

The point is for hosts to be able to generate their own addresses, e.g. for CGA.   So the DHCP server can't
originate the address.   All your other points are valid, though.

Hi, Bernie,

Thanks for your valuable comments. See my replies in lines.

> Without judging whether I think this is a good or bad idea, I will
> point
> out that one (IMHO) major flaw is that there is no "lifetime"
> associated
> with these registrations. Do they last for a day or forever?

This is a good catch. But the reason is we don't know who should decide the lifetime. The hosts would always
say as long as possible, like forever. This does not help. That's why we do not have lifetime in the request
option. The server expires old address periodly could be a choice, but have other issues, like you
mentioned below. The authors would like to widely ask opinion from the WG.

> Without this, there is no way to reclaim an address or know when it is
> stopped being needed (because no re-registration occurs). Over time
> without this, the DHCPv6 server would have to remember more and more
> addresses and hence fill its database (both on disk and in memory) with
> more and more addresses.
> 
> This does mean that the client would have to periodically re-register
> the address.
> 
> And, then that begs the question as to whether this is worth it -- why
> not just use DHCPv6 in the first place? Many servers allow the client
> to
> hint at the address (and if not in use and assuming server policy
> allows
> the hint to be used), that address is "leased" to the client.

I don't want to discuss this question (whether host generated address should exist or only DHCP-assigned
address) too much. This discuss is endless, we know. And the fact is there are many host generated
addresses exist. This fact is the foundation of our requirement of address registration.

> Investing in updating hosts to implement this work could likely be
> better spent in implementing DHCPv6? 
> 
> Also, RFC 4862 addresses are ones that the DHCPv6 server can easily be
> programmed to avoid - as they are EUI-64 based and therefore have the
> universal/local bit set to indicate that these are universal addresses
> (a DHCPv6 server really shouldn't be generating addresses with the
> universal bit set -- except it is attempting to mimic stateless
> assignments). That's also why RFC 4941 clearly states:
> 
>    3.  Take the leftmost 64-bits of the MD5 digest and set bit 6 (the
>        leftmost bit is numbered 0) to zero.  This creates an interface
>        identifier with the universal/local bit indicating local
>        significance only.
> 
> And, RFC 4941 generated addresses could "conflict" with other RFC 4941
> generated addresses (by a different client) and DAD can be used to
> handle these cases -- a new address is then generated.
> 
> So, that really only leaves CGA addresses as a "problem space"? I don't
> know/recall enough about whether these could or are already handled in
> other ways, but they have to co-exist with RFC 4941 addresses too (for
> example in cases where the techniques proposed in this draft are not
> available).

All you above points are right. But the registration is not only to avoid address duplication.

Regards,

Sheng

> - Bernie
> 
> -----Original Message-----
> From: dhcwg-bounces <at> ietf.org [mailto:dhcwg-bounces <at> ietf.org] On Behalf
> Of Jiangsheng
> Sent: Tuesday, July 05, 2011 3:41 AM
> To: dhcwg <at> ietf.org WG
> Subject: [dhcwg] FW: New Version Notification for
> draft-jiang-dhc-addr-registration-01.txt
> 
> Hi, all,
> 
> A new draft draft-jiang-dhc-addr-registration-01 has been submitted to
> DHC WG. This document follows the WG consensus on the requirement of
> address registration (draft-jiang-6man-addr-registration-req). The
> requirement part from is document of
> draft-jiang-6man-addr-registration-req has been integrated into this
> new
> draft.
> 
> Any comments are welcome!
> 
> Best regards,
> 
> Sheng
> 
> > -----Original Message-----
> > From: internet-drafts <at> ietf.org [mailto:internet-drafts <at> ietf.org]
> > Sent: Monday, July 04, 2011 4:24 PM
> > To: Jiangsheng
> > Cc: phdgang <at> gmail.com; Jiangsheng
> > Subject: New Version Notification for draft-jiang-dhc-addr-
> > registration-01.txt
> >
> > A new version of I-D, draft-jiang-dhc-addr-registration-01.txt has
> been
> > successfully submitted by Sheng Jiang and posted to the IETF
> repository.
> >
> > Filename:	 draft-jiang-dhc-addr-registration
> > Revision:	 01
> > Title:		 A Generic IPv6 Addresses Registration Solution
> Using
> > DHCPv6
> > Creation date:	 2011-07-01
> > WG ID:		 Individual Submission
> > Number of pages: 11
> >
> > Abstract:
> >    In the IPv6 address allocation scenarios, host self-generated
> >    addresses are notionally conflicted with the network managed
> address
> >    architecture. These addresses need to be registered in the
> > networking
> >    management plate for the purposes of central address
> administration.
> >    This document introduces a generic address registration solution
> >    using DHCPv6, and defines one new ND option and three new DHCPv6
> >    options.
> >
> >
> >
> >
> > The IETF Secretariat
> _______________________________________________
> dhcwg mailing list
> dhcwg <at> ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg

On Jul 5, 2011, at 11:51 PM, Jiangsheng wrote:
> This is a good catch. But the reason is we don't know who should decide the lifetime. The hosts would always
say as long as possible, like forever. This does not help. That's why we do not have lifetime in the request
option. The server expires old address periodly could be a choice, but have other issues, like you
mentioned below. The authors would like to widely ask opinion from the WG.

Would it work to have a way to tell the DHCP server "I want this address, and if I can't have it, I want to
generate a new address" but then follow the regular DHCPv6 address maintenance strategy, where the
server assigns the lifetime and manages renewal?   Since we already have the DHCP infrastructure in place,
this seems like it would solve Bernie's problem nicely.   This could basically wind up just being an
additional option in the IA_NA suboption of a regular Solicit/Confirm/Renew message.

> On Jul 5, 2011, at 11:51 PM, Jiangsheng wrote:
> > This is a good catch. But the reason is we don't know who should
> decide the lifetime. The hosts would always say as long as possible,
> like forever. This does not help. That's why we do not have lifetime in
> the request option. The server expires old address periodly could be a
> choice, but have other issues, like you mentioned below. The authors
> would like to widely ask opinion from the WG.
> 
> Would it work to have a way to tell the DHCP server "I want this
> address, and if I can't have it, I want to generate a new address" but
> then follow the regular DHCPv6 address maintenance strategy, where the
> server assigns the lifetime and manages renewal?   Since we already
> have the DHCP infrastructure in place, this seems like it would solve
> Bernie's problem nicely.   This could basically wind up just being an
> additional option in the IA_NA suboption of a regular
> Solicit/Confirm/Renew message.

This sounds a feasible solution for me. 

However, there is a concept issue. The lifetime will be only for the registration entity, not the address.
This is different from the current lifetime in IA_NA. Also, we need extra suboption for the refusing scenario.

Sheng

Sheng, I don't understand your comment. Ted's idea is that the client
does DHCPv6 - just that the client selects the addresses, not the
server. The client would need to enforce the lifetimes as it does for
normal leases - and renew as necessary. So, there is no difference in
the meaning of the lifetimes. The client is not free to use the address
"forever" (unless the server provides it an infinite lifetime).

- Bernie

-----Original Message-----
From: Jiangsheng [mailto:jiangsheng <at> huawei.com] 
Sent: Wednesday, July 06, 2011 2:05 AM
To: Ted Lemon
Cc: Bernie Volz (volz); dhcwg <at> ietf.org
Subject: RE: [dhcwg] New Version Notification for
draft-jiang-dhc-addr-registration-01.txt

> On Jul 5, 2011, at 11:51 PM, Jiangsheng wrote:
> > This is a good catch. But the reason is we don't know who should
> decide the lifetime. The hosts would always say as long as possible,
> like forever. This does not help. That's why we do not have lifetime
in
> the request option. The server expires old address periodly could be a
> choice, but have other issues, like you mentioned below. The authors
> would like to widely ask opinion from the WG.
> 
> Would it work to have a way to tell the DHCP server "I want this
> address, and if I can't have it, I want to generate a new address" but
> then follow the regular DHCPv6 address maintenance strategy, where the
> server assigns the lifetime and manages renewal?   Since we already
> have the DHCP infrastructure in place, this seems like it would solve
> Bernie's problem nicely.   This could basically wind up just being an
> additional option in the IA_NA suboption of a regular
> Solicit/Confirm/Renew message.

This sounds a feasible solution for me. 

However, there is a concept issue. The lifetime will be only for the
registration entity, not the address. This is different from the current
lifetime in IA_NA. Also, we need extra suboption for the refusing
scenario.

Sheng

Mon	Tue	Wed	Thu	Fri	Sat	Sun

				1	2	3
4	5	6	7	8	9	10
11	12	13	14	15	16	17
18	19	20	21	22	23	24
25	26	27	28	29	30	31

77	May 2013
207	April 2013
148	March 2013
120	February 2013
39	January 2013
116	December 2012
146	November 2012
147	October 2012
190	September 2012
157	August 2012
101	July 2012
25	June 2012
21	May 2012
124	April 2012
168	March 2012
80	February 2012
33	January 2012
108	December 2011
60	November 2011
97	October 2011
50	September 2011
46	August 2011
58	July 2011
47	June 2011
91	May 2011
35	April 2011
61	March 2011
9	February 2011
26	January 2011
51	December 2010
42	November 2010
146	October 2010
107	September 2010
155	August 2010
24	July 2010
27	June 2010
41	May 2010
44	April 2010
54	March 2010
232	February 2010
57	January 2010
33	December 2009
137	November 2009
120	October 2009
39	September 2009
24	August 2009
86	July 2009
27	June 2009
27	May 2009
91	April 2009
168	March 2009
60	February 2009
92	January 2009
114	December 2008
75	November 2008
205	October 2008
126	September 2008
123	August 2008
130	July 2008
29	June 2008
37	May 2008
38	April 2008
60	March 2008
63	February 2008
58	January 2008
160	December 2007
281	November 2007
109	October 2007
87	September 2007
149	August 2007
37	July 2007
76	June 2007
41	May 2007
43	April 2007
191	March 2007
146	February 2007
69	January 2007
39	December 2006
110	November 2006
92	October 2006
71	September 2006
95	August 2006
72	July 2006
148	June 2006
44	May 2006
33	April 2006
152	March 2006
123	February 2006
48	January 2006
67	December 2005
140	November 2005
130	October 2005
97	September 2005
46	August 2005
138	July 2005
96	June 2005
199	May 2005
36	April 2005
98	March 2005
111	February 2005
90	January 2005
74	December 2004
81	November 2004
76	October 2004
70	September 2004
200	August 2004
99	July 2004
57	June 2004
41	May 2004
161	April 2004
157	March 2004
192	February 2004
103	January 2004
67	December 2003
152	November 2003
239	October 2003
60	September 2003
50	August 2003
126	July 2003
78	June 2003
62	May 2003
53	April 2003
81	March 2003
206	February 2003
90	January 2003
46	December 2002
63	November 2002
109	October 2002
56	September 2002
54	August 2002
72	July 2002
66	June 2002
200	May 2002
68	April 2002
1	September 2000

Re: DHCPv6 client(proxy) sending unicast packets to server in all dhcp packets.

Re: DHCPv6 client(proxy) sending unicast packets to server in all dhcp packets.

FW: New Version Notification for draft-jiang-dhc-addr-registration-01.txt

Re: DHCPv6 client(proxy) sending unicast packets to server in all dhcp packets.

Re: FW: New Version Notification for draft-jiang-dhc-addr-registration-01.txt

Re: FW: New Version Notification for draft-jiang-dhc-addr-registration-01.txt

Re: FW: New Version Notification for draft-jiang-dhc-addr-registration-01.txt

Re: New Version Notification for draft-jiang-dhc-addr-registration-01.txt

Re: New Version Notification for draft-jiang-dhc-addr-registration-01.txt

Re: New Version Notification for draft-jiang-dhc-addr-registration-01.txt