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

otroan@employees.org Wed, 15 February 2017 21:34 UTC

Return-Path: <otroan@employees.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 E16EE129867; Wed, 15 Feb 2017 13:34:08 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org
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 iAeQnTwd80HZ; Wed, 15 Feb 2017 13:34:07 -0800 (PST)
Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id 1527E129866; Wed, 15 Feb 2017 13:34:07 -0800 (PST)
Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 15 Feb 2017 21:34:07 +0000
Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id A574AD788E; Wed, 15 Feb 2017 13:34:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=ry+9XELTne46a3UwVqo10VqRgzg=; b= lqCncTsuzr7+COWLIcQ4CF7UzEVrJyAgMnlJJrQs1C5qZLsK3IAYeDrqnV/7reBt uODRy+yV0WfQ4Gc4IJ+cEYwXzgccWqtJO7Oa2PLuhn9411JXl+EfptxOQaeQF5C6 jm1Ux6/CptBw/8Gm02/Vs0tMoRGcSP8fToIbTJ2vnZo=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=IEML55kw+rWhwe6EaXPA/pS mMzO7iiz7Jlq/TV39Vmr266QFZ3acB/HasmWl3BLBWMwRZOFjIINUyUmba+tdnEA L20nesukYiq8jOSEGEimKzCdePy0Rb9tnyCCc+5a3qkhpQ4gh/cVmva6yYx8WPat 61xjdvF+I20QzOOTjoHs=
Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 78DE3D788D; Wed, 15 Feb 2017 13:34:06 -0800 (PST)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id BA67A8BC9F36; Wed, 15 Feb 2017 22:34:14 +0100 (CET)
From: otroan@employees.org
Message-Id: <B4A4FFFD-A90D-4C26-BDBD-75555840CA22@employees.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_8DF724A5-A49A-42FC-94CA-A61B929DF27A"; protocol="application/pgp-signature"; micalg=pgp-sha512
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: Wed, 15 Feb 2017 22:34:13 +0100
In-Reply-To: <75196cfa-5476-0c7b-7612-ea2e446fc6f1@gmail.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.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> <75196cfa-5476-0c7b-7612-ea2e446fc6f1@gmail.com>
X-Mailer: Apple Mail (2.3259)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/SToKsc3cUY4P7ApVZlIFpGVL8hU>
Cc: 6man WG <ipv6@ietf.org>, IETF-Discussion Discussion <ietf@ietf.org>, Suresh Krishnan <suresh.krishnan@ericsson.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: Wed, 15 Feb 2017 21:34:09 -0000

Brian,

>>>>> Brian, changing the 64 bit boundary is such a big change that I would
>>>>> claim it is far outside the scope of advancing 4291 to Internet standard.
>>>>> 
>>>> 
>>>> Agreed.
>>> 
>>> Of course. The point is only that it's a parameter in the design of SLAAC,
>>> whose value is set by the address architecture.
>> 
>> If your statement is that we only have the 64 bit boundary because of SLAAC I believe you are wrong.
>> Can you provide any support for that view?
> 
> No, that's not what I'm saying. I'm saying that SLAAC - by design - would work
> with any reasonable IID length, but we've chosen to fix it at 64.
> 
>> If I understand you correctly, your proposal is to change the fixed 64 bit Interface-ID length in IPv6 to a variable one, with an exception for links where SLAAC is used.
> 
> No. At least not in the foreseeable future. But we should allow for the fact that if
> prefixes between /64 and /127 are used, routing needs to just work. That's all.
> 
>> How do you practically suggest to do this, given the issues raised in https://tools.ietf.org/html/rfc7421#section-4.1 ?
> 
> I'm not suggesting any change to normal subnets, where all those issues apply.
> I can't see how /64 can be changed for them, without changing a great many
> things.
> 
>> Do you think this change is appropriate in the context of advancing 4291?
> 
> I don't think I have suggested text that would lead to a single instruction in
> running code being changed.

CURRENT (RFC4291bis):

   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]

PROPOSED:

    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 unicast
   addresses used for Stateless Address Autoconfiguration [RFC4862] is required
   to be 64 bits long. The rationale for the 64 bit
   boundary in IPv6 addresses can be found in [RFC7421]


My reading of the proposed text, which certainly may be wrong, given that English is not my first language, is that it leaves the Interface-ID length of links _not_ using SLAAC undefined, i.e. not fixed at 64. Is there any other way to interpret this sentence?

The proposed text appears to make the Interface-ID length an operational choice.
How is that _not_ changing the 64 bit boundary?

Best regards,
Ole