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

Karsten Thomann <karsten_thomann@linfre.de> Tue, 14 February 2017 18:36 UTC

Return-Path: <karsten_thomann@linfre.de>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3148129A86; Tue, 14 Feb 2017 10:36:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level:
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x3aPDU0VTMBd; Tue, 14 Feb 2017 10:36:14 -0800 (PST)
Received: from linfre.de (linfre.de [83.151.26.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C48A129685; Tue, 14 Feb 2017 10:36:14 -0800 (PST)
Received: from linne.localnet (91.96.120.134) by linfreserv (Axigen) with (ECDHE-RSA-AES256-SHA encrypted) ESMTPSA id 08FD9E; Tue, 14 Feb 2017 19:36:06 +0100
From: Karsten Thomann <karsten_thomann@linfre.de>
To: ipv6@ietf.org, jordi.palet@consulintel.es
Subject: Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard
Message-ID: <1513056.oYYGoBVvp1@linne>
User-Agent: KMail/4.13.0.22 (Windows/6.1; KDE/4.14.3; i686; git-c97962a; 2016-07-14)
In-Reply-To: <2A163C6E-FFBE-4502-BC2F-0DE8DF88C081@consulintel.es>
References: <148599306190.18700.14784486605754128729.idtracker@ietfa.amsl.com> <CAN-Dau24tGpEvFEjk7xdu9tyN30bYwB6GmVMQjtKHs8LYFAJMQ@mail.gmail.com> <2A163C6E-FFBE-4502-BC2F-0DE8DF88C081@consulintel.es>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="cp 1252"
X-AXIGEN-DK-Result: No records
DomainKey-Status: no signature
X-AxigenSpam-Level: 7
Date: Tue, 14 Feb 2017 10:36:14 -0800 (PST)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/BaYx95DvdNMLL40uBuoo6MJWaac>
Cc: draft-ietf-6man-rfc4291bis@ietf.org, IETF-Discussion Discussion <ietf@ietf.org>, 6man-chairs@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Feb 2017 18:36:16 -0000

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