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

Alexandre Petrescu <alexandre.petrescu@gmail.com> Fri, 24 February 2017 14:57 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 AA65C129854 for <ipv6@ietfa.amsl.com>; Fri, 24 Feb 2017 06:57:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.353
X-Spam-Level:
X-Spam-Status: No, score=-5.353 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] 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 WLCGw5fNCCOK for <ipv6@ietfa.amsl.com>; Fri, 24 Feb 2017 06:57:48 -0800 (PST)
Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 558F3129697 for <ipv6@ietf.org>; Fri, 24 Feb 2017 06:57:48 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id v1OEvksH018928 for <ipv6@ietf.org>; Fri, 24 Feb 2017 15:57:46 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 00C8620B861 for <ipv6@ietf.org>; Fri, 24 Feb 2017 15:57:46 +0100 (CET)
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id E5A6420B858 for <ipv6@ietf.org>; Fri, 24 Feb 2017 15:57:45 +0100 (CET)
Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v1OEvjum011349 for <ipv6@ietf.org>; Fri, 24 Feb 2017 15:57:45 +0100
Subject: Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard
To: ipv6@ietf.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> <58c4708d-2391-fafc-5921-17cfcc8f7e8b@gmail.com> <20170224011024.6D6A66478B2E@rock.dv.isc.org>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <fc906d46-11f3-2af1-a3ca-91571d2c8bc8@gmail.com>
Date: Fri, 24 Feb 2017 15:57:36 +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: <20170224011024.6D6A66478B2E@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/_Ice8fUTM_5MZls7FCbmRjlrLvs>
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: Fri, 24 Feb 2017 14:57:51 -0000


Le 24/02/2017 à 02:10, Mark Andrews a écrit :
>
> In message <58c4708d-2391-fafc-5921-17cfcc8f7e8b@gmail.com>;, Alexandre Petrescu
>  writes:
>>
>>
>> Le 22/02/2017 à 11:15, Mark Andrews a écrit :
>>>
>>> In message <3af95cc0-d336-f0be-bd42-aeb2319452ad@gmail.com>;,
>>> 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.
>
> Except that is exactly what homenet does completely automated.

Except homenet still relies on SLAAC/Ethernet on end devices.

>>> 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.
>
> They also get /48's from the sane ISPs.  If your ISP is insane go find
> one that isn't.

/48 from sane ISP, but with drawbacks: tunnelling, right?

Alex

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