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

Pierre Pfister <pierre.pfister@darou.fr> Thu, 23 February 2017 10:24 UTC

Return-Path: <SRS0=0eqy=2E=darou.fr=pierre.pfister@bounces.m4x.org>
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 E0055129602; Thu, 23 Feb 2017 02:24:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 eJ5jmkDRCKpR; Thu, 23 Feb 2017 02:24:41 -0800 (PST)
Received: from mx1.polytechnique.org (mx1.polytechnique.org [129.104.30.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EFA0129669; Thu, 23 Feb 2017 02:24:41 -0800 (PST)
Received: from ppfister-m-ja6k.ciscolive.local (unknown [80.157.70.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ssl.polytechnique.org (Postfix) with ESMTPSA id 73D105647A7; Thu, 23 Feb 2017 11:24:38 +0100 (CET)
Content-Type: text/plain; charset="us-ascii"
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
From: Pierre Pfister <pierre.pfister@darou.fr>
In-Reply-To: <ECF27195-4A6B-4AFC-8950-83876F333BD4@employees.org>
Date: Thu, 23 Feb 2017 11:24:33 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <A1F60D51-C39E-45DC-B3D5-960D92C186E4@darou.fr>
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> <ECF27195-4A6B-4AFC-8950-83876F333BD4@employees.org>
To: Ole Troan <otroan@employees.org>, 6man WG <ipv6@ietf.org>, IETF-Discussion Discussion <ietf@ietf.org>
X-Mailer: Apple Mail (2.3259)
X-AV-Checked: ClamAV using ClamSMTP at svoboda.polytechnique.org (Thu Feb 23 11:24:38 2017 +0100 (CET))
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/PoIPvsuhjt2QM7YMQ66_MZMuYN8>
Cc: james woodyatt <jhw@google.com>, 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, 23 Feb 2017 10:32:39 -0000

Hello all,

> Proposal:
>  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 recognised
>  in IETF standards track documents.
> 

The only place in IPv6 standards where the 64 boundary is mandated is on the 2000::/3 rule.
There is not a single implementation or deployment of that rule. There is no instance where 
trying to configure a prefix of length different than 64 will work when the prefix is within 2000::/3, and fail when it is not.
That is a sufficient reason to not include this rule as part of the standard track.

Nevertheless, SLAAC over Ethernet links indeed requires prefix length of 64.
As documented in the RFC7421, there are a few examples of protocols which require 64 bits long interface identifiers.

SLAAC is not the only way to configure IPv6 hosts though.
Manual configuration, automated configuration, and DHCP are all IETF approved ways of configuring IPv6 hosts. 
They all work with prefixes of various lengths. 
Does 'special cases' in the proposed text covers manual/automated configuration or DHCP ? If so, it is far from being clear.

You obviously should use /64s if you want SLAAC to work, as well as other protocols which are documented in RFC7421,
but /64 is not the rule, it is an architectural consideration that you have to take into account when you design your network depending on the protocols that you want to run there.

Therefore, as far as this discussion is concerned, there is no reason to mandate 64 bits boundaries as part of the IPv6 specification.

- Pierre