IETF Logo Mail Archive

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

Fernando Gont <fgont@si6networks.com> Fri, 09 June 2017 12:29 UTC

Return-Path: <fgont@si6networks.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 8A44A129AD7 for <ipv6@ietfa.amsl.com>; Fri, 9 Jun 2017 05:29:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 KxWEvTOygrAI for <ipv6@ietfa.amsl.com>; Fri, 9 Jun 2017 05:29:16 -0700 (PDT)
Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37C29129B06 for <ipv6@ietf.org>; Fri, 9 Jun 2017 05:29:16 -0700 (PDT)
Received: from [192.168.0.185] (unknown [105.50.131.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 669DD805AC; Fri, 9 Jun 2017 14:29:32 +0200 (CEST)
Subject: Re: draft-bourbaki-6man-classless-ipv6-00
To: otroan@employees.org, Brian E Carpenter <brian.e.carpenter@gmail.com>
Cc: 6man WG <ipv6@ietf.org>
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>
From: Fernando Gont <fgont@si6networks.com>
Message-ID: <6e03e25e-fd6a-6311-390e-4834281a76f7@si6networks.com>
Date: Fri, 09 Jun 2017 15:24:57 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1
MIME-Version: 1.0
In-Reply-To: <34A29D4D-3670-40BC-B62E-85C4EABC55D5@employees.org>
Content-Type: text/plain; charset="windows-1252"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/iZVRnLDPQtCNMLlPz_Qn1ud9E00>
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 12:29:18 -0000

On 06/09/2017 10:46 AM, otroan@employees.org wrote:
> 
>> On 6 Jun 2017, at 00:25, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
>>
>> On 05/06/2017 19:45, Lorenzo Colitti wrote:
>>> On Mon, Jun 5, 2017 at 8:05 AM, Brian E Carpenter <
>>> brian.e.carpenter@gmail.com> wrote:
>>>
>>>> None of that is the point. The point is to establish
>>>> that routing is classless
>>>
>>>
>>> Routing is already classless because BCP 198.
>>>
>>>
>>>> and /64 is a parameter of specific addressing schemes.
>>>>
>>>
>>> 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.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

v2.23.0 | Report a Bug | By Email