Re: [v6ops] A proposal for draft-ietf-6man-rfc4291bis-07

Timothy Winters <> Wed, 08 March 2017 23:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id ABC761294EC for <>; Wed, 8 Mar 2017 15:24:00 -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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id v6jY4am0lp89 for <>; Wed, 8 Mar 2017 15:23:58 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C5D4C1293EC for <>; Wed, 8 Mar 2017 15:23:57 -0800 (PST)
Received: by with SMTP id y76so94310953qkb.0 for <>; Wed, 08 Mar 2017 15:23:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=unh-iol; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=N53wkYM95CHJVIvDgDZXx2URrKdam6GURG3Ia8DZtnE=; b=IY5YHbkA7KeG4BkiG8rEmKRxMxXsGmj+X7HPpAjBgFNOVwODpYcB4XIi+/b6jwXMTe DdbBcHVjDqsCNlxjnJ/83AfbraLDP7nbmQrJ4QFvXDegwbPVju+4UeX4DLh90VPHydLF LLuQYe4ifP1GtnubRJVKgZWR55kugfa4DTdjs=
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=N53wkYM95CHJVIvDgDZXx2URrKdam6GURG3Ia8DZtnE=; b=IvrHnoAs3iI84MR6Ayy4WaekcknPi9YTLMHcDhRWCM3/aC4wRKh3sxgOziwKOCvRDQ kSKKzwogBdrefxkfIWjJVZvH6dIL1RJMwQR/ZfPGKbEiYDYv3aSgLr/Emo6/99Yt4vNq v58A5pZFnaV2NI8jeRq0XyItnaMO+LFt1EGXplpIP0Zl9zIrvIDdvdgL04hAvgkAXhcq wZbNzfHwrK8lVEiM2YD8alNAdVKSojWPcve4pYeRqMlk21UfBpGYtNuqudNkC2Q88ufc AGlQigTKqVhkvhveHi44z1Fb4nclS/YuKwxsjn6y3E5UarYwQqVtQH9RZH8l67Y0II9L JwjA==
X-Gm-Message-State: AMke39mpczCwLkJImkj4qpbXj3YGTrlrRfJGjhtz6wj0Zw56ASqsKxgf/oAGV97KGPJhnzcnNw1ZuDTm3aF0/cb4
X-Received: by with SMTP id f60mr11652692qtb.123.1489015436842; Wed, 08 Mar 2017 15:23:56 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Wed, 8 Mar 2017 15:23:55 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Timothy Winters <>
Date: Wed, 8 Mar 2017 18:23:55 -0500
Message-ID: <>
Subject: Re: [v6ops] A proposal for draft-ietf-6man-rfc4291bis-07
To: james woodyatt <>
Content-Type: multipart/alternative; boundary=001a1145c1942dc28b054a406c15
Archived-At: <>
Cc: 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, 08 Mar 2017 23:24:01 -0000

Hi James,

I look forward to the text, but it won't change the fact the 4861 expects
variable length for on-link determination.

This excerpt, from Erik Nordmark (author) seems to agree with that:

"we should hard-code the /64 boundary in as few places
as possible to allow for future evolution. Your 80 bit interface ID
on some new links is one example of possible future evolution.
Another example is cases where 20 years from now having less than 64 bit
interface IDs (or addresses allocated with DHCP from a >64 bit subnet
might fill a useful role.

Hard-coding the /64 address too me sounds like the original Arpanet design
with 8 bit network numbers and 24 bit host numbers; which was
first with class A/B/C and later with CIDR.
I don't know of a technical reason why /64 needs to be a hard limit."

I did some we have tested well over 500 IPv6 Implementations are the lab
and I'm aware of this failing 4 times ever. This doesn't cover the number
of devices that have failed inhouse and haven't come to the IOL.   It would
seem that almost all current devices support the ND interpretation, and
changing this might cause other Interoperability issues. That's my main
concern, and I'd have to think on this a bit more.  Maybe your text will
help clarify this...


On Wed, Mar 8, 2017 at 5:38 PM, james woodyatt <> wrote:

> On Mar 8, 2017, at 13:54, Timothy Winters <> wrote:
> Since this was added in the update from RFC 2461 to 4861 I went to go look
> for why this was added and found the following thread.
> Discussion:
> q=Requirement+for+64bit+I%2FF+ID&so=date&gbt=1&index=
> rJtLf5Krh0X9vg3vYts_xO1oUCw
> <>
> Final Decision:
> This is clearly about the spirit of this clarification, the working group
> when adding this text wanted to allow prefix lengths much larger then 64
> (80 is the example).
> I think the most we can say there is that the working group wanted to
> reserve power in the future to define new link types (or revise existing
> link types) to allow for standard use of an IID length other than 64 bits
> (for example 48 bits).
> There appears to be no evidence in that thread that the working group
> wanted to REQUIRE hosts to accept PIO elements for purposes of on-link
> determination even when their Prefix Length is invalid for address
> configuration on the link type in use.
> I discussed this in detail in my long previous message reviewing this text.
>   <>
> The relevant excerpt of my previous message follows:
> But we’re not done. RFC 4862 continues:
> >> It is the responsibility of the system administrator to ensure that the
> lengths of prefixes contained in Router Advertisements are consistent with
> the length of interface identifiers for that link type.
> I do not read this as any requirement on the host implementer to
> accommodate system administrators who use Prefix Length values that are not
> consistent with the IID length defined for the link type in use.
> >> It should be noted, however, that this does not mean the advertised
> prefix length is meaningless.
> This is informative and helpful, and not normative text.
> >> In fact, the advertised length has non-trivial meaning for on-link
> determination in [RFC4861] where the sum of the prefix length and the
> interface identifier length may not be equal to 128.
> Indeed, as I read RFC 4861, this recognizes *explicitly* that hosts MAY
> use advertised prefixes with invalid Prefix Length for address
> configuration, for example, for the purpose of on-link determination.
> >> Thus, it should be safe to validate the advertised prefix length here,
> in order to detect and avoid a configuration error specifying an invalid
> prefix length in the context of address autoconfiguration.
> This is not in conflict with the observation of RFC 4861 that processing
> Prefix Lengths for on-link determination that are invalid for address
> configuration is not REQUIRED and merely OPTIONAL.
> >> Note that a future revision of the address architecture [RFC4291] and a
> future link-type-specific document, which will still be consistent with
> each other, could potentially allow for an interface identifier of length
> other than the value defined in the current documents.  Thus, an
> implementation should not assume a particular constant.  Rather, it should
> expect any lengths of interface identifiers.
> As I read this excerpt, this is RFC 4862 expressly recognizing that future
> standards action could introduce new valid IID lengths for address
> configuration other than 64 bits. This hasn’t happened yet. (And there is
> still some controversy about whether RFC 4291 should not be revised unless
> it is changed to do so.)
> In a forthcoming message, I will propose text for inclusion in
> I-D.ietf-6man-rfc4291bis with the hope that it may help clarify this matter
> further.
> --james woodyatt <>


Now offering testing for SDN applications and controllers in our SDN switch
test bed. Learn more today