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

james woodyatt <> Wed, 08 March 2017 22:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E64361294E8 for <>; Wed, 8 Mar 2017 14:38:25 -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=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vVn347eHdPUh for <>; Wed, 8 Mar 2017 14:38:23 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c00::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D67001294B2 for <>; Wed, 8 Mar 2017 14:38:23 -0800 (PST)
Received: by with SMTP id j5so20258131pfb.2 for <>; Wed, 08 Mar 2017 14:38:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=RteeBaso+lLaXwoaBDZY2/WlL2J75IVEwgVH5n9KOIM=; b=nh7RCG8+nWGblZyyAu91ve6d9QxoIJkaIk76YwXQFd+aDUSyHY9fshVIL6zZlPFAw7 Y27RKRKDV0vu/4vYPXC/5BNmi23DkIKaUhqQu3VKQZy1Bd8npjXwO8iBVaJXVKuSy2z9 MTS+5DDRM2FDj+I2haQBpSj2268eh3b/mnQTdgHlsvgrwdAizjSjWTVvMNzQEm3fTYfw mdHgug0mS327G26dWjWfRAA/m+CV8ENYLkMysSVkjxfCHkL6USTUQRpNxy0KStvERiF+ YMZQMNRn8GM6iNUrSfQ4MMnE3uCkfveeP/XgleLpZHp2wOSw1IHVv7RS+I0g9a4jEQhP trrA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=RteeBaso+lLaXwoaBDZY2/WlL2J75IVEwgVH5n9KOIM=; b=JiYscOPPN/jl3YjBoAo+IUFcr0qew5ONeYx1g8UbugtFpXc2ASaf/NnjoaIhZilWIG xZ8B9MyNv/7P372+x+CXJ6MtoEua++9BECZ0FqO0PtcB3bQspB77AcZISfMN9VJK08Zs ZXLV7mKbFPmB7tG3nrGDtLKbygK9yOcfuzO/wUi/U1lf+qFD8YLQ6N6KRwGxzrq1C9CI KS3olsB9LNrTZc1w38t7+MrKazADM0Mib5DRpbLalg+jN7Hel9bnZeUzoSGysV7LhKWs C+h8JCxhYMuRoZQ+EVp5wqSmVcX5PdovwYfQm6w+eOO8P5JeogSmv8oiMswJfN6KXMB1 ZN5w==
X-Gm-Message-State: AMke39nBCgnmcYYUd4v8QeVuD9qFT4KoTKl4ayfBNwszhsBoJwUY9KnKI4N0j74PemFin5cA
X-Received: by with SMTP id t22mr12274076plj.14.1489012703196; Wed, 08 Mar 2017 14:38:23 -0800 (PST)
Received: from ([]) by with ESMTPSA id a62sm8070214pgc.60.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Mar 2017 14:38:22 -0800 (PST)
From: james woodyatt <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_F3FBFB44-ECE4-4109-86AC-C64ABB098494"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Subject: Re: [v6ops] A proposal for draft-ietf-6man-rfc4291bis-07
Date: Wed, 8 Mar 2017 14:38:21 -0800
In-Reply-To: <>
To: Timothy Winters <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3259)
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 22:38:26 -0000

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:
> <>
> 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 < <>>