Re: Objection to draft-ietf-6man-rfc4291bis-07.txt

Lorenzo Colitti <> Wed, 01 March 2017 09:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4B0941298C0 for <>; Wed, 1 Mar 2017 01:51:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Rco8wFjnwQDv for <>; Wed, 1 Mar 2017 01:51:54 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6B8311298A9 for <>; Wed, 1 Mar 2017 01:51:54 -0800 (PST)
Received: by with SMTP id x75so6355049vke.2 for <>; Wed, 01 Mar 2017 01:51:54 -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=pd40y9JgV/txQdRMXaFUgai7ZIBVh1rqaSW58XvN+mE=; b=Wjmz1j9uK6UmFK4uuO5vrsx1kbTIAc6rTXtCBbIegTnfNQTA33zyawmhcpiys86qSz 3CrG5JmvhdI75COgVRYAZ0BWyF/BYz+7e941dNA8y3CiuWZ1H76s0OYUrYMHXeFhHQeC lhYIK9vQuK0AoIbGv2Zi7lUdIuTflXH4/SAl9NqQNoLX+x05o6tY5GiKnSwKIQJRboR5 aq2v8l+A7FmMxQSOV+hjhk/AAIni887c3o5S86Z1W7cXnOo7F4N1UcnB1ISNLmlugM7q r8X9ERPBdzpxHg49mNGzqNffHJVRF3dXlyyG9uxV1cw3Zyv/3C68KH7CBEZand6T3dMZ MDEw==
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=pd40y9JgV/txQdRMXaFUgai7ZIBVh1rqaSW58XvN+mE=; b=qyIU5kW4OtVgIfMAmdoA+/oEqD6HWrnkS/Mpma9owtFJfxxIYA2GcikjleuDfQbnGF oN8F3IkBHYHlIRvO+vxGtEB/mAj3B7jWGfeweAvFqIrZ5sAwbUVq26hdKOxu2GO4v8im U1BXlEzkLQZX5+KuF9vr63mgs8Nt/iTOVDztYI73upEZeQUa4dFDRSCTk9diF5QcHPgO L9DmDeZ1XVL3PXwsFxr7r5ZyT3Y0wuKhAauQ1Im2UBGmk4qQW0Gt8HNu0HIJKpymwmHw FMZHeMcvkIn68kBiLSqsSLXbX2r6DokNmSgK89dvigoV5hrfvXC1Mv6r94tvI2kn8zwy Kt4A==
X-Gm-Message-State: AMke39lJtvj899rdHQrlb2349R03UlrleW9mMXkEdrofKo4e9McDjZLG26PjJHFA0E/THMhTXujQeXejd9GHDxjW
X-Received: by with SMTP id y128mr2898816vkd.102.1488361913341; Wed, 01 Mar 2017 01:51:53 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Wed, 1 Mar 2017 01:51:32 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <>
From: Lorenzo Colitti <>
Date: Wed, 1 Mar 2017 18:51:32 +0900
Message-ID: <>
Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt
To: David Farmer <>
Content-Type: multipart/alternative; boundary=001a1141d60024ba920549a84307
Archived-At: <>
Cc: james woodyatt <>, 6man WG <>
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, 01 Mar 2017 09:51:56 -0000

On Wed, Mar 1, 2017 at 5:33 AM, David Farmer <> wrote:

> However many OSes also allow configurations other than just /64, is this
>>> OK? Is that how RFC4291 should be interpreted? Honestly, I don't read it
>>> that way,
>> IMO the important question is not "should an OS refuse to configure a /65
>> when manually configuring an address". I think the much more important
>> questions are, "can the OS assume that it can use the full 64 bits to form
>> an IID", and "will this link ever run out of IPv6 addresses". The answers
>> to those should be yes and no.
> I don't disagree with your answers, and you may not think the manual
> config question is important, but others seem too.

FWIW I wouldn't oppose an exception for manually-configured addresses on

And you don't have too.  But, your saying no one else can ever have a
> reason to do that, and I'm not so sure about that.  And something on the
> other side of the Internet can't make any assumption about what I'm doing
> anyway.  You are saying it can't be done because the 64 bit boundary is
> even more important than CIDR and addresses on the other side of the
> Internet are supposed to be opaque.  Where as I disagree, CIDR and the
> opaqueness of addresses across the Internet are more fundamental properties
> than 64 bit boundary.  Which is why I say the 64 bit boundary is really a
> RECOMMENDATION.  And CIDR and the opaqueness of addresses across the
> Internet are REQUIREMENTS.

Let's see if there is common ground here. I agree that routers should
forward on arbitrary prefix lengths. It's probably reasonable that hosts
should not make assumptions about other host's IP addresses (except if they
are on the same subnet). But I think a host should be allowed to assume
that its own subnet and its own IID are 64 bits long.

>> Another thing I think we should avoid is to remove the fixed 64 barrier
>> and open the door to having this debate again and again, once for every new
>> IPv6-over-foo document and once for every new address configuration
>> protocol (today we have SLAAC and DHCPv6, who knows what we'll have in the
>> future).
> Which is why it time to get this right and saying it is now and forever 64
> isn't right.

Do you agree that a fixed boundary is useful or not? For 20 years the
standards have guaranteed that 64 bits of IIDs were available to hosts that
wanted to use them. If we make that barrier mobile, there will be no
guarantee in the standards any more. Who should be allowed to set the
boundary? An IPv6-over-foo document? An address configuration technology
such as SLAAC? An ISP that wants to charge you $1 for every /128 you use?