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

Brian E Carpenter <brian.e.carpenter@gmail.com> Tue, 14 February 2017 19:59 UTC

Return-Path: <brian.e.carpenter@gmail.com>
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 403E31297D4; Tue, 14 Feb 2017 11:59:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 tZwl6iKMcnAy; Tue, 14 Feb 2017 11:59:49 -0800 (PST)
Received: from mail-oi0-x243.google.com (mail-oi0-x243.google.com [IPv6:2607:f8b0:4003:c06::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCE7C129420; Tue, 14 Feb 2017 11:59:43 -0800 (PST)
Received: by mail-oi0-x243.google.com with SMTP id x84so3645304oix.2; Tue, 14 Feb 2017 11:59:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=6Frf95Jc1E4K0s5Vg6+OVBUibpAZHAWj1jw7fo3Bc84=; b=Uu5QDQ1WD6Uu4nDLFUlKxDqqlGRBux/BL51tTSPO/s4IOmOE01xKAuRzDCtW/RlN6E BE90oAn3LNKpAX6+vKLLw1WmcpuNoYn3AaGnjR/PhEQExh9acbhU/mkR9CpJjgcV163n EhAKYy8sYIl8ev3oxu7m3MEutsvxnmmKWmgFr8OEF4qfgNGUuuw/+lVuJQu+1Qc6SjVw UdFsHQrqoZdL6tqY2biCzIA43jBATvcjGIPWEk4JySiGrsmsC96ufADhtzemRD7pF8+M ODgKnNc2V+/oVFjQSR9kNhJ9KzD5jpwUJ2Cu6pfoGSLQJQgfyEzPmq1iamDQYzX3lxqD ZdtQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=6Frf95Jc1E4K0s5Vg6+OVBUibpAZHAWj1jw7fo3Bc84=; b=YlB6L+9Ewcr0sMCGm4rKFCgNPjohVg5v5pQtPQu+yJGdd3eMtlJUF57ihE9Y9UeH36 QyINQSb8Sv9XCUgAqLUIjoFRuGV3UYNRyutLfNTvkDG3TObb57FUsyjcYStAD9R5ja7i VZ5BlCyCr3NctmI1iooXtSZmqlCOtGJkAMvqz6l8X01pg6Vl5NX6Im9+dxBWfJbS5I7i fMzqxCzJymKqO78MRJWnF0+giDscjDLxECu85b1KZT0T99m++u7pXOTM/F2E+L2qcqvt Ax8J2HqvgodIDxNekwH5OenWw0hqYXKA3SkCQ3pZ2IC9IUqlRc36cLz72f8twt7cHTMW MDkw==
X-Gm-Message-State: AMke39np/5sK3dNWLmBIo4A2X6oTyaOglyU0ff59M0tKaqhyzNy/AypSdb0MNiuGFcUMMA==
X-Received: by 10.84.229.76 with SMTP id d12mr37386526pln.21.1487102383040; Tue, 14 Feb 2017 11:59:43 -0800 (PST)
Received: from [192.168.178.21] ([118.148.78.74]) by smtp.gmail.com with ESMTPSA id w16sm2878517pgc.15.2017.02.14.11.59.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Feb 2017 11:59:42 -0800 (PST)
Subject: Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard
To: David Farmer <farmer@umn.edu>, Jordi Palet Martinez <jordi.palet@consulintel.es>
References: <148599306190.18700.14784486605754128729.idtracker@ietfa.amsl.com> <CAN-Dau0kDiSNXsyq9-xEdS5mzLt-K+MYHqoV8aC8jDVREw8OPQ@mail.gmail.com> <8e5c950a-0957-4323-670f-f3d07f40b4df@gmail.com> <CAN-Dau30OuJ7_57302shrSOs8+sc6iaoDgV27umxb59uwb_pZQ@mail.gmail.com> <E780DEC3-F0E9-4A35-B3EA-8D6961775276@consulintel.es> <CAN-Dau24tGpEvFEjk7xdu9tyN30bYwB6GmVMQjtKHs8LYFAJMQ@mail.gmail.com> <2A163C6E-FFBE-4502-BC2F-0DE8DF88C081@consulintel.es> <CAN-Dau2Qv1dww_yxgw_SCx+zmVjXrctkPRoTK9i1x2--zHrxRg@mail.gmail.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
Message-ID: <cd45eabb-6dd4-1ffc-ff92-aaa395f1fabf@gmail.com>
Date: Wed, 15 Feb 2017 08:59:41 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <CAN-Dau2Qv1dww_yxgw_SCx+zmVjXrctkPRoTK9i1x2--zHrxRg@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/vzQ_31DiZpAxB52XzSVt_E8Y8ew>
Cc: 6man WG <ipv6@ietf.org>, 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 19:59:51 -0000

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@consulintel.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@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/
>> ballot/
>>         >>
>>         >>
>>         >> 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/l
>> istinfo/ipv6
>>         >> ------------------------------------------------------------
>> --------
>>         >>
>>         >
>>         >
>>         >
>>         >
>>         >
>>         > ------------------------------------------------------------
>> --------
>>         > IETF IPv6 working group mailing list
>>         > ipv6@ietf.org
>>         > Administrative Requests: https://www.ietf.org/mailman/l
>> istinfo/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.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>     --
>>     ===============================================
>>     David Farmer               Email:farmer@umn.edu <mailto:
>> Email%3Afarmer@umn.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.
>>
>>
>>
>>
> 
>