Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Address

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(_dot_)palet(_at_)consulintel(_dot_)es> 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(_at_)ietf(_dot_)org> en nombre de David Farmer 
> > <farmer(_at_)umn(_dot_)edu
> > >
> > Responder a: <farmer(_at_)umn(_dot_)edu>
> > Fecha: martes, 14 de febrero de 2017, 17:03
> > Para: Jordi Palet Martinez <jordi(_dot_)palet(_at_)consulintel(_dot_)es>
> > CC: 6man WG <ipv6(_at_)ietf(_dot_)org>, 
> > <draft-ietf-6man-rfc4291bis(_at_)ietf(_dot_)org>,
> > IETF-Discussion Discussion <ietf(_at_)ietf(_dot_)org>, 
> > <6man-chairs(_at_)ietf(_dot_)org>
> > 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(_dot_)palet(_at_)consulintel(_dot_)es> wrote:
> >
> >     Agree, we shouldn’t change that. Must be 64 bits.
> >
> >     Regards,
> >     Jordi
> >
> >
> >     -----Mensaje original-----
> >     De: ietf <ietf-bounces(_at_)ietf(_dot_)org> en nombre de David Farmer <
> > farmer(_at_)umn(_dot_)edu>
> >     Responder a: <farmer(_at_)umn(_dot_)edu>
> >     Fecha: martes, 14 de febrero de 2017, 16:27
> >     Para: Brian E Carpenter 
> > <brian(_dot_)e(_dot_)carpenter(_at_)gmail(_dot_)com>
> >     CC: <draft-ietf-6man-rfc4291bis(_at_)ietf(_dot_)org>, 
> > <6man-chairs(_at_)ietf(_dot_)org>,
> > 6man WG <ipv6(_at_)ietf(_dot_)org>, IETF-Discussion Discussion 
> > <ietf(_at_)ietf(_dot_)org>
> >     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(_dot_)e(_dot_)carpenter(_at_)gmail(_dot_)com> 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(_at_)ietf(_dot_)org> 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(_at_)ietf(_dot_)org mailing lists by 2017-03-01. 
> > Exceptionally,
> > comments may be
> >         >> sent to iesg(_at_)ietf(_dot_)org 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(_at_)ietf(_dot_)org
> >         >> Administrative Requests: https://www.ietf.org/mailman/l
> > istinfo/ipv6
> >         >> ------------------------------------------------------------
> > --------
> >         >>
> >         >
> >         >
> >         >
> >         >
> >         >
> >         > ------------------------------------------------------------
> > --------
> >         > IETF IPv6 working group mailing list
> >         > ipv6(_at_)ietf(_dot_)org
> >         > Administrative Requests: https://www.ietf.org/mailman/l
> > istinfo/ipv6
> >         > ------------------------------------------------------------
> > --------
> >         >
> >
> >
> >
> >
> >
> >
> >         --
> >         ===============================================
> >         David Farmer               Email:farmer(_at_)umn(_dot_)edu <mailto:
> > Email%3Afarmer(_at_)umn(_dot_)edu> <mailto:Email%3Afarmer(_at_)umn(_dot_)edu 
> > <mailto:
> > Email%253Afarmer(_at_)umn(_dot_)edu>>
> >         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(_at_)umn(_dot_)edu <mailto:
> > Email%3Afarmer(_at_)umn(_dot_)edu>
> >     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.