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

Lorenzo Colitti <lorenzo@google.com> Fri, 17 February 2017 06:33 UTC

Return-Path: <lorenzo@google.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 83C4E1295B3 for <ipv6@ietfa.amsl.com>; Thu, 16 Feb 2017 22:33:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 znpFbc4nKD_F for <ipv6@ietfa.amsl.com>; Thu, 16 Feb 2017 22:33:12 -0800 (PST)
Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com [IPv6:2607:f8b0:400c:c08::22e]) (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 2791E1295BF for <ipv6@ietf.org>; Thu, 16 Feb 2017 22:33:07 -0800 (PST)
Received: by mail-ua0-x22e.google.com with SMTP id 35so24925392uak.1 for <ipv6@ietf.org>; Thu, 16 Feb 2017 22:33:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YZmFU8iN9e/DIVWgrISQKJh8STej/v4HQzM681yF8WA=; b=lGu+/XDemFYdIPsJdyBvtTHjxGAdRHosw5l8QOk7nd3qqg8fqbO1bHdEekEKUZjKAW HkDmE57NcRIN0U2vRX7MaI5C+cCE41pud4dTNoF9p8IkLsh3NtWufzpTnOLrZ2iF6mWv qiXpimO+IUBynyQgaM4Nv7KZLKaRS5y++aAoh4ljw1Fg5xn5gqJNdh2v0D1HKzSNpcjI 6L+cFTYcwrTlqG7ULxViWH2s3SrcCDtkoT6WUPh4dLyXekKOE+P4pFXRaW4eiqaSSedq smUXRNV6sKSj9EZG4Vbhck3SD8AaZvJ2YubjuKyO/NzTONhdLNRSyVrNPnVCi1xvdYgF rdfg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=YZmFU8iN9e/DIVWgrISQKJh8STej/v4HQzM681yF8WA=; b=ML8rZT+ulHSng+jsOsIBSADFqBnJx58AJG3yVcVVkqYmaE75+0uKpAUfXPBI1HfnEm u1VDE8d3Pk9rG9gX/9dIW5A4s0gGNIZmDgSRMNqocHtERLUibQuwXim3g2tpR+nCJhwC ivN3Hps7MKvDQDWq8N/OvcZrCic9esl+RWK1pjEPvd7Q+SQrq7nBl1/DMvo30EzY56C6 U3FZq0gao3djUfxKhhiMsCEROVdTcbfU4CzcS4qC6gldlGGwUU3+MjPz5fOMuGr2qib/ PHb+G3jGiT7urbCJHm414Fd/wSYQfhOEsOGcV6iS+oUfj1bXQBNMxhcdyQhQvBC7BDLd ZSjw==
X-Gm-Message-State: AMke39n4gC0BagX0Tm/quQNswiK/LqVabkhXBnaIxImxNoc8oNNT+mD7lW2a1iklH0OxO07z1zbHtzgFmFHHNvsQ
X-Received: by 10.159.49.66 with SMTP id n2mr3457500uab.72.1487313186030; Thu, 16 Feb 2017 22:33:06 -0800 (PST)
MIME-Version: 1.0
Received: by 10.31.171.2 with HTTP; Thu, 16 Feb 2017 22:32:45 -0800 (PST)
In-Reply-To: <8767e370398045af989467a63747b29e@XCH15-06-11.nw.nos.boeing.com>
References: <148599306190.18700.14784486605754128729.idtracker@ietfa.amsl.com> <CAN-Dau0kDiSNXsyq9-xEdS5mzLt-K+MYHqoV8aC8jDVREw8OPQ@mail.gmail.com> <8e5c950a-0957-4323-670f-f3d07f40b4df@gmail.com> <05FD5283-9A15-4819-8362-5E6B2416D617@employees.org> <CAKD1Yr3B+dw83B0+26oUqdVJE==wHUBwoWzfWBJep8f+=uM8xQ@mail.gmail.com> <d9dc153a-61a8-5976-7697-ce1ecc9c8f3f@gmail.com> <4AF83EE6-6109-491F-BE66-114724BB197B@employees.org> <m2y3x6eutl.wl-randy@psg.com> <B76B6864-5827-4AC1-9BF7-8FFF069C10F1@employees.org> <m2lgt6ed7j.wl-randy@psg.com> <4514E052-25C1-4C85-AB1D-0B53FD9DA0E1@employees.org> <CAN-Dau3VriYNUf96yZEFMMV+-4WCxBz94Lkqfg3OsCUAbVYhaw@mail.gmail.com> <660929B4-158B-453F-9B5F-6C029F9699FA@employees.org> <E093E86F-41F5-4485-A8D3-761831F9AAF8@google.com> <8767e370398045af989467a63747b29e@XCH15-06-11.nw.nos.boeing.com>
From: Lorenzo Colitti <lorenzo@google.com>
Date: Fri, 17 Feb 2017 15:32:45 +0900
Message-ID: <CAKD1Yr2eg1VVetdURn7aH_1Y7sdqEjRQPzuP7a7=6vH0UQOQug@mail.gmail.com>
Subject: Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard
To: "Manfredi, Albert E" <albert.e.manfredi@boeing.com>
Content-Type: multipart/alternative; boundary="f403045e2fee1fd9d30548b41614"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/HT3ZDkX-tWPipnA0LALnVqLCMqs>
Cc: james woodyatt <jhw@google.com>, "6man-chairs@ietf.org" <6man-chairs@ietf.org>, "draft-ietf-6man-rfc4291bis@ietf.org" <draft-ietf-6man-rfc4291bis@ietf.org>, IETF-Discussion Discussion <ietf@ietf.org>, 6man WG <ipv6@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: Fri, 17 Feb 2017 06:33:17 -0000

That's a valid opinion but it does not reflect the current state of the
IPv6 standards.

Again, let's bear in mind that this discussion is not about changing the
standard, but about reclassifying the existing standards. We can discuss
changing this part of the standard to our heart's content, but *in 6man, on
another document*, not here.

I would be rather surprised if such a discussion ever reached consensus,
but I certainly wouldn't want to dissuade anyone from trying.

On Fri, Feb 17, 2017 at 7:38 AM, Manfredi, Albert E <
albert.e.manfredi@boeing.com> wrote:

> RFC 7421 is informational. And many considerations are not so critical
> anymore, on a specific stateful format.
>
>
>
> I don’t think we need to reinforce the notion that IPv6 must have 64-bit
> prefixes, since that is not true now, and should not even be made to apply
> to the currently unused address space. So, I’m opposed to text that implies
> any such restriction, with the exception of (a) currently used unicast
>  address space, (b) SLAAC, (c) ULA, possibly other exceptions.
>
>
>
> In other words, *exceptions belong to requiring the 64-bit IID*. Any RFC
> that implies otherwise, IMO, ought to be subject to a –bis version.
>
>
>
> Bert
>
>
>
>
>
> *From:* ipv6 [mailto:ipv6-bounces@ietf.org] *On Behalf Of *james woodyatt
> *Sent:* Thursday, February 16, 2017 17:21
> *To:* IETF-Discussion Discussion <ietf@ietf.org>
> *Cc:* 6man WG <ipv6@ietf.org>; draft-ietf-6man-rfc4291bis@ietf.org;
> 6man-chairs@ietf.org
> *Subject:* Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version
> 6 Addressing Architecture) to Internet Standard
>
>
>
> On Feb 16, 2017, at 13:25, otroan@employees.org wrote:
>
> On Feb 13, 2017, at 14:32, David Farmer <farmer@umn.edu> 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. […]
>
>
>
> […]
>
> The challenge is to find text that enforces the 64-bit boundary policy
> (ignoring the technical arguments for a moment), and at the same time
> ensures implementors do the right thing and make their code handle any
> prefix length. Of course these are interdependent and doing the latter
> makes it harder to enforce the first.
>
>
>
> I propose the following:
>
>
>
> IPv6 unicast routing is based on prefixes of any valid length up to 128
> bits [BCP198]. However, as explained in [RFC7421], the Interface ID of
> unicast addresses is generally required to be 64 bits in length, with
> exceptions only provided in special cases where expressly recognized in
> IETF standards track documents.
>
>
>
> Trying to help out here.
>
>
>
>
>
> --james woodyatt <jhw@google.com>
>
>
>
>
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
>