Re: draft-bourbaki-6man-classless-ipv6-00

Brian E Carpenter <brian.e.carpenter@gmail.com> Sun, 11 June 2017 23:17 UTC

Return-Path: <brian.e.carpenter@gmail.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 5541112945C for <ipv6@ietfa.amsl.com>; Sun, 11 Jun 2017 16:17:09 -0700 (PDT)
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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 cN-71KyNb7Jr for <ipv6@ietfa.amsl.com>; Sun, 11 Jun 2017 16:17:07 -0700 (PDT)
Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::229]) (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 74A4B12945B for <ipv6@ietf.org>; Sun, 11 Jun 2017 16:17:07 -0700 (PDT)
Received: by mail-pf0-x229.google.com with SMTP id 83so45235242pfr.0 for <ipv6@ietf.org>; Sun, 11 Jun 2017 16:17:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=p5zq6B/0DKtB4NfkmsLn0fAslboX/Z/VyhXSj/HsbRw=; b=WIsEoQnp5B8ESWaLf/8saTpXu//BZnfnvivz+QvP1RR5ScrK6WySVPP9BaeaKJxBOC Px+SYYLyCm09vPV5cY0aHwR+Gx1Y2JIkFkcF6VXJ8GPQTKy/DdMwja3xRNUjNt2Lp1fd mlLlS/OME0L3o9chnwjie/Zb6DZ3xkKmEKY0u257RCTSwu6Xt/QlcDCLCGmnlJMnyO34 TrKjAwUDwY/ckr8H7mD1PaP7jqH5qtx/duuOmnWA69M0/14xPpNzhuIeeh28stJzzzQL Fg62KMNrcMEjz8ZZPYiw+e+YXPbxt6RMDnmrgoMtflOwcsQXevCWlpwAyYEBCa9ZnoOL wCnQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=p5zq6B/0DKtB4NfkmsLn0fAslboX/Z/VyhXSj/HsbRw=; b=GnCPKMO5znIrsOKepKn2jsG+rezSINO2aTGDmNSlHyce/QZ8OeFoGBaPcntj2UYVPr jkFB7T+uyDFGCVlJc07rTChnBAkSyfkY3yrDg0xkiqPhVY0sWQfMS9pdW3PtgI44S/69 D8wMSmOhYwnXSdlFaEVL6nUcjUbf7JXeLGZ2wvt5Zsvg5hEJplSowU2Kh8NE1oGxj//m MZEPffL2oGgifGlUhrBuUTY5pCFxYme4MiyphfEymSZ67o+OR6nIGU0d14PI5AqDSrQd Tla6x+yKfB2RZ4UyIrCb1zkVVWWb116lPFUUhweI/D4rZ0LM836K+cqWW3A013YHKcui WerQ==
X-Gm-Message-State: AODbwcAZ9OCw8JeDyBDVoIaNAK6ff8D3FG/ERnUOsep0DizIRHuCqEm1 WPtzk/oIrHwjd6cz
X-Received: by 10.84.130.99 with SMTP id 90mr53062292plc.165.1497223026733; Sun, 11 Jun 2017 16:17:06 -0700 (PDT)
Received: from [192.168.178.21] ([118.148.117.140]) by smtp.gmail.com with ESMTPSA id i68sm16454463pfi.72.2017.06.11.16.17.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 11 Jun 2017 16:17:05 -0700 (PDT)
Subject: Re: draft-bourbaki-6man-classless-ipv6-00
To: "Manfredi, Albert E" <albert.e.manfredi@boeing.com>
Cc: 6man WG <ipv6@ietf.org>
References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170604093119.nt733rb3ymmjssww@Vurt.local> <m1dHTLx-0000DcC@stereo.hq.phicoh.net> <CAKD1Yr0ZZwRar6D-2bkXBKPYehqqW99+BMtDOjyovR8WDXKzxw@mail.gmail.com> <CAD6AjGTjikAWutcenW8qn7OW8kPM9c_x_yDUy5vQxJmXKL85dg@mail.gmail.com> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <CAKD1Yr0_WR_TB+OC0U1Qt2h6WzUp9EGvrqC1ZKW2mwFeBd3bCQ@mail.gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <34A29D4D-3670-40BC-B62E-85C4EABC55D5@employees.org> <6e03e25e-fd6a-6311-390e-4834281a76f7@si6networks.com> <1B580CBB-B29D-4860-9EC8-BECD1D5E0006@employees.org> <4b2f5200-86a1-7711-e5ff-7436572be467@gmail.com> <E02C4C99-155A-4358-A845-F00F8BB071C1@employees.org> <b3ca5271-21b1-ab33-2dff-82735ebe9128@gmail.com> <235143da452c4ff4aec39a26ba918e7e@XCH15-06-11.nw.nos.boeing.com> <1489a50a-2616-f9ac-4109-16c595e15f90@gmail.com> <df8830b80f714a369be3b9f5ba311b11@XCH15-06-11.nw.nos.boeing.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
Message-ID: <0f8b7aa0-b9bb-4d6f-f8fa-597faead2108@gmail.com>
Date: Mon, 12 Jun 2017 11:17:01 +1200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1
MIME-Version: 1.0
In-Reply-To: <df8830b80f714a369be3b9f5ba311b11@XCH15-06-11.nw.nos.boeing.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/dfgfWanONBhdKcDfO2QTntUcTRI>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
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: Sun, 11 Jun 2017 23:17:09 -0000

On 12/06/2017 10:14, Manfredi, Albert E wrote:
> -----Original Message-----
> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] 
> 
>>> I think there are practical alternatives, so I too would suggest
>>> not to state flatly that SLAAC requires fixed length IIDs.
>>> Anything that requires RAs to work can make adjustments to its
>>> IID, in real time.
>>
>> It cannot adjust its IID length when assigning itself a
>> link-local address *before* receiving any RA/PIO messages.
> 
> True. Clearly.
> 
>> But whatever length N of IID it uses to generate its LL
>> address must match the the prefix length 128-N in a later
>> RA/PIO with A=1. Otherwise, SLAAC fails. (see Section 5.5.3
>> bullet d of RFC4862, as Jinmei-san kindly explained to me.)
> 
> Section 5.5.3 states that the prefix length of a valid prefix must be 128-N bits wide, where N is the number of bits of the IID. Then it states that it's the responsibility of the system admin to ensure that prefix lengths are consistent with the IIDs for that link type.
> 
> Now, what prevents a link type from having multiple available IID lengths, ready to go, to match varying prefix lengths that might be available? The basic rules are the same. The only difference is that we are no longer held to just one length of IID (for the link type). So it becomes also the host's responsibility, to use an IID length consistent with the length of prefix offered. 
> 
>> So in fact the only thing that works is if the equipment
>> assumes the same IID length as the router announces (as 128-N).
>> Therefore, N must be predefined.
> 
> That's the way it works now, but it's hardly the only way it can be made to work. Similarly, IPv4 did not have to remain classful, because that's the way it had been. IP stacks were upgraded, and CIDR became the rule.
> 
>>> ULAs and link local would need to create IIDs with no
>>> knowledge of the outside world. But not SLAAC.
>>
>> ULAs have nothing to do with it; SLAAC doesn't care whether a
>> prefix is ULA or globally reachable.
> 
> I think you missed my point. When the host forms either a ULA or a LLA, the host must do so with no knowledge of anything external to itself. 

Absolutely not, for a ULA. A ULA is simply a global scope address which
happens to lie under a ULA prefix, which is today just another /64 that
comes from a completely standard PIO. A host could form a ULA using SLAAC,
in which case the prefix comes from a completely standard PIO with A=1.
(A host could also receive a ULA via DHCPv6, or it could even be manually
configured, but in those cases it's just like any other global scope
/128.)

    Brian


> So sure, the IID in those two examples has to be predictable. Instead, there is no valid reason for the IID used in SLAAC to have to be formed independently that way, other than "that's how it's done now."
> 
> Once we are freed from the IPX-legacy notion of the IID being formed from the hardware address of the interface, all these preconceived restrictions, derived from that deprecated notion, can be eliminated. Variable length IIDs are ideal for a system with variable length prefixes. Why should we deprecate IPv6 to something less flexible that it can be?
> 
> Bert
>