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

Mark Andrews <marka@isc.org> Fri, 24 February 2017 01:10 UTC

Return-Path: <marka@isc.org>
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 A2BD41293F3 for <ipv6@ietfa.amsl.com>; Thu, 23 Feb 2017 17:10:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.902
X-Spam-Level:
X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 DqMSdATgERe7 for <ipv6@ietfa.amsl.com>; Thu, 23 Feb 2017 17:10:35 -0800 (PST)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84860129417 for <ipv6@ietf.org>; Thu, 23 Feb 2017 17:10:35 -0800 (PST)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.ams1.isc.org (Postfix) with ESMTPS id 3182024AE0A; Fri, 24 Feb 2017 01:10:31 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 2FC8716004F; Fri, 24 Feb 2017 01:10:30 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 167FD160070; Fri, 24 Feb 2017 01:10:30 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 9FfRlAKf27zs; Fri, 24 Feb 2017 01:10:30 +0000 (UTC)
Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 3088B16004F; Fri, 24 Feb 2017 01:10:29 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 6D6A66478B2E; Fri, 24 Feb 2017 12:10:24 +1100 (EST)
To: Alexandre Petrescu <alexandre.petrescu@gmail.com>
From: 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> <58c4708d-2391-fafc-5921-17cfcc8f7e8b@gmail.com>
Subject: Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard
In-reply-to: Your message of "Wed, 22 Feb 2017 11:43:25 +0100." <58c4708d-2391-fafc-5921-17cfcc8f7e8b@gmail.com>
Date: Fri, 24 Feb 2017 12:10:24 +1100
Message-Id: <20170224011024.6D6A66478B2E@rock.dv.isc.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/PNESDDiZkbwffY5W2eAAaruZK2s>
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: Fri, 24 Feb 2017 01:10:37 -0000

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.

> > 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.
 
> 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
> >> --------------------------------------------------------------------
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org