In my opinion the sentence should be restricted to cases where it's required to be 64 bit (SLAAC) and allow everything else. There are enough examples where /127, /126 and /124bit masks are used. So my favorite version is the one from Brian > However, the Interface ID of unicast addresses used for > Stateless Address Autoconfiguration [RFC4862] is required > to be 64 bits long. Followed by David's version extended with recommendation of 64bit IID. Regards Karsten Am Dienstag, 14. Februar 2017, 17:07:09 schrieb JORDI PALET MARTINEZ: > I understand that, but those are two clear exceptions, no others should be > “allowed” by default. > > Keeping the door open is not good in my opinion. Specific exceptions must be > taken in consideration one by one. > > Regards, > Jordi > > > -----Mensaje original----- > De: ietf <ietf-bounces@xxxxxxxx> en nombre de David Farmer <farmer@xxxxxxx> > Responder a: <farmer@xxxxxxx> > Fecha: martes, 14 de febrero de 2017, 17:03 > Para: Jordi Palet Martinez <jordi.palet@xxxxxxxxxxxxxx> > CC: 6man WG <ipv6@xxxxxxxx>, <draft-ietf-6man-rfc4291bis@xxxxxxxx>, > IETF-Discussion Discussion <ietf@xxxxxxxx>, <6man-chairs@xxxxxxxx> Asunto: > Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing > Architecture) to Internet Standard > > The problem we want it to be 64 bits except when it's not suppose to be, > such as RFC6164 for point-to-point and RFC6052 for IPv4/IPv6 translators > with /96 Network-Specific Prefix. > > On Tue, Feb 14, 2017 at 9:53 AM, JORDI PALET MARTINEZ > <jordi.palet@xxxxxxxxxxxxxx> wrote: > > Agree, we shouldn’t change that. Must be 64 bits. > > Regards, > Jordi > > > -----Mensaje original----- > De: ietf <ietf-bounces@xxxxxxxx> en nombre de David Farmer > <farmer@xxxxxxx> Responder a: <farmer@xxxxxxx> > Fecha: martes, 14 de febrero de 2017, 16:27 > Para: Brian E Carpenter <brian.e.carpenter@xxxxxxxxx> > CC: <draft-ietf-6man-rfc4291bis@xxxxxxxx>, <6man-chairs@xxxxxxxx>, 6man > WG <ipv6@xxxxxxxx>, IETF-Discussion Discussion <ietf@xxxxxxxx> Asunto: Re: > Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing > Architecture) to Internet Standard > > Actually, in addition to your text there still needs to be a > recommendation for 64 bit IIDs in all other cases. 64 bit IIDs are(and > should remain) the norm for IPv6, I do not want to change that. But the > current language say IIDs are always 64 bit except when an address begins > with binary 000, leaving no room for any other exception. And this is > plainly incorrect, I provided two clear exceptions that are already > standardized. Furthermore, IIDs other than 64 bits are in operational use, > with manual configuration and DHCPv6. So I'd suggest; > > However, the Interface ID of unicast addresses used for > Stateless Address Autoconfiguration [RFC4862] is required > to be 64 bits long, in all other cases it is recommended to > be 64 bits long. > > The other option is to enumerate all the exceptions, requiring the > document to be updated every time a new exception is standardized. > > On Mon, Feb 13, 2017 at 4:53 PM, Brian E Carpenter > <brian.e.carpenter@xxxxxxxxx> wrote: > > At an earlier stage I suggested restricting the applicability > of the "However..." sentence to SLAAC [RFC4862]. A short way > of doing this would be > > However, the Interface ID of unicast addresses used for > Stateless Address Autoconfiguration [RFC4862] is required > to be 64 bits long. > > Regards > Brian > > On 14/02/2017 11:32, David Farmer wrote: > > I have concerns with the following text; > > > > IPv6 unicast routing is based on prefixes of any valid length > > up to > > 128 [BCP198]. For example, [RFC6164] standardises 127 bit > > prefixes > > on inter-router point-to-point links. However, the Interface ID > > of > > all unicast addresses, except those that start with the binary > > value > > 000, is required to be 64 bits long. The rationale for the 64 > > bit > > boundary in IPv6 addresses can be found in [RFC7421] > > > > The third sentence seems to limit exceptions to 64 bit IIDs to > > exclusively > > addresses that start with binary vale of 000. There are at least > > two other > > exceptions from standards track RFCs, that should be more clear > > accounted > > for in this text. First is [RFC6164] point-to-point links, as > > mentioned in > > the previous sentence. I think the clear intent of [RFC6164] is > > to allow > > one(1) Bit IIDs for point to point-to-point links using any Global > > Unicast > > Address, not just those that start with 000. Second is, > > [RFC6052], which > > updates [RFC4921] and seems to allow 32 bit IIDs or /96 prefixes > > for any > > Global Unicast Address when used for IPv4/IPv6 translation, > > referred to as > > ""Network-Specific Prefix" unique to the organization deploying > > the address > > translators," in section 2.2 of [RFC6052]. > > > > Thanks. > > > > On Wed, Feb 1, 2017 at 5:51 PM, The IESG <iesg-secretary@xxxxxxxx> wrote: > >> The IESG has received a request from the IPv6 Maintenance WG > >> (6man) to > >> consider the following document: > >> - 'IP Version 6 Addressing Architecture' > >> > >> <draft-ietf-6man-rfc4291bis-07.txt> as Internet Standard > >> > >> The IESG plans to make a decision in the next few weeks, and > >> solicits > >> final comments on this action. Please send substantive comments > >> to the > >> ietf@xxxxxxxx mailing lists by 2017-03-01. Exceptionally, > >> comments may be > >> sent to iesg@xxxxxxxx instead. In either case, please retain the > >> beginning of the Subject line to allow automated sorting. > >> > >> Abstract > >> > >> This specification defines the addressing architecture of the > >> IP > >> Version 6 (IPv6) protocol. The document includes the IPv6 > >> addressing > >> model, text representations of IPv6 addresses, definition of > >> IPv6 > >> unicast addresses, anycast addresses, and multicast addresses, > >> and an > >> IPv6 node's required addresses. > >> > >> This document obsoletes RFC 4291, "IP Version 6 Addressing > >> Architecture". > >> > >> The file can be obtained via > >> https://datatracker.ietf.org/doc/draft-ietf-6man-rfc4291bis/ > >> > >> IESG discussion can be tracked via > >> https://datatracker.ietf.org/doc/draft-ietf-6man-rfc4291bis/ballo > >> t/ > >> > >> > >> No IPR declarations have been submitted directly on this I-D. > >> > >> > >> > >> > >> ----------------------------------------------------------------- > >> --- > >> IETF IPv6 working group mailing list > >> ipv6@xxxxxxxx > >> Administrative Requests: > >> https://www.ietf.org/mailman/listinfo/ipv6 > >> ----------------------------------------------------------------- > >> --- > > > > ------------------------------------------------------------------ > > -- > > IETF IPv6 working group mailing list > > ipv6@xxxxxxxx > > Administrative Requests: > > https://www.ietf.org/mailman/listinfo/ipv6 > > ------------------------------------------------------------------ > > -- > > -- > =============================================== > David Farmer Email:farmer@xxxxxxx > <mailto:Email%3Afarmer@xxxxxxx> <mailto:Email%3Afarmer@xxxxxxx > <mailto:Email%253Afarmer@xxxxxxx>> Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 <tel:612-626-0815> > Minneapolis, MN 55414-3029 Cell: 612-812-9952 <tel:612-812-9952> > =============================================== > > > > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the use of the > individual(s) named above. If you are not the intended recipient be aware > that any disclosure, copying, distribution or use of the contents of this > information, including attached files, is prohibited. > > > > > > > > > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the use of the > individual(s) named above. If you are not the intended recipient be aware > that any disclosure, copying, distribution or use of the contents of this > information, including attached files, is prohibited. > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@xxxxxxxx > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > --------------------------------------------------------------------