Re: I-D Action: draft-foglar-ipv6-ull-routing-00.txt

Mikael Abrahamsson <swmike@swm.pp.se> Fri, 15 September 2017 07:56 UTC

Return-Path: <swmike@swm.pp.se>
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 03E4013304B; Fri, 15 Sep 2017 00:56:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se
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 3IQ7l1xT5k01; Fri, 15 Sep 2017 00:56:55 -0700 (PDT)
Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (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 EDB1D13304A; Fri, 15 Sep 2017 00:56:54 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 9D09AB6; Fri, 15 Sep 2017 09:56:52 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1505462212; bh=Ss99ODra6OO30aJ8/iKwphRLQBI8cncrkCvdremssUU=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=mI2jYVrtbs4IXpN8AEoS5ry4/Y8+4bXxvxb1mr4hJ9cNli7tm0uisvT+Gc/mVSsG2 DdRtoNFxnZVhYtFM1Wf7GsC74r16hxeUFuC42NMNL3tLY05M11GPifF5qChsWHXcRG WSx9JkoHgls2tVGbWWCiUmrnk5gcUJo7N4tvXlVE=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 85CDDB5; Fri, 15 Sep 2017 09:56:52 +0200 (CEST)
Date: Fri, 15 Sep 2017 09:56:52 +0200
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
cc: draft-foglar-ipv6-ull-routing@ietf.org, 6man <ipv6@ietf.org>
Subject: Re: I-D Action: draft-foglar-ipv6-ull-routing-00.txt
In-Reply-To: <7e8fd49f-a777-fd9e-d410-be7e8d5958cc@gmail.com>
Message-ID: <alpine.DEB.2.20.1709150952110.29378@uplift.swm.pp.se>
References: <150523432567.17956.11322312258310497482@ietfa.amsl.com> <7e8fd49f-a777-fd9e-d410-be7e8d5958cc@gmail.com>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/ARaX8yct_VY2RMpI8wmHhUB4P78>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
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, 15 Sep 2017 07:56:57 -0000

On Fri, 15 Sep 2017, Brian E Carpenter wrote:

> "One of the goals of IPv6 was to have a sufficiently long address to 
> allow grouping in fields to simplify routing decisions."

Well, it's certainly used that way. If you go to an RIR you can ask for a 
lot more address-space than you can in IPv4 "to simplify routing".

So if I say "this device only sends /50 to the network, it has 48 ports, 
each port gets /56, that means I am never using a /52 out of this /50", 
then that's typically fine.

https://www.ripe.net/publications/docs/ripe-552#3

"3.4. Aggregation

Wherever possible, address space should be distributed in a hierarchical 
manner, according to the topology of network infrastructure. This is 
necessary to permit the aggregation of routing information by ISPs and to 
limit the expansion of Internet routing tables.

This goal is particularly important in IPv6 addressing, where the size of 
the total address pool creates significant implications for both internal 
and external routing.

IPv6 address policies should seek to avoid fragmentation of address 
ranges.

Further, RIRs should apply practices that maximise the potential for 
subsequent allocations to be made contiguous with past allocations 
currently held. However, there can be no guarantee of contiguous 
allocation."

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se