I certainly agree with that approach too. In answer to Alexandre: you are correct that this value is a parameter for RFC4862. But for reasons we have discussed often, it needs to be fixed by the architecture. Regards Brian On 15/02/2017 08:18, David Farmer wrote: > So I hear you saying something like the following would be appropriate in > your opinion; > > However, the Interface ID of all unicast addresses is required to be 64 bit > with the exception of the following; addresses for point-to-point links > [RFC6164], Network-Specific Prefixes used for IPv4/IPv6 Translators > [RFC6052], and addresses that start with the binary value 000. > > While this is the less preferred approach as far as I'm concerned, I > believe it resolves the issue I raised. > > Thanks. > > On Tue, Feb 14, 2017 at 10:07 AM, JORDI PALET MARTINEZ < > jordi.palet@xxxxxxxxxxxxxx> wrote: > >> 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/ >> ballot/ >> >> >> >> >> >> 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/l >> istinfo/ipv6 >> >> ------------------------------------------------------------ >> -------- >> >> >> > >> > >> > >> > >> > >> > ------------------------------------------------------------ >> -------- >> > IETF IPv6 working group mailing list >> > ipv6@xxxxxxxx >> > Administrative Requests: https://www.ietf.org/mailman/l >> istinfo/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. >> >> >> >> >> >> >> >> >> >> -- >> =============================================== >> David Farmer Email:farmer@xxxxxxx <mailto: >> Email%3Afarmer@xxxxxxx> >> Networking & Telecommunication Services >> Office of Information Technology >> University of Minnesota >> 2218 University Ave SE Phone: 612-626-0815 >> Minneapolis, MN 55414-3029 Cell: 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. >> >> >> >> > >