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

Alexandre Petrescu <> Wed, 22 February 2017 10:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 13DB21296BD for <>; Wed, 22 Feb 2017 02:43:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.333
X-Spam-Status: No, score=-0.333 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] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LIRjfqHkEZxd for <>; Wed, 22 Feb 2017 02:43:34 -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 4974E12968C for <>; Wed, 22 Feb 2017 02:43:34 -0800 (PST)
Received: from ( []) by (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v1MAhW3J014534; Wed, 22 Feb 2017 11:43:32 +0100
Received: from (localhost []) by localhost (Postfix) with SMTP id 42CBA204EA1; Wed, 22 Feb 2017 11:43:32 +0100 (CET)
Received: from ( []) by (Postfix) with ESMTP id 34308203667; Wed, 22 Feb 2017 11:43:32 +0100 (CET)
Received: from [] ( []) by (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v1MAhWMH026185; Wed, 22 Feb 2017 11:43:32 +0100
Subject: Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard
To: Mark Andrews <>
References: <> <> <> <> <> <> <> <> <20170221001940.GB84656@Vurt.local> <> <20170221101339.GC84656@Vurt.local> <> <54c81141-e4f5-4436-9479-9c02be6c09bb@Spark> <> <> <>
From: Alexandre Petrescu <>
Message-ID: <>
Date: Wed, 22 Feb 2017 11:43:25 +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: Wed, 22 Feb 2017 10:43:36 -0000

Le 22/02/2017 à 11:15, Mark Andrews a écrit :
> In message <>,
> Alexandre Petrescu writes:
>> Le 22/02/2017 =E0 04:00, Lorenzo Colitti a =E9crit :
>>> On Wed, Feb 22, 2017 at 10:50 AM, Job Snijders <
>>> <>> wrote:
>>> Those "thousands of interconnections" facilitate the
>>> communication between millions of those hosts.
>>> But the configuration cost and management overhead is not
>>> proportional to the hosts that are served by those
>>> interconnections, it is proportional to the number of
>>> interconnections. A 10x100G peering interconnection that serves X
>>> million hosts is one interface that has to be managed.
>>> Have you considered that not all interconnections are equal? The
>>> type of interconnection I am mainly (but not exclusively)
>>> referring to is the interconnection between Autonomous Systems to
>>> facilitate the exchange of routing information using BGP-4.
>>> Autoconfiguration plays no role here, everything is configured
>>> explicitly. I'd argue that the use case is hardly comparable with
>>> a residential or mobile connection.
>>> Those use cases are very well served by /127 for PNIs and /64s
>>> for Internet exchanges. What's left?
>>> As pointed out in this thread, real networks use all kinds of
>>> prefix lengths. Also, one doesn't renumber everything every time
>>>  a new document comes out - you stick to things that work for
>>> you.
>>> As discussed above, most links use /64.
>>> Some vendors in this thread have admitted to strive to make
>>> things work with any prefix length, why is there then still a
>>> discussion that people must use /64 - when both vendors and users
>>> are not always doing so, for good reasons?
>>> You're forgetting about host operating system developers and host
>>> users,
>> I think you talk about users of hosts like smartphones, situated at
>> the edge of the Internet, not in the core.
>> In straightforward IP addressing architectures ("hierarchical"),
>> the prefixes of routes towards the edges are naturally shorter than
>> that 64: e.g. prefix /60 for site, /63 for building, /64 for office
>> desk.
> In a straight forward addressing architecture a site gets a /48 and
> sub entities request the numbers of /64's they need

Yes, that is when human planners make an architecture for a stable
situation, for a longer term like 10 years.

> and it uses a autoconfiguring routing protocol for routing traffic.

Except that edge computers caring about SLAAC/Ethernet/64 dont typically
run routing protocols, and even less autoconfiguring routing protocols.

> Homes and most sites don't need heirachical routing.  65000 routing
> entries should be able to be handled even by a $15 router.

Households: yes a 15eur a router can handle many routes;  but
househodls get one /64 from ISP, others get 16 such /64s, but no more.
However, the more IoT devices arrive the more subnets are needed in a
house network.  That will challenge the initial thoughts of the address
planners, again.

The /64 limit has become very popular thanks to SLAAC/Ethernet/64.  But
if one keeps the /64 limit in the standards one is bound to revisit the
initial address plans continuously.

If on another hand the /64 limit is removed, and SLAAC/Ethernet made to
allow for shorter-than-64 Interface IDs, or a new address autoconf
mechanism altogether (DHCP?), then one no longer needs to regularly
revisit initial addressing plans.  Well, maybe with a successor to
IPv6 but that would be much later.

>> In practice these hierarchical architectures are ideals hard to
>> implement. Because some hosts even in the core use
>> SLAAC/Ethernet/64, because edges expand, etc.
>> This makes that people need prefix lenghts of routes to lead to a
>> particular /64 carved out of some other prefix, instead of
>> aggregating. This leads to waste of publically routable space, or
>> to the use of ULA prefixes, or NAT66 prefixes, which have
>> inconvenients too.
>> Alex
> Or you just requests the prefixed you need and use a routing
> protocol.

Except it's not very sure to be able to dynamically request prefixes.

The places where this /64 limit is so visible, like cellular networks,
are precisely places where DHCPv6 Prefix Delegation is crucially absent.

Even if by specs (the theory) 3GPP mandates DHCPv6-PD, in practice
cellular operators oppose the use of DHCPv6-PD on smartphones.  The
reasons of this opposition are: one /64 is more than enough for many
devices (they dont understand SLAAC/Ethernet/64 and ptp links),
difficulty to revisit address plans, lack of DHCPv6-PD software at a
certain router manufacturer, etc.  One could write a 100-page report
about these reasons at cellular operators who dont reply to DHCPv6
PrefixDelegation requests.

Also, one could list a number of non-cellular network operators, and IT
departments, who also oppose DHCPv6 Prefix Delegation.  Each have their

Because of that, I propose to avoid painting ourselves in an "ivory
tower" and imagine one could dynamically request /64 prefixes at a snap
of a finger...



>>> both of which benefit substantially to having a subnet size that
>>>  is always the same and never runs out of addresses.
>>> I'm confident this discussion will eventually resolve itself and
>>> conclude that /64 is not the only valid prefix length, rigid
>>> positions rarely are attainable. Water can flow or it can crash.
>>> Even if you're right, the place to have that discussion is not on
>>> this document.
>>> --------------------------------------------------------------------
IETF IPv6 working group mailing list
>>> Administrative Requests:
>>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list Administrative
>> Requests:
>> --------------------------------------------------------------------