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

Alexandre Petrescu <alexandre.petrescu@gmail.com> Wed, 22 February 2017 10:43 UTC

Return-Path: <alexandre.petrescu@gmail.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 13DB21296BD for <ipv6@ietfa.amsl.com>; Wed, 22 Feb 2017 02:43:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.333
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LIRjfqHkEZxd for <ipv6@ietfa.amsl.com>; Wed, 22 Feb 2017 02:43:34 -0800 (PST)
Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4974E12968C for <ipv6@ietf.org>; Wed, 22 Feb 2017 02:43:34 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (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 pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 42CBA204EA1; Wed, 22 Feb 2017 11:43:32 +0100 (CET)
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 34308203667; Wed, 22 Feb 2017 11:43:32 +0100 (CET)
Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (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 <marka@isc.org>
References: <05FD5283-9A15-4819-8362-5E6B2416D617@employees.org> <CAKD1Yr3B+dw83B0+26oUqdVJE==wHUBwoWzfWBJep8f+=uM8xQ@mail.gmail.com> <d9dc153a-61a8-5976-7697-ce1ecc9c8f3f@gmail.com> <4AF83EE6-6109-491F-BE66-114724BB197B@employees.org> <75196cfa-5476-0c7b-7612-ea2e446fc6f1@gmail.com> <B4A4FFFD-A90D-4C26-BDBD-75555840CA22@employees.org> <m2wpcqeuot.wl-randy@psg.com> <44F7BEDA-CF11-4E1E-BA6F-88794DEC1AF7@employees.org> <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> <3af95cc0-d336-f0be-bd42-aeb2319452ad@gmail.com> <20170222101532.C7BDC64529C3@rock.dv.isc.org>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <58c4708d-2391-fafc-5921-17cfcc8f7e8b@gmail.com>
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: <20170222101532.C7BDC64529C3@rock.dv.isc.org>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/miEeQsVFXoc8m-ms_NzDvrhWuLY>
Cc: ipv6@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: Wed, 22 Feb 2017 10:43:36 -0000


Le 22/02/2017 à 11:15, Mark Andrews a écrit :
>
> In message <3af95cc0-d336-f0be-bd42-aeb2319452ad@gmail.com>om>,
> 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 <job@ntt.net
>>> <mailto:job@ntt.net>> 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
reasons.

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

Alex


Alex

>
>
>>> 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
>>> ipv6@ietf.org Administrative Requests:
>>> https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
>>>
>>
>>
>>>
>>>
>>>
>>>
>>>
--------------------------------------------------------------------
>> IETF IPv6 working group mailing list ipv6@ietf.org Administrative
>> Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------