sudurais a | 1 Jul 17:01 2011
Picon

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

Hi Ted,

Thanks. I meant, Solicit packet.

Why such a restriction imposed ?.

Regards,
sudurais,

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
Ole Troan | 4 Jul 10:23 2011

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

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
Jiangsheng | 5 Jul 09:40 2011

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
Bernie Volz (volz | 6 Jul 04:52 2011
Picon

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

Section 15 of RFC 3315 is pretty clear on this:

 

15. Message Validation

 

 

   A server MUST discard any Solicit, Confirm, Rebind or

   Information-request messages it receives with a unicast destination

   address.

 

There is other text that makes it clear that for other messages multicast is also the correct choice EXCEPT when the server has told the client that it may unicast (via the Server Unicast option).

 

The main reason for this is that we really want all client to server communication to always use the same path – which means to use the Relay Agent (and hence Relay-Forw) when the client and server are not on the same physical “wire”.

 

If DHCPv4, not requiring this caused some problems since Option 82 (Relay Agent) information was then not always available except if tricks were played.

 

-          Bernie

 

From: dhcwg-bounces <at> ietf.org [mailto:dhcwg-bounces <at> ietf.org] On Behalf Of sudurais a
Sent: Friday, July 01, 2011 11:01 AM
To: Ted Lemon
Cc: dhcwg <at> ietf.org
Subject: Re: [dhcwg] DHCPv6 client(proxy) sending unicast packets to server in all dhcp packets.

 

Hi Ted,

Thanks. I meant, Solicit packet.

Why such a restriction imposed ?.

Regards,
sudurais,

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
Bernie Volz (volz | 6 Jul 05:16 2011
Picon

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

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
Ted Lemon | 6 Jul 05:41 2011

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

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.
Jiangsheng | 6 Jul 05:51 2011

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

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
Ted Lemon | 6 Jul 05:57 2011

Re: 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.
Jiangsheng | 6 Jul 08:05 2011

Re: 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
Bernie Volz (volz | 6 Jul 13:34 2011
Picon

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

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

Gmane