Dear all: FWIW, I also created a ticket https://trac.ietf.org/trac/6lo/ticket/20 to track the issue.
Please let me know if the text below is OK (you may leverage the ticket); I'll time out and post by the end of week. Take care, Pascal -----Original Message----- From: 6lo [mailto:6lo-boun...@ietf.org] On Behalf Of Pascal Thubert (pthubert) Sent: mardi 4 avril 2017 18:16 To: Erik Nordmark <nordm...@sonic.net>; Christian Huitema <huit...@huitema.net>; Lorenzo Colitti <lore...@google.com> Cc: Brian Haberman <br...@innovationslab.net>; 6lo@ietf.org Subject: Re: [6lo] Draft applicability for 6775bis Dear all: I retrofitted the text with minors editions as follows: " 2. Applicability The purpose of the Address Registration Option (ARO) option [RFC6775] and the Extended ARO (EARO) option that is introduced in this document is to facilitate duplicate address detection (DAD) for hosts and pre-populate Neighbor Cache Entries (NCE) [RFC4861] in the routers to reduce the need for sending multicast neighbor solicitations and also to be able to support backbone routers. In some cases the address registration can fail or be useless for reasons other than a duplicate address. Examples are the router having run out of space, a registration bearing a stale sequence number (e.g. denoting a movement of the host after this registration was placed), a host misbehaving and attempting to register an invalid address such as the unspecified address [RFC4291], or the host using an address which is not topologically correct on that link. In such cases the host will receive an error to help diagnose the issue and may retry, possibly with a different address, and possibly registering to a different 6LR, depending on the returned error. However, the ability to return errors to address registrations MUST NOT be used to restrict the ability of hosts to form and use addresses as recommended in Host Address Availability Recommendations [RFC7934]. In particular, this is needed for enhanced privacy, which implies that each host will register a multiplicity of address as part mechanisms like Privacy Extensions for Stateless Address Autoconfiguration (SLAAC) in IPv6 [RFC4941]. This implies that a 6LR or 6LBR which is intended to support N hosts MUST have space to register at least on the order of 10N IPv6 addresses. " I also removed the administrative rejection, the return codes are now as follows: " +-------+-----------------------------------------------------------+ | Value | Description | +-------+-----------------------------------------------------------+ | 0..2 | See [RFC6775]. Note that a Status of 1 "Duplicate | | | Address" applies to the Registered Address. If the Source | | | Address conflicts with an existing registration, | | | "Duplicate Source Address" should be used instead | | | | | 3 | Moved: The registration fails because it is not the | | | freshest | | | | | 4 | Removed: The binding state was removed. This may be | | | placed in an asynchronous NS(ARO) message, or as the | | | rejection of a proxy registration to a Backbone Router | | | | | 5 | Proof requested: The registering node is challenged for | | | owning the registered address or for being an acceptable | | | proxy for the registration | | | | | 6 | Duplicate Source Address: The address used as source of | | | the NS(ARO) conflicts with an existing registration. | | | | | 7 | Invalid Source Address: The address used as source of the | | | NS(ARO) is not usable on this link, e.g. it is not | | | topologically correct | | | | | 8 | Invalid Registered Address: The address being registered | | | is not usable on this link, e.g. it is not topologically | | | correct | +-------+-----------------------------------------------------------+ " Does that work? Take care, Pascal -----Original Message----- From: 6lo [mailto:6lo-boun...@ietf.org] On Behalf Of Brian Haberman Sent: mardi 4 avril 2017 16:42 To: 6lo@ietf.org Subject: Re: [6lo] Draft applicability for 6775bis On 4/4/17 10:02 AM, Suresh Krishnan wrote: > Hi Dave, > >> On Mar 29, 2017, at 1:47 PM, Dave Thaler <dtha...@microsoft.com> >> wrote: >> >> Any issue with a standards track document having a normative >> reference to a BCP? > > No issues that I know of. The downref rules seem to be pointing > *from* Standards track and BCP documents *to* lower maturity level > documents as per RFC3967. Just to be safe, I can still call this out > in the IETF last call if the WG decides to go that way. Right. ST and BCP are at the same level, so there are no down-ref issues with a normative reference. Those issues arise when ST or BCP documents normatively reference Info and Experimental documents. _______________________________________________ 6lo mailing list 6lo@ietf.org https://www.ietf.org/mailman/listinfo/6lo _______________________________________________ 6lo mailing list 6lo@ietf.org https://www.ietf.org/mailman/listinfo/6lo
