Re: FW: New Version Notification for draft-jiang-dhc-addr-registration-01.txt
Jiangsheng <jiangsheng <at> huawei.com>
2011-07-06 03:51:55 GMT
Thanks for your valuable comments. See my replies in lines.
> Without judging whether I think this is a good or bad idea, I will
> out that one (IMHO) major flaw is that there is no "lifetime"
> 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
> hint at the address (and if not in use and assuming server policy
> 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
All you above points are right. But the registration is not only to avoid address duplication.
> - 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
> 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
> Any comments are welcome!
> Best regards,
> > -----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-
> > registration-01.txt
> > A new version of I-D, draft-jiang-dhc-addr-registration-01.txt has
> > successfully submitted by Sheng Jiang and posted to the IETF
> > Filename: draft-jiang-dhc-addr-registration
> > Revision: 01
> > Title: A Generic IPv6 Addresses Registration Solution
> > 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
> > architecture. These addresses need to be registered in the
> > networking
> > management plate for the purposes of central address
> > 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