Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
> --------------------------------------------------------------------





[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]