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

Philip Homburg <pch-ietf-6@u-1.phicoh.com> Thu, 23 February 2017 10:20 UTC

Return-Path: <pch-bF054DD66@u-1.phicoh.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 4686412969B; Thu, 23 Feb 2017 02:20:59 -0800 (PST)
X-Quarantine-ID: <qT5hQXrgLfqc>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Cc"
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 qT5hQXrgLfqc; Thu, 23 Feb 2017 02:20:57 -0800 (PST)
Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 018431294B2; Thu, 23 Feb 2017 02:20:55 -0800 (PST)
Received: from stereo.hq.phicoh.net ([::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #127) id m1cgqW5-0000MkC; Thu, 23 Feb 2017 11:20:53 +0100
Message-Id: <m1cgqW5-0000MkC@stereo.hq.phicoh.net>
To: ietf@ietf.org
Subject: Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard
From: Philip Homburg <pch-ietf-6@u-1.phicoh.com>
Sender: pch-bF054DD66@u-1.phicoh.com
References: <20170221001940.GB84656@Vurt.local> <068ce975-8b1e-a7c5-abba-2bfc1d904d70@gmail.com> <20170221101339.GC84656@Vurt.local> <CAKD1Yr33oQb=gMGaEM++hLgmMtxMdihiDrUihEsjs63vy8qRbA@mail.gmail.com> <54c81141-e4f5-4436-9479-9c02be6c09bb@Spark> <CAKD1Yr28iQHt0iuLvR3ndrT3Hfct=4k9dxjJeu3MAjDjOogEvA@mail.gmail.com> <CAL9jLaZgTp++PJ9KGHEWuPoVm6t3b8QfVDCEhz5h4fv-0fuUAA@mail.gmail.com> <CAKD1Yr3SbR=xt3RPu7+q1o14wKuUuwUc6oG+BgZtEK1O+m5sWw@mail.gmail.com> <4936e96b-fc82-4de0-9188-ced9547deb2f@Spark> <CAKD1Yr3K+SJb_4ksZ96yNypVKJE-fXopuVaXNhhKp1gkh1=QEg@mail.gmail.com> <20170222144147.GC89584@hanna.meerval.net> <7960ff2d-359f-429c-6e82-ef592f90bf53@gmail.com> <CAKD1Yr1W+AVt4Dixo9epB5VazxBsVMD+mrshwaE=n7SuX6eGDw@mail.gmail.com>
In-reply-to: Your message of "Thu, 23 Feb 2017 09:41:43 +0900 ." <CAKD1Yr1W+AVt4Dixo9epB5VazxBsVMD+mrshwaE=n7SuX6eGDw@mail.gmail.com>
Date: Thu, 23 Feb 2017 11:20:53 +0100
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/hBQ96sm0eXoSjZtiqNOW_tfDCRM>
Cc: draft-ietf-6man-rfc4291bis@ietf.org, 6man-chairs@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: Thu, 23 Feb 2017 10:20:59 -0000

>> Nobody is saying that /64 isn't extremely widely used where it's
>> appropriate to have a portable fixed length IID. Set the default
>> at 64 and trust operators to change it where they need to.
>> That's realistic.
>
>As a host developer I strongly oppose that. It will make life easier for
>network operators but make life harder for host OS developers, host
>operators, and host users.
>
>And it is absolutely inappropriate to change this now in given that the /64
>boundary has been the standard for the last 20 years. It will break
>deployed code that relies on the current standard. (That includes concrete
>code I can point to that I know runs on tens of millions of devices.)
>That's not acceptable to do in a standard reclassification.

Lorenzo,

I'm curious about the issues the host developer faces.

It seems to me that there are three basic ways of configuring addresses:
1) SLAAC
2) DHCP IA_NA
3) Manual

There is of course also DHCP IA_PD, but I'll leave that out for the moment
as it is not directly relevant to IIDs.

For DHCP IA_NA, the host should not care about the length of the IID. The
host just configures the address as a whole. Not need to look at the prefix
length.

With manual configuration, again the host doesn't care. If is possible that
manual configuration is done using IIDs. But combining an IID and a prefix is
not magic. There is no reason why manually configured IIDs whould have to be
64 bits.

Then there is SLAAC. I'm fully on board to say that SLAAC should require
64 bit IIDs for ever. 

So it seems to me that there are operators that want to use longer prefixes
with manual configuration and you want to keep SLAAC at 64-bit. That sounds
perfectly consistent.

I can't think of any reason why IA_NA or manually configured IIDs would have
to be 64 bit. 

So a text like 'implementations MUST support 64-bit IIDs for SLAAC.
implementations SHOULD support other lengths for other ways of configuring
addresses (IA_NA, manual).' should work. Or did I miss something?