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

james woodyatt <jhw@google.com> Thu, 16 February 2017 22:21 UTC

Return-Path: <jhw@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 92CEE129560 for <ipv6@ietfa.amsl.com>; Thu, 16 Feb 2017 14:21:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 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_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 0Mgv3_cWGK2b for <ipv6@ietfa.amsl.com>; Thu, 16 Feb 2017 14:21:18 -0800 (PST)
Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::22d]) (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 8CEC11295AE for <ipv6@ietf.org>; Thu, 16 Feb 2017 14:21:18 -0800 (PST)
Received: by mail-pf0-x22d.google.com with SMTP id e4so8391929pfg.1 for <ipv6@ietf.org>; Thu, 16 Feb 2017 14:21:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=kheEmpcw6dfHTuKTw63Yss4BC89XLyNjEZOhyKiuGKI=; b=JmXTBJFzCAvOTQY4w1aH2QeyDHkRojxj8cLXfkC2NBdLyiKSAS+c/rIW/0Osq93V5B Y3mdJvEPa9IKkPGSZ8Iyi1nA1Kcmda65ElqtoQq9+RvTuDhd6qFATs86zTEZzUNboIRW u/AOWaQ3SOQN97wj1FuT6YbDrS+RPomZ5Zhko8z6FHC6YAwRyQPwTKjmb6bVPo7qBNAx UZQw8SCtWzfHbuVOHdvJj72UTw1mZpsYGqfojk4MMvD4VRykVNctrdYifJEis+vmI4gP nFgutu93Zkjc0jEJXa9Qoa2JlrNnIbtY1eIBBcZDwVF43KRadOos2qr0KfAFWLbS73e3 SdcQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=kheEmpcw6dfHTuKTw63Yss4BC89XLyNjEZOhyKiuGKI=; b=GdPGyfZU/rKLL1HAFob9iw94U1k5pgyG+2Y8RYgmJshejmmr5y3pRYyR+CI6g1jqiT 2rZIQepU01ZM58ac5naMH+jz5c95tfU7UrFqBp2MXcKlluh23XoUl31kdY89UiZPmiE0 ImGtTjzxESJSweWaes7UWkHDK3LGssW6BvzR1EsPtxj3MUVHdG6j8DvyAQYIgUwSM+1D B2zYC1+jGXpeEdVsgwDvyKDfVIjYsvEeU5zHZlhCsrdMLK+2CsgX22ua4mowSW0+rQ+9 2ZRCXYTwfocTJa4mQP80k532MyYvaTYoZTYJfFsK1jtaUeZQUrkKuAXxtiUXMbcYcgcs PURg==
X-Gm-Message-State: AMke39kzxs5MOZ+cj68HOJY4GiNCMlOBiNGdVoTwvNiZ0sn9QKtndLCQLSzv8ZlvSUKGy1yk
X-Received: by 10.84.173.195 with SMTP id p61mr6405283plb.63.1487283678021; Thu, 16 Feb 2017 14:21:18 -0800 (PST)
Received: from dhcp-100-99-230-134.pao.corp.google.com ([100.99.230.134]) by smtp.gmail.com with ESMTPSA id w89sm15324777pfk.133.2017.02.16.14.21.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Feb 2017 14:21:17 -0800 (PST)
From: james woodyatt <jhw@google.com>
Message-Id: <E093E86F-41F5-4485-A8D3-761831F9AAF8@google.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_B8C728E4-78A4-4BBD-813F-498B8AB21D5B"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Subject: Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard
Date: Thu, 16 Feb 2017 14:21:16 -0800
In-Reply-To: <660929B4-158B-453F-9B5F-6C029F9699FA@employees.org>
To: IETF-Discussion Discussion <ietf@ietf.org>
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>
X-Mailer: Apple Mail (2.3259)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/fUP7piFcxg3nEK1jQKGZvK8Iwcg>
Cc: 6man WG <ipv6@ietf.org>, draft-ietf-6man-rfc4291bis@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: Thu, 16 Feb 2017 22:21:20 -0000

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 <mailto:jhw@google.com>>