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

otroan@employees.org Fri, 09 June 2017 19:21 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 E7B72128D69 for <ipv6@ietfa.amsl.com>; Fri, 9 Jun 2017 12:21:02 -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, 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 Iye2u57SgUPI for <ipv6@ietfa.amsl.com>; Fri, 9 Jun 2017 12:21:01 -0700 (PDT)
Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id 407C6128ACA for <ipv6@ietf.org>; Fri, 9 Jun 2017 12:21:01 -0700 (PDT)
Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 09 Jun 2017 19:20:59 +0000
Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 95ECFD788D; Fri, 9 Jun 2017 12:20:59 -0700 (PDT)
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=mOcHK95qILAyUtoO3NGtuMpBUgA=; b= eOFFx2LIDCpsR3HDGC/TURPFm/a91f+SZccF+EDmPpt2P0UsncA50K4kOpsFOpTt YmFczwHPzgrZ/GUHpXrMMdsMk+zhfIo3AhenT8LSlaoWo3BJZZEKM7K5ssnQkhq1 fhmGef+F7vMi/2NZEFLaBkqUNdeicp9c3Yl3/+G9nf4=
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=XCs5HZ9gME4YFgg7SbDijQd d58DE/cnWXdYliV4yv8fBUaQcuQ9DN0G+PxFH46NyOpHWBIDJz8+5kmYYRwVdlji YMBUQs3ADFKektIP9FL0bo1uKxLX8xn1u7z/Y7R401kJrNC/0L/ZM9CbyR2x4d9w ylO/4scBekS7mUXGUGOE=
Received: from h.hanazo.no (77.16.70.76.tmi.telenormobil.no [77.16.70.76]) (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 BD3C9D788B; Fri, 9 Jun 2017 12:20:58 -0700 (PDT)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 36F09D0E0F85; Fri, 9 Jun 2017 21:20:56 +0200 (CEST)
From: otroan@employees.org
Message-Id: <AD1E871C-0AC5-416C-B3FB-E91FF4F48FD5@employees.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_225DAE45-7C5D-4D53-886A-33BA3A630295"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: draft-bourbaki-6man-classless-ipv6-00
Date: Fri, 09 Jun 2017 21:20:55 +0200
In-Reply-To: <dd6706e1-fc1e-0921-d74d-87e18088f44e@si6networks.com>
Cc: Brian E Carpenter <brian.e.carpenter@gmail.com>, 6man WG <ipv6@ietf.org>
To: Fernando Gont <fgont@si6networks.com>
References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <CAKD1Yr0DtQYvCYLQexhXe_nhb5rjeyhnB4bCveqyO5Xbuwdg1A@mail.gmail.com> <CAKFn1SEdjhsQ3tKPZdbdfF4ArDzw-FZfjQT68gV55Fc-5vzBvw@mail.gmail.com> <CAKD1Yr3ppM0UF8HoN8PgS7F0iEmK26ebiuJK=tkAdZnuLWpkZg@mail.gmail.com> <CAKFn1SHASt34ihJmGN0iRFQQzLTMspZfxXHgBjBatXXcRYF4cw@mail.gmail.com> <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> <dd6706e1-fc1e-0921-d74d-87e18088f44e@si6networks.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/HghCoBSPTH8JKLBMiT8wfG1kafw>
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: Fri, 09 Jun 2017 19:21:03 -0000

> On 9 Jun 2017, at 20:52, Fernando Gont <fgont@si6networks.com> wrote:
> 
> On 06/09/2017 09:25 PM, otroan@employees.org wrote:
>>>>>> It *is* a parameter. The parameter's value is 64 for all unicast addresses
>>>>>> except those starting with 000.
>>>>> 
>>>>> The parameter's *current* value, yes. But should we really be fixing
>>>>> the value of the parameter once and for all in the addressing architecture?
>>>>> Why don't we fix it in each IPv6-over-foo, which is what the SLAAC design
>>>>> assumes?
>>>> 
>>>> do we have a rationale for fixing the value in the IPv6-over-foo documents (anymore)?
>>> 
>>> At the time of this writing, we should probably be in the camp of "If
>>> you do slaac, better stick to 64, since it's know to work with legacy
>>> implementations, and besides, allows for sparse allocation (reduced
>>> collisions of IIDs when you pick a random one, resistance to address
>>> scans, etc.).
>>> 
>>> There's no compelling technical argument for mandating /64 (i.e., such
>>> specific value) if you do manual configuration or, for instance,
>>> stateful DHCPv6. And the recommendation for /64 for slaac mostly has to
>>> do with backwards compatibility than with anything else.
>> 
>> your goal is to remove the 64 bit boundary from RFC2464 et al and update RFC4862?
> 
> No. I'm just saying that such specific value is an historical artifact,
> not a technical one.
> 
> It's fine for the /64 to stay for slaac -- although the more clear we
> make it that its a parameter, rather some value that came from an
> oracle, the better.

There are many reasons why there is a fixed split between what the network gets and what the hosts gets. It's part of a tussle.
As well as to allow for 8+8. I don't see that the particular tussle has changed much over the last 20 years, nor the reasons for 8+8.

Any credible opponent of the fixed 64 bit boundary must answer the issues laid out in RFC7421.

Also the players on network side of the tussle must give credible reasons for why 64 bits isn't enough for them.

Brian assured us the draft isn't about this. Hard to say from the draft and it seems you are of a different opinon.

Ole