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

Lorenzo Colitti <> Wed, 22 February 2017 14:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 10EB612996B for <>; Wed, 22 Feb 2017 06:17:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dt4tYNHK7v40 for <>; Wed, 22 Feb 2017 06:17:34 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0CF2F12996E for <>; Wed, 22 Feb 2017 06:17:32 -0800 (PST)
Received: by with SMTP id x75so2248832vke.2 for <>; Wed, 22 Feb 2017 06:17:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fJbShjzwAajr/xL5MEq/GUDSXh6xW4h+W6Yd/O51O6I=; b=ici1Do7ereyVVLU++2M3rEDXtlgCTm6AmxA7WHA2zqxtd0SrCNEZTojL7mvxUum/rN C9W7AjZaXmtwNohFz8OD7EqVcIDj1Ap9myaJy/NpQCePDjJ05qnEebfGTKU8jDn6EzvI W9xedEWRFORlsmEoOXWx5tgVqNFPd/l0UGDX0JrmL+bqPaz9ZMvJW17H4EUuyeWc5pRu 77FtJZFbRGnN6WMUlTHCjTkwu8/SR5qMa6eZgLiAeYD2WufFq91qLM0Sxe8m9tfBvR+F 4PAtpy7KQw+Ixw+MkBCuoRrwULi2FCVYCypFpE276yQ7jWKicr1ggo4iZMCGl8tC8Pks H5XQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fJbShjzwAajr/xL5MEq/GUDSXh6xW4h+W6Yd/O51O6I=; b=CBPDdICm8DvBS8G+8i70vZJadJk+mAid8VnC6p1oVfLTKDVzaosDVl0HGTd0n6VExz Y9pTxqClvapgFAbI2ZAoZkg+F9+16dnCde4dipD/4O3ytTtqSF6P14SEZxq7fSQFhHUT sDL6kuMMvnPU8Im74JVRZQBvLSo0siVDtTKKUI1IYxXhMJbH9g1ED3CejHLQfixxpGEg 5D32H4M5YEb8fnJK/8SJ5Di3mBMwsmNn0I3TMAeuRlrjxs5acWx2/jQM2xpu5heqUusF gB2N2bb03ot00mwydgjXumJRqtUwG8k6UAGql7dde1v7hRvQKdAk5pcsaBtcss2Hj0rm mOtw==
X-Gm-Message-State: AMke39n+YqsZKy1XL+xiIkg6ZyZdI54vTAEoT6f8ENmr266v72y2uBCWS4TcGXHlnSRwlmD9ZdZxoomxNy1oyU8c
X-Received: by with SMTP id i188mr12227960vka.45.1487773050823; Wed, 22 Feb 2017 06:17:30 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Wed, 22 Feb 2017 06:17:09 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <20170221001940.GB84656@Vurt.local> <> <20170221101339.GC84656@Vurt.local> <> <54c81141-e4f5-4436-9479-9c02be6c09bb@Spark> <> <> <> <>
From: Lorenzo Colitti <>
Date: Wed, 22 Feb 2017 23:17:09 +0900
Message-ID: <>
Subject: Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard
To: Christopher Morrow <>
Content-Type: multipart/alternative; boundary=001a1142f17833d3d305491f28bc
Archived-At: <>
Cc: 6man WG <>,,, IETF-Discussion Discussion <>
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 14:17:35 -0000

Host developers and users do care what the prefix length is.

There are lots of things you can do if you know that the network will never
run out of addresses. For example, you can form new addresses at will and
use them for anything you want (privacy; per-application addresses, or
whatever else you can think of). Read RFC 7934 for a list of the things
we've thought of so far, and bear in mind that if this IPv6 thing even only
lasts as long as IPv4, that's still several decades, and I'm sure we'll
have lots of bright ideas during that time if we don't shortsightedly carry
over IPv4 practices motivated by address scarcity.

A fixed prefix length is also very beneficial because it allows hosts to
extend the network indefinitely at layer 2 without giving up the benefits
provided by autoconfiguration and end to end connectivity. It means that
ill-informed or ill-intentioned network administrators cannot use
addressing to constrain apps in a way that leads to suboptimal user
experience. That sort of thing obviously does not happen in the 2914 or
15169 backbone. It does happen in lots of other places.

On Wed, Feb 22, 2017 at 1:44 PM, Christopher Morrow <> wrote:

> On Tue, Feb 21, 2017 at 10:51 PM, Lorenzo Colitti <>
> wrote:
>> On Wed, Feb 22, 2017 at 12:12 PM, Christopher Morrow <
>>> wrote:
>>> 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.
>>> isn't the dicsussion here really:
>>>   "If you want to use /64 go ahead, if you want to use /121 go for it,
>>> if you want to use SLAAC you'll get a /64 and like it"
>> Not sure. I for one wouldn't agree with that position, because I don't
>> see that /121 has enough advantages over /127 and /64 - and few enough
>> downsides for general-purpose hosts - to make it a good idea in general.
> I don't think /121 is anymore special than /127... or /64. My point was we
> don't care what prefix people use, generally, that there are cases where a
> /64 is required and that's fine, there are cases where /64 isn't and people
> can do what they want there.  It's simple enough to do SLAAC/64 on lans and
> other places.
> Requiring /64 or /127 and nothing else means when you do have to do a /120
> or something else you MAY end up fighting vendor problems because they made
> assumptions about: "only ever 64 or 127".