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

Wilco Baan Hofman <wilco@baanhofman.nl> Thu, 23 February 2017 11:43 UTC

Return-Path: <wilco@baanhofman.nl>
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 C1BB01296FA; Thu, 23 Feb 2017 03:43:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level:
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 MY9Ewklz1d9D; Thu, 23 Feb 2017 03:43:13 -0800 (PST)
Received: from vps.baanhofman.nl (vps.baanhofman.nl [92.222.219.102]) by ietfa.amsl.com (Postfix) with ESMTP id 90DA812A164; Thu, 23 Feb 2017 03:43:13 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by vps.baanhofman.nl (Postfix) with ESMTP id 6AFC51041AB5; Thu, 23 Feb 2017 12:43:12 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at vps.baanhofman.nl
Received: from vps.baanhofman.nl ([127.0.0.1]) by localhost (vps.baanhofman.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nRFjLQz-RiNP; Thu, 23 Feb 2017 12:43:10 +0100 (CET)
Received: from [IPv6:2001:610:120:3001:5d68:ec82:edc8:5d71] (unknown [IPv6:2001:610:120:3001:5d68:ec82:edc8:5d71]) (Authenticated sender: wilco) by vps.baanhofman.nl (Postfix) with ESMTPSA id BB1B31041AAD; Thu, 23 Feb 2017 12:43:10 +0100 (CET)
Subject: Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard
To: Philip Homburg <pch-ietf-6@u-1.phicoh.com>, ietf@ietf.org
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> <m1cgqW5-0000MkC@stereo.hq.phicoh.net>
From: Wilco Baan Hofman <wilco@baanhofman.nl>
Message-ID: <fb53226a-f798-5a61-afaa-99456d7e9000@baanhofman.nl>
Date: Thu, 23 Feb 2017 12:43:17 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.4.0
MIME-Version: 1.0
In-Reply-To: <m1cgqW5-0000MkC@stereo.hq.phicoh.net>
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="NpA95HFXSvAaBS2tENK7dlrgUFGFAUHIR"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/Nfe3bp4ca4OcgpkuMg32vnaxoHY>
Cc: 6man WG <ipv6@ietf.org>, 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: Thu, 23 Feb 2017 11:43:22 -0000


On 23/02/17 11:20, Philip Homburg wrote:
>>> 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.
>
> I'm curious about the issues the host developer faces.
>
> 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.
For stateful DHCPv6 the prefix length should also be /64 and should
allow multiple addresses, at least in my opinion. And I have seen
several devices that only allowed configuration of /64 prefixes
(printers, etc) for even static addresses, which is a perfectly valid
assumption right now.

So we see SLAAC, ILNP and NPT66 requiring 64-bit prefix length. But
these cases all cover edge networks, with hosts, printers and similar
nodes. Keeping the requirement (or moving to SHOULD) for edge networks
seems reasonable to me.

However, this does not make the carrier use case any less relevant. The
main problem with /64 is TCAM exhaustion through ND attacks. Because NDP
follows a multicast discovery model, it simply does not scale up to 2^64
addresses in a subnet when being scanned/attacked. A subscription model
(like WiFi proxyNDP does) would scale a lot better. This is something
that needs to be addressed as well, separately.

Another problem carriers face is that /127 can not be configured on a
lot of routers, because of the subnet router anycast requirement that
was only lifted for /127 with rfc6164 in 2011. That means that
operationally people go out-of-spec, because frankly, going out-of-spec
works more reliably and consistently.

And because /64s don't really work for inter-router-links because of the
attack surface, and /127s don't really work because of older routers,
people will start configuring /126 for inter-router-links and /125 and
(slightly) shorter for VRRP and for BGP sessions with multiple routers.

In my opinion, there should at least be some room in the IPv6 standard
for arbitrary prefix lengths for interconnects.

-- Wilco