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

Alexandre Petrescu <> Thu, 23 February 2017 12:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8A21A1296E8 for <>; Thu, 23 Feb 2017 04:25:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.332
X-Spam-Status: No, score=-0.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zEyNJQi8znYm for <>; Thu, 23 Feb 2017 04:25:35 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D36331296E0 for <>; Thu, 23 Feb 2017 04:25:34 -0800 (PST)
Received: from ( []) by (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v1NCPW9B023496 for <>; Thu, 23 Feb 2017 13:25:32 +0100
Received: from (localhost []) by localhost (Postfix) with SMTP id D4129207545 for <>; Thu, 23 Feb 2017 13:25:32 +0100 (CET)
Received: from ( []) by (Postfix) with ESMTP id CACDD2073C1 for <>; Thu, 23 Feb 2017 13:25:32 +0100 (CET)
Received: from [] ( []) by (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v1NCPWSx000397 for <>; Thu, 23 Feb 2017 13:25:32 +0100
Subject: Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard
References: <20170221001940.GB84656@Vurt.local> <> <20170221101339.GC84656@Vurt.local> <> <54c81141-e4f5-4436-9479-9c02be6c09bb@Spark> <> <> <> <4936e96b-fc82-4de0-9188-ced9547deb2f@Spark> <> <> <> <> <> <>
From: Alexandre Petrescu <>
Message-ID: <>
Date: Thu, 23 Feb 2017 13:25:24 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 23 Feb 2017 12:25:36 -0000

Le 23/02/2017 à 12:43, Wilco Baan Hofman a écrit :
> 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

In DHCPv6-for-addresses (not for prefixes) the prefix length field is

Some of the DHCPv6 Client code sets a 64 (hardcoded in C language) in
the source code when assigning that address to the interface.

That is completely wrong.

I suppose programmers having written this thought to themselves that
since SLAAC/Ethernet does that, and since RFC4191 reinforces it, then
why not DHCPv6 too?

They miss that DHCPv6 spec does not include a prefix length in their

> and should allow multiple addresses, at least in my opinion.

Yes, DHCPv6 should allow for multiple addresses.  It is the case.  But
no plen.

Also DHCPv6 Prefix Delegation is made to be able to request a prefix (a
P1/64, or a P2/63 or even a P3/3 - the plen is a parameter).  With that,
the Client is free to form addresses out of maybe P1 by setting an
Interface ID of a parametrable length, and delegate further something
out of a P3.

> 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.

It is a wrong assumption even right now to assume a /64 plen for a
manually configured address.  This has strong consequences on routing.

A host on a /120 subnet MUST NOT set /64 for manually configured
addresses, but /120; otherwise it can eat out of a subnet of someone else.

This is simply covered in the 4191 IPv6 Architecture by the statement
sayint that the Interface ID length plus the prefix length must equal
128.  120 plus 64 equals 184 which is different than 128.

> So we see SLAAC, ILNP and NPT66 requiring 64-bit prefix length.

Again, 64-bit in SLAAC is a side effect of using Ethernet with that
SLAAC.  SLAAC per se uses a parametrable prefix length.

As such, it is SLAAC/Ethernet requiring 64-bit prefix length.

For ILNP and NPT66 I dont know, but I thought I saw /48 in some Network
Prefix Translator implementation on linux.

> 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.

I would disagree, because we want these edge networks to further grow.

I would agree with a statement that says Ethernet can only work with
SLAAC if it has an IID of length 64.  One can not make an Ethernet
subnet with SLAAC and plen 65.  That is a problem of Ethernet - RFC2464
- and try to update it.  Otherwise it wont grow.

> 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.

I agree.

> 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.

I agree.


> -- Wilco
> --------------------------------------------------------------------
>  IETF IPv6 working group mailing list Administrative
> Requests:
> --------------------------------------------------------------------