Subject: A proposal for draft-ietf-6man-rfc4291bis-07

From: David Farmer <[email-masked]>
Date: Thu, 2 Mar 2017 16:43:49 -0600

I've been thinking about this, really hard, and listening to what others
are saying. I think we want to say the following;

1. IPv6 unicast routing is 128 bits in length [BCP198], AKA not classful!
2. Subnet Prefixes of 64 bits are RECOMMENDED
3. IIDs are REQUIRED to be 64 bits
4. Say nothing that would imply you cannot configure a prefix length longer
than 64 bits in length, at least manually.
5. Avoid all explicit exceptions, like RFC6164, etc...

How about in the current draft remove the 2nd paragraph of 2.4, then add
the following paragraph at the end of section 2.4

   IPv6 unicast routing is based on prefixes of any length up to 128
   bits [BCP198]. However, subnet prefixes of 64 bits in length are
   recommended in normal use. Furthermore, subnet prefixes and
   Interface IDs both of 64 bits in length are required when a unicast
   address is formed from a subnet prefix and an Interface ID. Otherwise,
   when a subnet prefix of another length is used then a unicast address
   is assumed to have no internal structure and is treated as a single
   128 bit quantity. The rationale for the 64 bit boundary in IPv6
   addresses can be found in [RFC7421].

Then in the 4th paragraph of 2.4.1

   As noted in Section 2.4, when a unicast address is formed from a
   subnet prefix and an Interface ID, both are required to be 64 bits
   in length.

I think this accomplishes the 5 goals above and is not inconsistent with at
least the intent of RFC4291. If you read section 2.5 of the RFC4291, I
think my new paragraph is only more clearly restating what is said there
already.

Note that SLACC and other things that use IIDs have 64 bits required for
the IID and subnet prefix length.  But, it should also be noted that host
are not required to have any knowledge of an addresses structure including
its own addresses, therefore IIDs are in fact optional.   Additionally, 64
bit prefix lengths are recommend for everything, including manual config
and DHCP, but manual config and DHCP are allowed other prefix lengths as
well.   Also, the exception for unicast addresses that begin with 000 is no
longer really necessary.

Rotten tomatoes and eggs now please. :)

Thanks.

 --
===============================================
David Farmer               Email:[email-masked]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Fri, 3 Mar 2017 00:18:07 +0000

From: ipv6 [mailto:[email-masked]] On Behalf Of David Farmer

> I've been thinking about this, really hard, and listening to what
> others are saying. I think we want to say the following;
>

Okay.

> 2. Subnet Prefixes of 64 bits are RECOMMENDED

If a home or other network is assigned a /64, what do we recommend for internal subnetting, then? Can't be done? Or does the IETF forbid ISPs from assigning /64s?

> 3. IIDs are REQUIRED to be 64 bits

I thought this interminable last call was specifically because many of us object to this idea. With those exceptions such as SLAAC on Ethernet. Or maybe IIDs should not be longer than 64 bits?

> 4. Say nothing that would imply you cannot configure a prefix length longer than 64 bits in length, at least manually.

Agreed, but does that not invalidate #3?

Bert

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Fri, 3 Mar 2017 00:34:15 +0000

> 3. IIDs are REQUIRED to be 64 bits

I think that RFC 4291 bis should not retain a constraint that has been applied so far, out of convenience, in the earliest stages of IPv6 deployment. Somehow the idea of forced 64-bit IIDs has crept into the culture, even while it is being violated by some devices, routers primarily.

To be pragmatic about these things, given that OSs seem to break if IIDs of other lengths are attempted, my suggestion is to limit the damage to *current use* of the 2000::/3 unicast address space. Not to extend it to all of IPv6.

Bert

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 3 Mar 2017 14:29:23 +1300

On 03/03/2017 13:34, Manfredi, Albert E wrote:
> I think that RFC 4291 bis should not retain a constraint that has been applied so far, out of convenience, in the earliest stages of IPv6 deployment. 

Agreed. And I think there are actually two things to say here:

3.1. Any IPv6-over-foo spec must specify a recommended IID length.
3.2. In the absence of such a spec, the recommended IID length is 64 bits.

Again, that breaks no running code, and it respects the architectural
statement that prefix_length + IID_length == 128, and the use of CIDR
routing and variable-length subnet masks.

    Brian

---

From: David Farmer <[email-masked]>
Date: Thu, 2 Mar 2017 19:49:56 -0600

On Thu, Mar 2, 2017 at 6:18 PM, Manfredi, Albert E <
[email-masked]> wrote:

> If a home or other network is assigned a /64, what do we recommend for
> internal subnetting, then? Can't be done? Or does the IETF forbid ISPs from
> assigning /64s?
>

First of all, a home network is essentially a site, and this is an issue
discussed in section 2.4.4 which probably needs to be updated too.  I think
including a direct reference to RFC 6177 would be a good idea, you get
there indirectly via the reference to RFC3587 and it's reference to RFC3177
which was updated by RFC6177. Furthermore, HOMENET RFC7368 says

   The introduction of IPv6 for home networking makes it possible for
   every home network to be delegated enough address space from its ISP
   to provision globally unique prefixes for each such subnet in the
   home.  While the number of addresses in a standard /64 IPv6 prefix is
   practically unlimited, the number of prefixes available for
   assignment to the home network is not.  As a result, the growth
   inhibitor for the home network shifts from the number of addresses to
   the number of prefixes offered by the provider; this topic is
   discussed in BCP 157 [RFC6177], which recommends that "end sites
   always be able to obtain a reasonable amount of address space for
   their actual and planned usage."

However, if a provider only delegates a /64, this new text ensures that
prefix could be further subnetted down below /64 using manual config or
possibly DHCPv6.  This is NOT RECOMMENDED, /64 subnets are RECOMMENDED and
RFC6177 clearly RECOMMENDS sites be allow more than one /64 subnet.

> I thought this interminable last call was specifically because many of us
> object to this idea. With those exceptions such as SLAAC on Ethernet. Or
> maybe IIDs should not be longer than 64 bits?
>

Variable length IIDs are a BIG CHANGE and it will break current code, I'm
not sure that is a really good idea.

> > 4. Say nothing that would imply you cannot configure a prefix length
> longer than 64 bits in length, at least manually.
>

Nope, the new text I supplied basically says 64 bit IIDs doesn't
necessarily imply every subnet on the Internet is a /64. All the way back
to RFC1884 this text says "at a minimum, a node may consider that unicast
addresses (including its own) have no internal structure", and an IID is
just that internal structure of an address, which is OPTIONAL by that text.

---

From: David Farmer <[email-masked]>
Date: Thu, 2 Mar 2017 19:55:42 -0600

On Thu, Mar 2, 2017 at 7:29 PM, Brian E Carpenter <
[email-masked]> wrote:

> > I think that RFC 4291 bis should not retain a constraint that has been
> applied so far, out of convenience, in the earliest stages of IPv6
> deployment.
>

I'd be fine with that, but others seem to feel otherwise. Lorenzo and James?

Thanks

-- 
===============================================
David Farmer               Email:[email-masked]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815 <(612)%20626-0815>
Minneapolis, MN 55414-3029   Cell: 612-812-9952 <(612)%20812-9952>
===============================================

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Fri, 3 Mar 2017 02:05:58 +0000

From: David Farmer [mailto:[email-masked]]

>> Brian E Carpenter <[email-masked]> wrote:

> I'd be fine with that, but others seem to feel otherwise. Lorenzo

That's why it's called "consensus." As opposed to unanimity.

> possibly DHCPv6.

Exactly. So, how can we allow RFC 4291 bis to say that 64-bit IIDs are REQUIRED? We can't. That was my original point.

Bert

---

From: David Farmer <[email-masked]>
Date: Thu, 2 Mar 2017 20:39:31 -0600

> >> 3.2. In the absence of such a spec, the recommended IID length is

How about, IIDs are REQUIRED to be 64 bits unless overridden by an
IPv6-over-foo spec?

> Exactly. So, how can we allow RFC 4291 bis to say that 64-bit IIDs are
> REQUIRED? We can't. That was my original point.
>
> Bert
>

Because, it doesn't say IIDs are themselves required.  In fact it says "at
a minimum, a node may consider that unicast addresses (including its own)
have no internal structure". IIDs are just that internal structure of an
address, which is by that text is OPTIONAL.  Therefore, it is only saying
if you use an IID it must be 64 bits.

And I'd now suggest it should say, if you use an IID it must be 64 bits
unless overridden my an IPv6-over-foo spec.

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Fri, 3 Mar 2017 02:55:52 +0000

> Because, it doesn't say IIDs are themselves required.

I see this as being a semantic game. As long as an address consists of a prefix, and it has to in order for the packet to be forwarded "the usual way" across routers, the remaining bits will be an ID pointing to a specific interface. I don’t think we are suggesting here that any prefix greater than 64 bits MUST result in a flat network. Or at least, I'm not.

> In fact it says "at a minimum, a node may consider that unicast
> addresses (including its own) have no internal structure".

As a minimum, sure, that's always the case. A node might possibly assume this, as a minimum. "As a minimum" the rule can apply to any IPv6 node, even /64 nodes. A router, for instance, might be configured to only route ten 128-bit addresses, each one to a particular egress interface, and blindly send the rest over an 11th egress interface, for all other traffic. That works fine, as long as the number of 128-bit addresses doesn't grow too much.

> And I'd now suggest it should say, if you use an IID it must be
> 64 bits unless overridden my an IPv6-over-foo spec.

But this would make "as a minimum" phrase lose all its meaning? Now it says that this flat routing scheme must be the only one allowable, for prefixes > 64. So I don’t think that's right.

Bert

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 3 Mar 2017 13:31:06 +0900

> 3.2. In the absence of such a spec, the recommended IID length is 64 bits.

I disagree that we should leave it up to IPv6-over-foo documents to specify
an IID length. If we wanted to make a statement along these lines, the
statement should be that the IID length is 64 bits unless otherwise
specified in an IPv6-over-foo document.

If were to end up making such a statement in this document, then this
document would need to formally update RFC 7934, some of whose conclusions
rest on the fact that IID lengths are currently required to be 64 bits
long, to say that IID lengths of 64 are RECOMMENDED for any network that
provides addresses to general-purpose hosts.

We would therefore have to say, in this document, that any IPv6-over-foo
document that specifies an IID shorter than 64 bits should either be
specifying a technology not used by general-purpose hosts, or should bear
the burden of explaining why the link layer it defines does not follow the
addressing best practices in RFC 7934.

---

From: David Farmer <[email-masked]>
Date: Thu, 2 Mar 2017 23:41:41 -0600

On Thu, Mar 2, 2017 at 8:55 PM, Manfredi, Albert E <
[email-masked]> wrote:

> I see this as being a semantic game. As long as an address consists of a
> prefix, and it has to in order for the packet to be forwarded "the usual
> way" across routers, the remaining bits will be an ID pointing to a
> specific interface. I don’t think we are suggesting here that any prefix
> greater than 64 bits MUST result in a flat network. Or at least, I'm not.
>
> As a minimum, sure, that's always the case. A node might possibly assume
> this, as a minimum. "As a minimum" the rule can apply to any IPv6 node,
> even /64 nodes. A router, for instance, might be configured to only route
> ten 128-bit addresses, each one to a particular egress interface, and
> blindly send the rest over an 11th egress interface, for all other traffic.
> That works fine, as long as the number of 128-bit addresses doesn't grow
> too much.
>
> But this would make "as a minimum" phrase lose all its meaning? Now it
> says that this flat routing scheme must be the only one allowable, for
> prefixes > 64. So I don’t think that's right.
>
> Bert
>

Well I'll agree it's subtle, it needs to be explained better in RFC4291bis,
and I probably haven't hit the mark yet, but it's more than just
semantics.  If I configure an interface as 2001:DB8::1/64, that is saying
that the interface has 128 bit address and a subnet length of 64 bits.
It's not saying the subnet prefix is 2001:DB8::0/64 and the IID is 1 with
an IID length of 64.

Similarly, if I configured my interface with 2001:DB8::1/120, that is
saying that the interface has 128 bit address and a subnet length of 120
bits. It's not saying the subnet prefix is 2001:DB8::0/120 and the IID is 1
with an IID length of 8.

Now I could also configure the address of an interface as 2001:DB8::1 with
no prefix length, it then should look for an RA for that link and if there
is a PIO for prefix 2001:DB8::0, and lets say it has a prefix length of 120
and with an "L" flag and no "A" flag.  In my opinion that should work and
communicate with another host on the link with an interface configured
similarly, with say 2001:DB8::2.  Furthermore, if another host on that link
had an interface configure with 2001:DB8::1001, they shouldn't communicate,
as that address isn't on link by that PIO.

And in all of those cases, 2001:DB8::1/64, 2001:DB8::1/120, or 2001:DB8::1,
2001:DB8::2, 2001:DB8::1001 with no prefix length, there is also a link
local address with an IID of length of 64 and a prefix of FE80::0/64 and
was auto generated with SLAAC.

And stateful DHCPv6 doesn't provide an IID either, it provides a full 128
bit IPv6 address, but doesn't provide a prefix length or a router, that is
learned from the RA and it's PIOs.  I agree with Randy that's another thing
to fix, but that's a fight for a different day, and completely independent
of this.

So saying that all IIDs are required to be 64 bits, doesn't actually imply
all subnet prefixes are /64.  It only says you can't generate an IPv6
address using an IID on a network with a subnet prefix other than /64, and
you probably can't (or at least shouldn't) set the "A" flag on PIO for
prefix other than /64. However, can manually configure or get an address
via DHCPv6 for subnet prefix other than /64.  This why we have to correct
RFC4291bis by recommending /64 subnet prefixes, because it's ambiguous now,
and would be much cleaner if it was clearly recommended.

Thanks.

---

From: [email-masked]
Date: Fri, 3 Mar 2017 08:46:28 +0100

Brian,

[...]

> Agreed. And I think there are actually two things to say here:

It is of course not done because of "convenience".

> 3.1. Any IPv6-over-foo spec must specify a recommended IID length.

Why? Why and how does data-link layer type influence the recommended IID length?
It made sense in the past when we created "modified EUI-64"s that were based on the data-link layer address, but why now?

> routing and variable-length subnet masks.

Cheers,
Ole

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 3 Mar 2017 10:17:15 +0100

David,

Sincerely I appreciate the effort and would like to agree to most
points.  But here is my answer and I wont change.

> 1. IPv6 unicast routing is 128 bits in length [BCP198], AKA not

Agreed, we want to say this.

> 2. Subnet Prefixes of 64 bits are RECOMMENDED

I disagree, we dont want to say this.

> 3. IIDs are REQUIRED to be 64 bits

I disagree.

> longer than 64 bits in length, at least manually.

I agree.

> 5. Avoid all explicit exceptions, like RFC6164, etc...

I dont know.

> How about in the current draft remove the 2nd paragraph of 2.4, then
> add the following paragraph at the end of section 2.4
>
> recommended in normal use.

I agree.

> Furthermore, subnet prefixes and Interface IDs both of 64 bits in
> length are required when a unicast address is formed from a subnet
> prefix and an Interface ID.

This phrase is too much.

> Otherwise, when a subnet prefix of
> another length is used then a unicast address is assumed to have no
> internal structure and is treated as a single 128 bit quantity. The
> rationale for the 64 bit boundary in IPv6 addresses can be found in
> [RFC7421].

This is an explanation of the earlier phrase, and as such is too too much.

> subnet prefix and an Interface ID, both are required to be 64 bits in
> length.

Is the 'subnet prefix' coming from an RA?  From elsewhere?  There are 
very many ways to make a subnet prefix.

> I think this accomplishes the 5 goals above and is not inconsistent
> with at least the intent of RFC4291. If you read section 2.5 of the
> RFC4291, I think my new paragraph is only more clearly restating what
> is said there already.

I think your text suggestion is indeed answering the initial 
requirements formulated at the top.

But I can not agree with it as such.

Again - thank you for the effort, it is good to pursue.

Alex
>
> Note that SLACC and other things that use IIDs have 64 bits required
> for the IID and subnet prefix length.  But, it should also be noted
> that host are not required to have any knowledge of an addresses
> structure including its own addresses, therefore IIDs are in fact
> optional. Additionally, 64 bit prefix lengths are recommend for
> everything, including manual config and DHCP, but manual config and
> DHCP are allowed other prefix lengths as well.   Also, the exception
> for unicast addresses that begin with 000 is no longer really
> necessary.
>
> -- =============================================== David Farmer
> Email:[email-masked] <mailto:[email-masked]> Networking &
> Telecommunication Services Office of Information Technology
> University of Minnesota 2218 University Ave SE        Phone:
> 612-626-0815 Minneapolis, MN 55414-3029   Cell: 612-812-9952
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list [email-masked] Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 3 Mar 2017 10:33:19 +0100

Le 03/03/2017 à 02:29, Brian E Carpenter a écrit :
>> I think that RFC 4291 bis should not retain a constraint that has
>> been applied so far, out of convenience, in the earliest stages of
>> IPv6 deployment.
>

Sounds promising.

But how about the links which dont specify IPv6-over-foo and simply
assume IPv6-over-Ethernet (e.g.g USB, cellular)?  Or should we start
writing IPv6-over-foo documents?

How about Ethernet links 2 hops away from the edge of the cellular
network assigning only one /64.  Can I write an
IPv6-over-Ethernet-2hop-away-from-cellular-edge?  Can I write there the
IID could be 4?

Alex

>
> Again, that breaks no running code, and it respects the
> architectural statement that prefix_length + IID_length == 128, and
> the use of CIDR routing and variable-length subnet masks.
>
> Brian
>

---

From: David Farmer <[email-masked]>
Date: Fri, 3 Mar 2017 03:36:03 -0600

> I disagree, we dont want to say this.

Why, please

> 3. IIDs are REQUIRED to be 64 bits

Again why, and would be ok to RECOMMEND at least

It seems wrong to completely remove any reference to 64 in the IPv6
Addressing Architecture, come on.

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 3 Mar 2017 10:38:08 +0100

Le 03/03/2017 à 03:05, Manfredi, Albert E a écrit :
>>> 3.1. Any IPv6-over-foo spec must specify a recommended IID
>>> length. 3.2. In the absence of such a spec, the recommended IID
>>> length is 64 bits.
>>>
>>> architectural statement that prefix_length + IID_length == 128,
>>> and the use of CIDR routing and variable-length subnet masks.
>>>
>>> Brian
>>
>> However, if a provider only delegates a /64, this new text ensures
>> that prefix could be further subnetted down below /64 using manual
>> config or possibly DHCPv6.

[I miss the original mail from David Farmer saying the above, in the
conversation with Brian and Albert, so I reply here.]

I agree, but that excludes the use of dear SLAAC/Ethernet (it requires
it to be manual config or possibly DHCPv6).

Or otherwise improve RFC2464 to accept other-than-64 IIDs.  Do you think
there could be a proposal of updating 2464 with acceptance of
other-than-64 IIDs?

Alex

>
> Exactly. So, how can we allow RFC 4291 bis to say that 64-bit IIDs
> are REQUIRED? We can't. That was my original point.
>
> Bert
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 3 Mar 2017 11:00:11 +0100

Le 03/03/2017 à 03:39, David Farmer a écrit :
>
>
> On Thu, Mar 2, 2017 at 8:05 PM, Manfredi, Albert E
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     From: David Farmer [mailto:[email-masked] <mailto:[email-masked]>]
>
>     >> Brian E Carpenter <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>     that
> Because, it doesn't say IIDs are themselves required.  In fact it
> says "at a minimum, a node may consider that unicast addresses
> (including its own) have no internal structure". IIDs are just that
> internal structure of an address, which is by that text is OPTIONAL.
> Therefore, it is only saying if you use an IID it must be 64 bits.
>

YEs, as long as we are allowed to update RFC2464 with MAY 
other-than-64bit IID.

Alex

> <mailto:[email-masked]>
> 2218 University Ave SE        Phone: 612-626-0815 <tel:(612)%20626-0815>
> Minneapolis, MN 55414-3029   Cell: 612-812-9952 <tel:(612)%20812-9952>
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 3 Mar 2017 11:28:39 +0100

Le 03/03/2017 à 10:36, David Farmer a écrit :
>
>
> On Fri, Mar 3, 2017 at 3:17 AM, Alexandre Petrescu
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>

It depends in which doc to put it.  It makes sense in RFC2464, or other 
IPv6-over-foo, but not in overall archi doc.

If we are to count, we notice many deployed subnet prefixes are not 64 
(i.e. they wouldnt be non-conformant to this recommendation).

> Again why, and would be ok to RECOMMEND at least

Depends where: makes sense in IP-over-foo, but not in overall archi 
covering in one paragraph about all foos.

> Addressing Architecture, come on.

I agree it is common to talk 64 when introducing IPv6 to someone, when 
looking at a screen dump of rt tables of numerous end nodes, and others. 
  Removing 64 from Archi can look daring, ofensive, hurting, not 
respecting reality.

So one wonders why64?  One source is this EUI-64 originated at IEEE. 
Then 'Modified' EUI-64 at IETF.  Yet EUI-64 is no longer.  It was 
designed to replace 48bit MACs.  It did not succeed: we dont see 
'EUI-64' on Ethernet-based devices, we continue to see 48bit MAC 
addresses even on non-Ethernet devices.  But we hear about EUI-128, 
which would obviously couldnt work with IPv6.

So yes I think it makes sense to remove all 64 from IPv6 Addressing 
Architecture.

Alex

---

From: james woodyatt <[email-masked]>
Date: Fri, 3 Mar 2017 10:12:25 -0800

On Mar 3, 2017, at 02:28, Alexandre Petrescu <[email-masked]> wrote:
> 
> So one wonders why64?  One source is this EUI-64 originated at IEEE. Then 'Modified' EUI-64 at IETF.  Yet EUI-64 is no longer. It was designed to replace 48bit MACs.  It did not succeed: we dont see 'EUI-64' on Ethernet-based devices, we continue to see 48bit MAC addresses even on non-Ethernet devices.  But we hear about EUI-128, which would obviously couldnt work with IPv6.

IEEE 802.15.4 is not remotely dead, and it uses EUI-64, not EUI-48.

--james woodyatt <[email-masked] <mailto:[email-masked]>>

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 3 Mar 2017 19:14:10 +0100

Le 03/03/2017 à 19:12, james woodyatt a écrit :
> On Mar 3, 2017, at 02:28, Alexandre Petrescu

But do I see "EUI-64" printed on some 802.15.4 device?  Or do I see a 
48bit MAC address?

I agree 802.15.4 is live and well and it is very good.

Alex

---

From: james woodyatt <[email-masked]>
Date: Fri, 3 Mar 2017 10:59:56 -0800

On Mar 2, 2017, at 17:55, David Farmer <[email-masked]> wrote:
> On Thu, Mar 2, 2017 at 7:29 PM, Brian E Carpenter <[email-masked] <mailto:[email-masked]>> wrote:
> > From: ipv6 [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of David Farmer
> >

I’m not sure my response to this is necessary, but since it was invited…

p1. For consistency with IPv6 Stateless Address Autoconfiguration [RFC 4862], I don’t think it’s a good idea to require IPv6-over-foo documents to specify IID length. Okay to state that they MAY do so, but not that they MUST do so, and if they don’t then the length is 64 bits, citing [RFC 7421]. [*]

p2. Section 5.5.3 Router Advertisement Processing in RFC 4862 discusses at length how to process the Prefix Information Option (PIO) in Router Advertisement (RA) messages. Some details relevant to this discussion:

  A. "If the sum of the prefix length and interface identifier length
      does not equal 128 bits, the Prefix Information option MUST be
      ignored."

  B. "The length of the interface identifier is
      defined in a separate link-type specific document, which should
      also be consistent with the address architecture [RFC4291] (see Section 2).

  C. "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. It should be noted, however, that this does not mean
      the advertised prefix length is meaningless.  […]
      [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.”

p3. There is another relevant point observed in Section 3 Design Goals of RFC 4862:

  A. "A large site with multiple networks and routers should not require
      the presence of a DHCPv6 server for address configuration.  In
      order to generate global addresses, hosts must determine the
      prefixes that identify the subnets to which they attach.  Routers
      generate periodic Router Advertisements that include options
      listing the set of active prefixes on a link."

I think this is a pretty clear statement to general purpose host operating system developers that Prefix Length advertised in PIO options, even those with zero for both A and L flags, are required to be 64 bits on all the typical link types in general use today and for the foreseeable future, because the IID for those links is specified to be 64 bits. Give us a new link type with a 32 bit IID, and we would then require all the PIO to have plen=96.

At the risk of being excessively repetitive, I will again say that I think it’s important to say that subnet prefixes for networks intended to connect general purpose hosts to the Internet are always 64 bits in length, and they should be 64 bits in length for all other subnets except where expressly recommended otherwise by IETF standards actions (including IPv6-over-foo specifications). I think that’s a shorter way of expressing all that stuff above.

—

[*] As an example, consider the case of IPv6 Over IEEE 802.15.4 [RFC4944]. For some reason, it was carefully written not to specify a limitation on the length of the IID except for use with stateless autoconfiguration, which expressly limits the IID to exactly 64 bits. It then proceeds to define the LOWPAN_HC1 common compressed header encoding, which allows for address compression provided that either A) the IID is derived accordingly from one of the two possible forms of IEEE 802.15.4 address it recognizes, or B) the subnet prefix is exactly 64 bits. These compression methods apply regardless of whether SLAAC is used or not. This gets even more squirrelly in [RFC6282] where LOWPAN_IPHC provides compression for addresses with a 64-bit IID derived from either the EUI-64 address or the IEEE 802.15.4 “short” 16-bit address.

---

From: james woodyatt <[email-masked]>
Date: Fri, 3 Mar 2017 11:05:20 -0800

On Mar 3, 2017, at 10:14, Alexandre Petrescu <[email-masked]> wrote:
> But do I see "EUI-64" printed on some 802.15.4 device?  Or do I see a 48bit MAC address?

The MAC address printed on IEEE 802.15.4 devices are 64 bits not 48 bits.

---

From: Iván Arce <[email-masked]>
Date: Fri, 3 Mar 2017 16:43:00 -0300

Hello

El 2/3/17 a las 22:49, David Farmer escribió:
> possibly DHCPv6.  This is NOT RECOMMENDED, /64 subnets are RECOMMENDED
> and RFC6177 clearly RECOMMENDS sites be allow more than one /64 subnet.
>  
> 
>     I thought this interminable last call was specifically because many
>     of us object to this idea. With those exceptions such as SLAAC on
>     Ethernet. Or maybe IIDs should not be longer than 64 bits?
> 
> 
> Variable length IIDs are a BIG CHANGE and it will break current code,
> I'm not sure that is a really good idea.

Is there data about that? Any specifics? Which/whose code?

What is the scope of the alleged problem?

A host OS implementor (OpenBSD) had said on this list that they will NOT
accept /64 as fixed prefix len mandated in a Internet Standard.

Some people on the list say allowing variable length prefix len will
"break existing running code" while others say the exact opposite. There
can't be a rational discussion about this without actual data.

An alternative is to drop the entire discussion on the basis of a
provable argument such as "it will break existing code" and move to a
discussion where arguments for and against are just analyzed in abstract
or where personal preferences, opinions and interests are stated as such.

-ivan

-- 
Iván Arce
Director del Programa STIC
Fundación Dr. Manuel Sadosky
http://www.fundacionsadosky.org.ar
TE: (+54-11) 4328-5164
GPG fingerprint: 4D97 3003 76C9 9DA4 7209  7982 0A1D 10BE CEA9 1B6E

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Fri, 3 Mar 2017 20:42:34 +0000

From: ipv6 [mailto:[email-masked]] On Behalf Of james woodyatt

> p1. For consistency with IPv6 Stateless Address Autoconfiguration
> [RFC 4862], I don’t think it’s a good idea to require IPv6-over-foo
> documents to specify IID length. Okay to state that they MAY do so,
> but not that they MUST do so, and if they don’t then the length is 64
> bits, citing [RFC 7421]. [*]

I'm okay with saying that SLAAC should by default assume 64-bit IIDs, at least over Ethernet and some other link layers, in today's reality.

> p2. Section 5.5.3 Router Advertisement Processing in RFC 4862 discusses
> at length how to process the Prefix Information Option (PIO) in Router
> Advertisement (RA) messages. Some details relevant to this discussion:

Okay, nothing here suggests that 64-bit IIDs should be mandatory. Matter of fact, RFC 4862 says explicitly,

      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.

And we are just now discussing such an RFC 4291 rev. Says quite clearly here to not assume 64 bit IID to be a constant.

I interpret that to say that global addresses should not ONLY be assigned with DHCPv6. There should also be a SLAAC option and/or, presumably, static configuration. That comment does not make a case for mandating 64-bit IIDs. Only if SLAAC uses 64-bit IIDs would the SLAAC-generated global addresses necessarily use 64-bit IIDs. RAs could be advertising prefixes > 64, which may be used with IIDs < 64 assigned by DHCPv6, or potentially also with a non-64-bit IID SLAAC?

> I think this is a pretty clear statement to general purpose host
> operating system developers that Prefix Length advertised in PIO
> options, even those with zero for both A and L flags, are required to
> be 64 bits on all the typical link types in general use today and for the
> foreseeable future, because the IID for those links is specified to be 64
> bits.

I don't this this implied. Plus, RFC 4862 is only about SLAAC.

Bert

---

From: james woodyatt <[email-masked]>
Date: Fri, 3 Mar 2017 13:18:39 -0800

On Mar 3, 2017, at 12:42, Manfredi, Albert E <[email-masked]> wrote:
> 
> […] Okay, nothing here suggests that 64-bit IIDs should be mandatory. […]

No, but it does say that valid IID lengths are defined for link types by their specification, and that invalid prefix lengths for a given link type MUST be ignored— and not just for stateless auto configuration but *ALSO* for on-link determination.

Shorter james: if IETF will insist that I modify my host IPv6 stack so that, on Wi-Fi links, it will do on-link determination with prefix lengths other than 64 bits, then I want to see that in its own draft and not in the successor to RFC 4291.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 4 Mar 2017 11:05:39 +1300

> It made sense in the past when we created "modified EUI-64"s that were based on the data-link layer address, but why now?

For out-of-the-box interoperability. No other reason that I can see.

   Brian

---

From: Philip Homburg <[email-masked]>
Date: Fri, 03 Mar 2017 23:30:51 +0100

>    Shorter james: if IETF will insist that I modify my host IPv6
>    stack so that, on Wi-Fi links, it will do on-link determination
>    with prefix lengths other than 64 bits, then I want to see that
>    in its own draft and not in the successor to RFC 4291.

Did I miss a couple of rounds somewhere?

Onlink prefixes come from PIO options in RAs with the L bit set. Since
forever, these options have a prefix length field.

Section 4.6.2 of RFC 4861 has this to say about prefix length:
"8-bit unsigned integer.  The number of leading bits
"in the Prefix that are valid.  The value ranges
"from 0 to 128.  The prefix length field provides
"necessary information for on-link determination
"(when combined with the L flag in the prefix
"information option).  It also assists with address
"autoconfiguration as specified in [ADDRCONF], for
"which there may be more restrictions on the prefix
"length.

So there are extra restriction for SLAAC, but not for use as an onlink
prefix.

Are you saying that your stack completely ignores that prefix length and
hardcodes it to 64?

---

From: james woodyatt <[email-masked]>
Date: Fri, 3 Mar 2017 15:44:02 -0800

> Did I miss a couple of rounds somewhere?

It looks like you’re assuming that I don’t have to comply with requirements in RFC 4862 when processing RA messages with Prefix Information Options (PIO). Like every good IPv6 host implementation, mine implements SLAAC. It therefore needs to comply with RFC 4862, especially if I ever hope for it to achieve IPv6 Ready certification for hosts. Lots of hosts are required to implement RFC 4862. You probably have one in your pocket.

> Are you saying that your stack completely ignores that prefix length and

I’m saying that my stack tries to comply with RFC 4862 which requires that it ignore PIO options where the Prefix Length is not 64 on link types that define the length of the IID as 64 bits in the relevant IPv6-over-link document. My stack does that in the hopes of eventually passing the IPv6 Ready certification test, which I’ve been through before, and, yes, it tests for that MUST In RFC 4862. It tests both the requirements for processing the A flag as well as the requirements for processing the L flag.

If you send me a Prefix Length other than 64 bits, then I’m gonna ignore it. Just as RFC 4862 commands.

It’s technically true that *if* my stack did not implement SLAAC, then it would have no need to comply with RFC 4862, and it could therefore accept Prefix Length other than 64 bits on Ethernet (and Wi-Fi) link types, by complying only with RFC 4861 and not RFC 4862.

But let’s be honest. Who would buy gear intended for home networks that cannot do SLAAC?

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Sat, 4 Mar 2017 00:53:23 +0000

> I’m saying that my stack tries to comply with RFC 4862 which
> requires that it ignore PIO options where the Prefix Length is
> not 64 on link types that define the length of the IID as 64 bits
> in the relevant IPv6-over-link document.

That's 64-bit IIDs for SLAAC and link-local. According to RFC 2464. Not a constant for all IIDs, as I read it (used in present and past tense).

> ignore it. Just as RFC 4862 commands.

For SLAAC.

> It’s technically true that *if* my stack did not implement SLAAC, then
> it would have no need to comply with RFC 4862, and it could therefore
> accept Prefix Length other than 64 bits on Ethernet (and Wi-Fi) link
> types,

To me, this could be a problem. Even on Ethernet, it should accept other than /64 prefixes. If I'm assigned a /64, or a /60, or whatever, and I determine to be inadequate, I should be able to use RA and DHCPv6, behind my edge router, to create any number of subnets. RFC 4291 bis needs to accept this as legitimate, because other RFCs already do.

And, more importantly, RFC 4862 itself leaves the door opened for a revised implementation of SLAAC, allowing even SLAAC to be used in such a subnetted case.

Bert

---

From: Philip Homburg <[email-masked]>
Date: Sat, 04 Mar 2017 10:15:39 +0100

>    Im saying that my stack tries to comply with RFC 4862 which
>    not 64 on link types that define the length of the IID as 64
>    bits in the relevant IPv6-over-link document. My stack does that
>    in the hopes of eventually passing the IPv6 Ready certification
>    test, which Ive been through before, and, yes, it tests for that
>    MUST In RFC 4862. It tests both the requirements for processing
>    the A flag as well as the requirements for processing the L
>    flag.
> 
>    If you send me a Prefix Length other than 64 bits, then Im gonna
>    ignore it. Just as RFC 4862 commands.

I find this confusing, you are ignoring an onlink prefix because of auto
configuration? That is IPv4 thinking. In IPv6 they are supposed to be
decoupled.

But in any case, ignoring an onlink prefix should be safe from an
interoperability point of view. Without the prefix you have to send
the traffic to the default router, which will send redirects. So slightly
less efficient but no big deal.

What I really don't understand is that if you implement RFC 4861 (ND)
and you get a PIO option with the A bit clear, that you would drop that
prefix because the address configuration that you are not doing anyhow
would not allow it.

To me that seems like a completely perverse reading of RFC 4861. Maybe
the host requirements RFC should clarify this issue. 

Note that this prefix could be used for DHCPv6. And even if you stack cannnot
use those addresses for address configuration, they may still be onlink.

Also note that RFC 4861 clearly distinguishes between onlink and 
autoconfiguration with the text: "It also assists with address
autoconfiguration as specified in [ADDRCONF], for which there may be
more restrictions on the prefix length." It would be really weird that
assume that RFC 4862 can silently update 4861 in this regard.

Ah, RFC 4862 (Section 5.5.3) is even specific about this problem:
"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.  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.

So this consistency check should only be done if the A bit is set.
And even then, it is not clear of RFC 4862 can change behavior specified 
by RFC 4861 without explictly saying so.

---

From: Alexandre Petrescu <[email-masked]>
Date: Sat, 4 Mar 2017 13:24:49 +0100

Le 04/03/2017 à 10:15, Philip Homburg a écrit :
>> requires that it ignore PIO options where the Prefix Length is not
>> 64 on link types that define the length of the IID as 64 bits in
>> the relevant IPv6-over-link document. My stack does that in the
>> hopes of eventually passing the IPv6 Ready certification test,
>> which Ive been through before, and, yes, it tests for that MUST In
>> RFC 4862. It tests both the requirements for processing the A flag
>> as well as the requirements for processing the L flag.
>>
> I find this confusing, you are ignoring an onlink prefix because of
> auto configuration? That is IPv4 thinking. In IPv6 they are supposed
> to be decoupled.
>
> interoperability point of view.

I agree with the IPv6 facility to have many on-link prefixes.  IPv4 does
it too these days anyways.

But I do not agree with mandating there to be multiple on-link prefixes.

The fe80::/64 is there by default.

So if I add a 2001:db8:abba:abb*::/60 on some computer it will get two
different onlink prefixes with different prefix lengths.

Two is too much, because it means ND  messages for that /64.  That is
noise that can create interference.

Ideally, freedom from /64 means that I would only have that /60 prefix
on the link if that's what I mnaually added.

To realize that freedom (avoid ND noise for /64) I have to add the /60
_and_ delete the /64.

Ideally just add the /60 should be sufficient.

Alex

> Without the prefix you have to send the traffic to the default
> router, which will send redirects. So slightly less efficient but no
> big deal.
>
> and you get a PIO option with the A bit clear, that you would drop
> that prefix because the address configuration that you are not doing
> anyhow would not allow it.
>
> To me that seems like a completely perverse reading of RFC 4861.
> Maybe the host requirements RFC should clarify this issue.
>
> Note that this prefix could be used for DHCPv6. And even if you
> stack cannnot use those addresses for address configuration, they may
> still be onlink.
>
>  more restrictions on the prefix length." It would be really weird
> that assume that RFC 4862 can silently update 4861 in this regard.
>
> "In fact, the "advertised length has non-trivial meaning for on-link
> And even then, it is not clear of RFC 4862 can change behavior
> specified by RFC 4861 without explictly saying so.
>

---

From: Philip Homburg <[email-masked]>
Date: Sat, 04 Mar 2017 13:58:31 +0100

>But I do not agree with mandating there to be multiple on-link prefixes.

Currently at home I have 4 different /64 prefixes as onlink (in addition to
link local). I think all implementations should support that.

>The fe80::/64 is there by default.

Just a note, my stack considers fe80::/10 as onlink. There is no
fe80::/64 in my stack. Of course addr. conf has to treat link local 
special.  But that is already spelled out in the RFC.

>different onlink prefixes with different prefix lengths.

So in my implementation adding a /64 creates two different prefix sizes.
It is not clear to me why you would care.

>noise that can create interference.

Onlink prefixes don't generate traffic. It is only when you use them
to configure addresses or when addresses covered by the prefix are
the destination of a packet. But that is exactly the way it should be.

>on the link if that's what I mnaually added.

True, you should be able to consider a /60 onlink. 

>To realize that freedom (avoid ND noise for /64) I have to add the /60

Address configuration should not create onlink prefixs, so I'm not sure
where the /64 comes from.

---

From: james woodyatt <[email-masked]>
Date: Mon, 6 Mar 2017 09:19:26 -0800

On Mar 4, 2017, at 01:15, Philip Homburg <[email-masked]> wrote:
> [I wrote:]
>> If you send me a Prefix Length other than 64 bits, then I'm gonna ignore it. Just as RFC 4862 commands.
> 
> I find this confusing, you are ignoring an onlink prefix because of auto configuration? […]

I found it confusing at first too, but the RFC 2119 keyword language in RFC 4862 is pretty unambiguous, and it makes sense too if you think about PIO updates that only change the lifetimes and the value of the A flag. The requirement to drop all PIO with invalid prefix length for the link type, regardless of the A flag, ensures with a simple-to-implement rule that you never take a misconfigured prefix as on-link if you cannot ever auto-configure an address in the prefix when the update to A=1 arrives.

This may not be the behavior you’d prefer that RFC 4862 require, but the requirement is clearly there and certification tests are within their ambit to check for it. Moreover, this proposed successor to RFC 4291 doesn’t even have an informative reference to RFC 4862 in it, much less an explicitly declared update. And I don’t believe it should.

---

From: Philip Homburg <[email-masked]>
Date: Mon, 06 Mar 2017 19:49:34 +0100

>    I found it confusing at first too, but the RFC 2119 keyword
>    language in RFC 4862 is pretty unambiguous, and it makes sense
>    too if you think about PIO updates that only change the lifetimes
>    and the value of the A flag. The requirement to drop all PIO
>    with invalid prefix length for the link type, regardless of the
>    A flag, ensures with a simple-to-implement rule that you never
>    take a misconfigured prefix as on-link if you cannot ever
>    auto-configure an address in the prefix when the update to A=1
>    arrives.
> 
>    This may not be the behavior youd prefer that RFC 4862 require,
>    but the requirement is clearly there and certification tests
>    are within their ambit to check for it. Moreover, this proposed
>    successor to RFC 4291 doesnt even have an informative reference
>    to RFC 4862 in it, much less an explicitly declared update. And
>    I dont believe it should.

If your stack only does this when the A bit is set, then I don't care
that much. I'm perfectly happy if SLAAC remains at 64 bits and anything
else requires DHCP or manual config.

Technically, if you only drop the PIO if the A bit is set, then it is 
still future proof, because any future change to the prefix length can
just require two options, one with the A bit set and one with the L 
bit set.

Certainly if the A bit is clear, to reach the MUST in step d), you must
have ignored step a). In addition, step d) spells out that prefixes that
don't match the IID have a meaning in onlink processing, making it
completely clear that 'in order to detect and avoid a configuration error
specifying an invalid prefix length in the context of address
autoconfiguration' means just that.

If RFC 4861 meant to ignore the PIO option for the purpose of onlink
then RFC 4861 would have said so directly.

In any case, I think the 'MUST drop' interpretation of RFC 4862 is
completely wrong. There is no way that a MUST in RFC 4862 can change the
behavior of RFC 4861 without RFC 4862 explicitly updating RFC 4861. If
that is intended, we should at least add an errata to RFC 4862.

I'm not sure why you would think RFC 4291 should say something about the
PIO option and the L bit processing?

So it is not so much what I prefer. It is already spelled out. Note that your
argument 'ensures with a simple-to-implement rule that you never take a
misconfigured prefix as on-link' is not reflected in RFC 4862. RFC 4862
talks about misconfiguration with respect to autoconfiguration and
is explict that this length check does not hold for onlink processing.
Again 'in order to detect and avoid a configuration error specifying
an invalid prefix length in the context of address autoconfiguration'

Finally, the 'MUST drop' interpetation is not consistent with the
behavior of FreeBSD, MacOS, and Linux. So I now start to wonder where
the 'MUST drop' interpretation comes from and if anyone ever bothered
to check out the behavior of existing stacks.

---

From: james woodyatt <[email-masked]>
Date: Mon, 6 Mar 2017 12:53:19 -0800

> to check out the behavior of existing stacks.

Looking at the relevant source code for a couple of the latest BSD-variant kernels, I believe you’re right about the current behavior on those platforms. My memory of them must be outdated. I think they used to drop PIO according to a strict interpretation of RFC 4862. I distinctly remember having to implement it that way in order to pass a certification test. I believe these implementations will not any longer pass that test. (One imagines either their owners don’t care, or the test has been revised to be more lenient.)

I am however looking at a commonly used lightweight IP stack that simply ignores all PIO options unless Prefix Length = 128 - IID Length (and it safely assumes all interface identifiers are length 64 because it doesn’t support link types with other IID lengths, and it’s also unsuitable for use in the environments where IETF standards make exceptions for other IID lengths). This stack was developed entirely apart from the Linux and KAME efforts, by people who read the fine RFCs and implemented the simplest lightest-weight thing possible that is still compliant with the requirements language. That’s important for people on platforms where every byte of code and stack space is precious.

p1. I get that RFC 4862 has requirements language that annoys some participants. We are not here revising RFC 4862 however, so that’s not relevant.

p2. The stack I’m using implements SLAAC and-- for completely defensible reasons— follows the letter of RFC 4862 requirements. Its current behavior is compliant with RFC 4291, RFC 4861 and RFC 4862. It’s not exactly uncommon in the field today, and it’s not currently broken by the proposed successor to RFC 4291 with its current language about IID length.

p3. I get that people want to hold up promotion of IPv6 to Full Standard until the successor of RFC 4291 is changed to declare explicitly that the stack I’m using is in error. My opinion is this is a procedural matter, not a technical matter.

I object to the procedural step being proposed, not the technical argument. If we MUST declare the stack I’m using to be in error, then please let’s NOT do it in this draft. Can you not wait until RFC 4861 and RFC 4862 are next revised?

---

From: Timothy Winters <[email-masked]>
Date: Mon, 6 Mar 2017 19:01:51 -0500

Hi James and Philip,

I wanted to quickly comment on this line.

On Mon, Mar 6, 2017 at 3:53 PM, james woodyatt <[email-masked]> wrote:

> Yes,  IPv6 Ready Logo and USGv6 Test Programs confirm that stacks process
PIO with a length larger then 64 bits for on-link determination.   This
works with most IPv6 stacks today.

>
> Looking at the relevant source code for a couple of the latest BSD-variant
> kernels, I believe you’re right about the current behavior on those
> platforms. My memory of them must be outdated. I think they used to drop
> PIO according to a strict interpretation of RFC 4862. I distinctly remember
> having to implement it that way in order to pass a certification test. I
> believe these implementations will not any longer pass that test. (One
> imagines either their owners don’t care, or the test has been revised to be
> more lenient.)
>
> I am however looking at a commonly used lightweight IP stack that simply
> ignores all PIO options unless Prefix Length = 128 - IID Length (and it
> safely assumes all interface identifiers are length 64 because it doesn’t
> support link types with other IID lengths, and it’s also unsuitable for use
> in the environments where IETF standards make exceptions for other IID
> lengths). This stack was developed entirely apart from the Linux and KAME
> efforts, by people who read the fine RFCs and implemented the simplest
> lightest-weight thing possible that is still compliant with the
> requirements language. That’s important for people on platforms where every
> byte of code and stack space is precious.
>
> p1. I get that RFC 4862 has requirements language that annoys some
> participants. We are not here revising RFC 4862 however, so that’s not
> relevant.
>
> p2. The stack I’m using implements SLAAC and-- for completely defensible
> reasons— follows the letter of RFC 4862 requirements. Its current behavior
> is compliant with RFC 4291, RFC 4861 and RFC 4862. It’s not exactly
> uncommon in the field today, and it’s not currently broken by the proposed
> successor to RFC 4291 with its current language about IID length.
>
> p3. I get that people want to hold up promotion of IPv6 to Full Standard
> until the successor of RFC 4291 is changed to declare explicitly that the
> stack I’m using is in error. My opinion is this is a procedural matter, not
> a technical matter.
>
> I object to the procedural step being proposed, not the technical
> argument. If we MUST declare the stack I’m using to be in error, then
> please let’s NOT do it in this draft. Can you not wait until RFC 4861 and
> RFC 4862 are next revised?
>
>
> --james woodyatt <[email-masked]>
>
>
>
>
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>
>

-- 

Now offering testing for SDN applications and controllers in our SDN switch
test bed. Learn more today http://bit.ly/SDN_IOLPR

---

From: james woodyatt <[email-masked]>
Date: Mon, 6 Mar 2017 16:25:31 -0800

On Mar 6, 2017, at 16:01, Timothy Winters <[email-masked]> wrote:
> On Mon, Mar 6, 2017 at 3:53 PM, james woodyatt <[email-masked] <mailto:[email-masked]>> wrote:
> On Mar 6, 2017, at 10:47, Philip Homburg <[email-masked] <mailto:[email-masked]>> wrote:
>> 
> Yes,  IPv6 Ready Logo and USGv6 Test Programs confirm that stacks process PIO with a length larger then 64 bits for on-link determination.   This works with most IPv6 stacks today.

Hmm. I seriously remember failing that test in the other direction: accepting the prefix when it was supposed to be ignored. Maybe I’m mistaken.

In any case, my opinion is that the IPv6 Ready Logo test and the USGv6 test would be imposing a stricter test than called for by the requirement language in RFC 4862 if it requires on-link determination to succeed on PIO with an invalid Prefix Length for the link type, and it’s a test for a feature that some constrained host implementations don’t currently implement.

Those stacks (like the one I’m using now) that would fail the IPv6 Ready Logo and USGv6 tests are still compliant with RFC 4862, and I think the successor to RFC 4291 shouldn’t declare them broken.

---

From: Timothy Winters <[email-masked]>
Date: Mon, 6 Mar 2017 19:34:43 -0500

Hi James,

I don't believe this test is too strict based on 4862 Section 6.3.4 "
Similarly,

   [ADDRCONF <https://tools.ietf.org/html/rfc4861#ref-ADDRCONF>] may
impose certain restrictions on the prefix length for
   address configuration purposes.  Therefore, the prefix might be
   rejected by [ADDRCONF
<https://tools.ietf.org/html/rfc4861#ref-ADDRCONF>] implementation in
the host.  However, the

   prefix length is still valid for on-link determination when combined

   with other flags in the prefix option."

Basically ND still works even if SLAAC thinks the prefix length is
invalid.   It's really a ND test for on-link deteremination.

~Tim

On Mon, Mar 6, 2017 at 7:25 PM, james woodyatt <[email-masked]> wrote:

> Hmm. I seriously remember failing that test in the other direction:
> accepting the prefix when it was supposed to be ignored. Maybe I’m mistaken.
>
> In any case, my opinion is that the IPv6 Ready Logo test and the USGv6
> test would be imposing a stricter test than called for by the requirement
> language in RFC 4862 if it requires on-link determination to succeed on PIO
> with an invalid Prefix Length for the link type, and it’s a test for a
> feature that some constrained host implementations don’t currently
> implement.
>
> Those stacks (like the one I’m using now) that would fail the IPv6 Ready
> Logo and USGv6 tests are still compliant with RFC 4862, and I think the
> successor to RFC 4291 shouldn’t declare them broken.
>

--

---

From: 神明達哉 <[email-masked]>
Date: Mon, 6 Mar 2017 17:11:07 -0800

At Mon, 6 Mar 2017 19:34:43 -0500,

> invalid.   It's really a ND test for on-link deteremination.

I'd also note that the above text didn't exist in RFC2461; it was
newly introduced in RFC4861.  If I remember it correctly the added
text was an attempt of clarifying validation for on-link determination
and validation for SLAAC are independent, as it had often been
misunderstood.  RFC4862 also tried to clarify that point, e.g., in
this text:

      [...]  It should be noted, however, that this does not mean
      the advertised prefix length is meaningless.  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.

But this thread and another similar discussion seem to suggest that
it's still not clear enough for some people.  At least two different
readers interpret this text:

      If the sum of the prefix length and interface identifier length
      does not equal 128 bits, the Prefix Information option MUST be
      ignored.

as the PIO MUST be ignored for all purposes including on-link
determination.  In a sense, it's not necessarily surprising - no
matter how we try to clarify a point there's always a reader that
still interprets it differently.  But if there is really a protocol
conformance test that doesn't interpret the text differently it's
really surprising to me.

The bottom line is, if there is an implementation that ignores a PIO
- with both L and A flag on, and
- with prefix length being something other than 64
- received on a link whose IID is specified to be 64 (like Ethernet)
even for on-link determination, then that implementation violates
RFC4861.  I can also assure that the document editor of RFC4862 didn't
intend such "strictness" - on the contrary, he actually tried to
clarify that's not the intent, but it looks like it's still not super
clear.

--
JINMEI, Tatuya

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 7 Mar 2017 11:44:04 +0100

Le 07/03/2017 à 02:11, 神明達哉 a écrit :
[...]
>> does not equal 128 bits, the Prefix Information option MUST be

Let me say that there are some interpretations of that sum from people
struggling to make it work.  These interpretations may be surprising to
the specifier.

The specifier is tempted to think that that "sum" equation is a good way
to tell everything in just one phrase.

But some people face the problem of making that sum be 128 even though
the plen is less than 64 and the IID is 64.

It is the case with the fe80:://10 needing to become a fe80::/64, and it
is also the case when PIO in RA has a P1::/63.

For this latter case, one wonders: am I allowed to form an address when
all I have is a P1::/63, and an IIDlen 64?  Can I make a P2::/64 by 
padding with 0s?

The specs dont answer these questions.  The specs think that the "sum"
equation is enough.

Further, because of that, some people think P1::/63 is forbidden from
being advertised on Ethernet.  Others think fe80:://10 is the same as
fe80::/64.

> still interprets it differently.

I agree with you.  And the more IPv6 gets deployed, the more readers
there are.

> But if there is really a protocol conformance test that doesn't
> interpret the text differently it's really surprising to me.
>
>  - with both L and A flag on, and - with prefix length being
> something other than 64 - received on a link whose IID is specified
> to be 64 (like Ethernet) even for on-link determination, then that
> implementation violates RFC4861.  I can also assure that the
> document editor of RFC4862 didn't intend such "strictness" - on the
> contrary, he actually tried to clarify that's not the intent, but it
> looks like it's still not super clear.

Well...

Alex

> -- JINMEI, Tatuya

---

From: Sander Steffann <[email-masked]>
Date: Tue, 7 Mar 2017 13:15:40 +0100

Hi Alex,

> Op 7 mrt. 2017, om 11:44 heeft Alexandre Petrescu <[email-masked]> het volgende geschreven:
> 
> It is the case with the fe80:://10 needing to become a fe80::/64

Which is explicitly specified in RFC 4862 section 5.3. The /10 is used as the basis and adapted to the IID length on the link. It explicitly says that all bits between fe80::/10 and the IID are zero (point 2).

It also says "The length of the interface identifier is defined in a separate link-type-specific document". RFC 2464, which is that link-type-specific document for ethernet, specifies in section 5 that on ethernet the prefix for link-local addresses is a fe80::/64 with a 64-bit IID. Everything is specified: the /10 to use as the basis, the /64 being the length used on ethernet and the bits between the two having to be zero.

> , and it is also the case when PIO in RA has a P1::/63.
> 
> all I have is a P1::/63, and an IIDlen 64?  Can I make a P2::/64 by padding with 0s?
> 

It is. A "sum" is a quite clearly defined mathematical concept. As you quoted above RFC 4862 section 5.5.3 says "If the sum of the prefix length and interface identifier length does not equal 128 bits, the Prefix Information option MUST be ignored." Let's test this. In your example case:
- P1::/63 has a prefix length of 63
- IIDlen (interface identifier length) is 64
- the sum of the prefix length and the interface identifier length is 63 + 64 = 127
- 127 does not equal 128
- therefore the Prefix Information option MUST be ignored

> being advertised on Ethernet.

According to RFC 4862 you can advertise it, but receivers must ignore it.

> Others think fe80:://10 is the same as fe80::/64.

As you can see above the fe80::/10 prefix is used as the basis for the link-local addresses, with the actual prefix length defined per link-type. For ethernet that has been specified as 64-bits, so that leads to fe80::/64 on ethernet.

Please read the RFCs. All the examples you provide are quite explicitly covered there...

Cheers,
Sander

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 7 Mar 2017 14:54:24 +0100

Le 07/03/2017 à 13:15, Sander Steffann a écrit :
> Hi Alex,
>
>> Op 7 mrt. 2017, om 11:44 heeft Alexandre Petrescu
>> <[email-masked]> het volgende geschreven:
>>
>> Le 07/03/2017 à 02:11, 神明達哉 a écrit : [...]
>>> But this thread and another similar discussion seem to suggest
>>> that it's still not clear enough for some people.  At least two
>>> different readers interpret this text:
>>>
>>>> If the sum of the prefix length and interface identifier
>>>> length does not equal 128 bits, the Prefix Information option
>>>> MUST be ignored.
>>
>> Let me say that there are some interpretations of that sum from
>> people struggling to make it work.  These interpretations may be
>> surprising to the specifier.
>>
>> The specifier is tempted to think that that "sum" equation is a
>> good way to tell everything in just one phrase.
>>
>> But some people face the problem of making that sum be 128 even
>> though the plen is less than 64 and the IID is 64.
>>
> Which is explicitly specified in RFC 4862 section 5.3. The /10 is
> used as the basis and adapted to the IID length on the link. It
> explicitly says that all bits between fe80::/10 and the IID are zero
>  (point 2).

That is how you read it, and you read it so because you want to make it
work.

But this is what the text says:

RFC4862:
> A link-local address is formed by combining the well-known link-local
> prefix FE80::0

Hold on?  Isn't that denoting an address?  Rather than a prefix?

FE80::0 is an address, not a prefix.  Were it a prefix it should have
been named FE80::/plen.  I suspect the author could not write FE80::/10
because s/he was not sure whether that should be FE80::/10 or FE80::/64.
  So she came up with FE80::0, ignoring that it can be understood as an
address by some.

And naturally so, because, notationally, it is not clear whether FE80::0
is even allowed, from the point of view of the "::".  We know the "::"
can not be preceded by 0s in the same sextet (notation FE80:0::/64 is
forbidden).  But we dont know whether "::" could be followed by hextets
made of 0s (we dont know whether FE80::0:0 is allowed).

Notationally, we do know that an address written like FE80::1 is a full
address (there is no plen specified).  It is possible to assign FE80::0
as an address on an interface.

Given that, how can the RFC4862 say "the link-local prefix FE80::0"?  If
so, how much trust can we put in that?  If this approximation is
permitted, which other approximations are allowed?  What does the point
2. actually meant?

(As a side remark, it is obvious that these things may appear as too
much detail for the person looking from high up, but the notational
definition is of utmost importance for someone trying to write a lexical
analysis and grammar for textual representation of IPv6 addresses.  I.e.
any of the numerous GUI or CLI interfaces.)

> 2.  The bits in the address to the right of the link-local prefix are
> set to all zeroes.

What is then a "link-local prefix"?  Is it fe80::/10?  Is it fe80::/64?

Did the author actually mean "left" instead of "right", and mean "IID"
instead of link-local prefix?

We dont know.  But we must make it work.  So we come up with
interpretations.

> It also says "The length of the interface identifier is defined in a
>  separate link-type-specific document". RFC 2464, which is that
> link-type-specific document for ethernet, specifies in section 5 that
> on ethernet the prefix for link-local addresses is a fe80::/64 with a
> 64-bit IID.

Yes.

> Everything is specified: the /10 to use as the basis,

At this time, it seems that /10 is not used for anything else.  It is
reserved for nothing.  You call it a 'basis' but nobody uses such a
basis, and it creates confusion as noted above.

So someone who insists on 64bit IID and 64bit plens can't continue with
that /10 for any reason.

> the /64 being the length used on ethernet and the bits between the
> two having to be zero.
>
>> For this latter case, one wonders: am I allowed to form an address
>>  when all I have is a P1::/63, and an IIDlen 64?  Can I make a
>> P2::/64 by padding with 0s?
>>
>> The specs dont answer these questions.  The specs think that the
>> "sum" equation is enough.
>
> It is. A "sum" is a quite clearly defined mathematical concept.

Well, it is as shady as when we say a=1.  The mathematician reads it
differently than the programmer.

A useful equation for programmer is like this: m+n MUST equal 128.  You 
are not allowed to pad if you receive a /63 in RA, or if you have a 
IID-shorter-than-64; you are not allowed to make addresses of length 129.

just the equation is not enough.

Moreover, that unclarity leads to deviations like this: 128 can only be 
made of 2 parts each being 64.

> As you quoted above RFC 4862 section 5.5.3 says "If the sum of the
> prefix length and interface identifier length does not equal 128
> bits, the Prefix Information option MUST be ignored." Let's test
> this. In your example case: - P1::/63 has a prefix length of 63 -
> IIDlen (interface identifier length) is 64 - the sum of the prefix
> length and the interface identifier length is 63 + 64 = 127 - 127
> does not equal 128 - therefore the Prefix Information option MUST be
>  ignored

And what if I add a 0 bit between the 63 and 64?  That plen would become
64.  At that point the sum would become 128 again.

It's the same thing that people did when adding 0s between /10 and /64
of the FE80:://10 to make it become FE80::/64.

Why the specifier can silently add 0bits to make plens 64 for the LL,
but implementer couldnt do the same with a received /63?

>> Further, because of that, some people think P1::/63 is forbidden
>> from being advertised on Ethernet.
>

And if so then it is wrong.

> As you can see above the fe80::/10 prefix is used as the basis for
> the link-local addresses, with the actual prefix length defined per
> link-type. For ethernet that has been specified as 64-bits, so that
> leads to fe80::/64 on ethernet.
>

I read many times these RFCs...  I know what I talk about.

You may be overwhelmed by too many emails from my part, but that's
another aspect.

Alex

> Cheers, Sander

---

From: Sander Steffann <[email-masked]>
Date: Tue, 7 Mar 2017 15:37:45 +0100

Hi,

> been named FE80::/plen.

True, it's written as an address. However, in step 2 it says to set all bits to the right of the prefix to zero. However you choose to read it, you end up with fe80:0000:0000:0000:0000:0000:0000:0000. In step 3 the N rightmost bits of that are overwritten with the N-bits-long IID.

> I suspect the author could not write FE80::/10

The ipv6-on-ethernet explicitly states that on ethernet the link-local prefix is fe80::/64.

> So she came up with FE80::0, ignoring that it can be understood as an

Don't make assumptions.

> made of 0s (we dont know whether FE80::0:0 is allowed).

Of course it is allowed. fe80:: is the same as fe80:0:0:0:0:0:0:0, is the same as fe80:0:0::0:0 etc. Where did you get the idea that some of those notations are forbidden? RFC 4291 only says that "The use of "::" indicates one or more groups of 16 bits of zeros." nothing more nothing less. It doesn't mandate using :: for all groups of 16-bits of zeroes, just "one or more".

> permitted, which other approximations are allowed?  What does the point

If you take it literally and assume that fe80::0 is an address instead of a prefix, then it is a /128 and point 2 doesn't need to do a thing because all those bits are 0 already. If you read it as a prefix then after point 2 you end up with the exact same 128 bits.

However, RFC 4862 explicitly refers to "the well-known link-local prefix FE80::0 [RFC4291]" and although it doesn't write it as a prefix, RFC 4291 section 2.4 is very explicit that the prefix is fe80::/10.

I agree that the wording is a bit unfortunate, but however you read it, after point 2 the result is the same.

> What is then a "link-local prefix"?  Is it fe80::/10?  Is it fe80::/64?

The link local prefix on ethernet is fe80::/64. Other network types may vary, but on all of them the link-local prefix is within fe80::/10.

> We dont know.  But we must make it work.  So we come up with

?!?? Stop second-guessing the authors. The wording is quite explicit and you "alternative interpretations" are not.

> basis,

On the most common network types it is indeed not uses. It is reserved for whatever happens in the future. Maybe nobody will use it, maybe some future RFC will. What's the problem?

> and it creates confusion as noted above.

No it doesn't. The /10 is reserved, ethernet uses a /64, other network types may use something different. Pretty clear.

> So someone who insists on 64bit IID and 64bit plens can't continue with

Why not? No harm in reserving a bit more than you use or need today.

> A useful equation for programmer is like this: m+n MUST equal 128.  You are not allowed to pad if you receive a /63 in RA, or if you have a IID-shorter-than-64; you are not allowed to make addresses of length 129.
> 

The equation is perfectly fine. Do you really want to add "no, you can't single-handedly modify the input to fit the output, stick to the equation and the input provided to you"??? Please stop being silly.

> Moreover, that unclarity leads to deviations like this: 128 can only be made of 2 parts each being 64.

On ethernet that is correct according to current RFCs.

> 64.  At that point the sum would become 128 again.

Again, stop making things up to fit your imagination. The RFC is quite clear.

> of the FE80:://10 to make it become FE80::/64.

Nope, that is explicitly specified as such.

> Why the specifier can silently add 0bits to make plens 64 for the LL,

It's not silent, it's specified.

> but implementer couldnt do the same with a received /63?

Because the RFC explicitly says not to.

> And if so then it is wrong.

In none of this I'm saying that I agree with what is written in the current RFCs. There are plenty of things I would have liked to be done differently. But today we have the existing RFCs. If things should be changed then the solution is to write new RFCs, not to play games with the interpretation of the current ones.

> You may be overwhelmed by too many emails from my part, but that's

No, my head is quite clear today despite the attempted confusion by alternative interpretations.

Cheers,
Sander

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 7 Mar 2017 16:52:40 +0100

Le 07/03/2017 à 15:37, Sander Steffann a écrit :
>>> A link-local address is formed by combining the well-known
>>> link-local prefix FE80::0
>>
>> FE80::0 is an address, not a prefix.  Were it a prefix it should
>> have been named FE80::/plen.
>
> True, it's written as an address. However, in step 2 it says to set
> all bits to the right of the prefix to zero.

And what is a prefix?  If specifier does not know what is a prefix how
could she expect the implementer to implement it?

> However you choose to read it, you end up with
> fe80:0000:0000:0000:0000:0000:0000:0000.

And that is an address.  Do you agree?

> In step 3 the N rightmost bits of that are overwritten with the
> N-bits-long IID.

YEs, that covers the 64bit rightmost part.  But that does not say what
to put between /10 and /64.

>> I suspect the author could not write FE80::/10 because s/he was not
>> sure whether that should be FE80::/10 or FE80::/64.
>

YEs, but IPv6-over-Ethernet is less important than IPv6 Addressing
Architecture.  This latter says there is an FE80::/10 (and not /64).

Do you agree IPv6 Addressing Architecture says "FE80::/10"?

>> So she came up with FE80::0, ignoring that it can be understood as
>>  an address by some.
>
> Don't make assumptions.

So why did she write "prefix FE80::0".  Isnt that wrong?

Or maybe I should not ask at all?

>
>> And naturally so, because, notationally, it is not clear whether
>> FE80::0 is even allowed, from the point of view of the "::".  We
>> know the "::" can not be preceded by 0s in the same sextet
>> (notation FE80:0::/64 is forbidden).  But we dont know whether "::"
>> could be followed by hextets made of 0s (we dont know whether
>> FE80::0:0 is allowed).
>
> Of course it is allowed.

?

> fe80:: is the same as fe80:0:0:0:0:0:0:0, is the same as
> fe80:0:0::0:0 etc.

I agree fe80:: is the same as fe80:0:0:0:0:0:0:0.

However, both fe80:: and fe80:0:0:0:0:0:0:0 are addresses, not prefixes.
  A prefix should have a '/' in its notation, like fe80::/64.

Moreover, in my interpretation, the fe80::0 is a forbidden notation,
because RFC5952 titled "IPv6 text representation" says "2001:0db8::0001
is not acceptable and must be represented as 2001:db8::1".

> Where did you get the idea that some of those notations are
> forbidden? RFC 4291 only says that "The use of "::" indicates one or
> more groups of 16 bits of zeros." nothing more nothing less. It
> doesn't mandate using :: for all groups of 16-bits of zeroes, just
> "one or more".

By RFC5952 titled "IPv6 text representation" saying "2001:0db8::0001
is not acceptable and must be represented as 2001:db8::1".

>> Notationally, we do know that an address written like FE80::1 is a
>>  full address (there is no plen specified).  It is possible to
>> assign FE80::0 as an address on an interface.
>>
>> Given that, how can the RFC4862 say "the link-local prefix
>> FE80::0"?  If so, how much trust can we put in that?  If this
>> approximation is permitted, which other approximations are allowed?
>> What does the point 2. actually meant?
>
> If you take it literally and assume that fe80::0 is an address
> instead of a prefix,

No IPv6 literal denotes a prefix without involving a /.

In IPv4: it's hard to say whether a notation like 192.168.0.0 is a /16
or a /24.

I think the same difficulty stands here.

Best is to say the plen by involving the "/".

> then it is a /128

That is another question: is FE80::/128 denoting an address or a prefix?

> those bits are 0 already. If you read it as a prefix then after point
> 2 you end up with the exact same 128 bits.
>
> However, RFC 4862 explicitly refers to "the well-known link-local
> prefix FE80::0 [RFC4291]"

That is a wrong notation.  There is no such thing as FE80::0 'prefix'.

Add that to the confusion between the fe80::/10 prefix and the fe80::/64
prefix.

You have a confusion with 3 ingredients here...

> and although it doesn't write it as a prefix, RFC 4291 section 2.4
> is very explicit that the prefix is fe80::/10.

Saying fe80::/10 is not same as saying fe80::0, sorry.

[...]
> The equation is perfectly fine. Do you really want to add "no, you
> can't single-handedly modify the input to fit the output, stick to
> the equation and the input provided to you"??? Please stop being
> silly.

?

[...]
> alternative interpretations.

Please clarify this: is it correct to say "prefix FE80::0"?  What is the
plen of it?  Just because it starts with "FE80" does not warrant a plen
of value 10.  Is it 9? Because after the 9th bit there are only 0s.  Or
is it 16?  Because there are two bytes in FE80.

If we dont know what the plen of "FE80::0" is, then it could be anything.

As such, what to do when the text says "2.  The left-most 'prefix
length' bits of the address are those of the link-local prefix."

Alex

---

From: Sander Steffann <[email-masked]>
Date: Tue, 7 Mar 2017 17:38:15 +0100

Hi,

> to put between /10 and /64.

Yes it does. In whatever way you read it those bits contain 0.

I'm going to stop this thread, this discussion is going nowhere... You seem to have made up your mind that you *want* to interpret the RFCs in a way that doesn't make sense, and it's not my job to fix that...

Cheers,
Sander

---

From: Fernando Gont <[email-masked]>
Date: Tue, 7 Mar 2017 13:51:19 -0300

> Yes it does. In whatever way you read it those bits contain 0.

Fully agreed.

That aside, when you learn link-locals via some APIs in BSDs, you'll
find that some of such bits are non-zero -- that's because they leverage
the requirement for them to be zero, and use such bits to store e.g. the
interface index. (it was one of my WTH moments when coding tools :-) ).

Thanks!

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Sander Steffann <[email-masked]>
Date: Tue, 7 Mar 2017 18:12:17 +0100

Hi,

> interface index. (it was one of my WTH moments when coding tools :-) ).

Yeah, that was surprising for me too :)

Cheers,
Sander

---

From: 神明達哉 <[email-masked]>
Date: Tue, 7 Mar 2017 10:36:47 -0800

At Tue, 7 Mar 2017 11:44:04 +0100,

> is also the case when PIO in RA has a P1::/63.

At least the above text from Section 5.5.3 of RFC4862 is irrelevant to
link-local addresses.  The entire Section 5.5 is about "Creation of
Global Addresses" as the title shows.  In the case of creating global
addresses, I can't think of an interpretation of this text

as it allows the creation in the case of advertised plen=63 and IID
len=64.  RFC4862 requires not to do so with the MUST.  BSDs implement
it that way, and so does Linux (according to what I heard here).  I'm
also pretty sure that there's a conformance test tool like that for
"IPv6 ready logo" or USGv6 that confirms the intent of the RFC.  And
so I'm also pretty sure that other major OSes interpret the RFC as it
intends.  So, overall, I don't think it's just what a document editor
intends in his mind, but a widely accepted interpretation.

That said, there's always someone who understands any seemingly clear
text differently from the actual intent, not to mention the recent row
about EH insertion.  So I'm not surprised that there are such people.
If you think this point is so unclear for so many people, I'd suggest
you write a clarification draft or submit an errata.  If you think we
should actually allow the creation in such a case, that's a protocol
change, and I'd suggest you write a draft to update RFC4862.  With
luck, that will become the new standard.

I don't think continuing this topic in this thread brings us anywhere,
so I'll stop here.

--
JINMEI, Tatuya

---

From: james woodyatt <[email-masked]>
Date: Tue, 7 Mar 2017 10:44:07 -0800

On Mar 6, 2017, at 16:34, Timothy Winters <[email-masked]> wrote:
> 
> I don't believe this test is too strict based on 4862 Section 6.3.4 "Similarly,
>    [ADDRCONF <https://tools.ietf.org/html/rfc4861#ref-ADDRCONF>] may impose certain restrictions on the prefix length for
>    rejected by [ADDRCONF <https://tools.ietf.org/html/rfc4861#ref-ADDRCONF>] implementation in the host.  However, the
> Basically ND still works even if SLAAC thinks the prefix length is invalid.   It's really a ND test for on-link deteremination.

I’ll run away and think about this some more, but right now I think it might still be a valid interpretation of the RFC 4862 requirement language to ignore PIO entirely if Prefix Length is not valid for the link type. If that means LwIP fails USGv6 and IPv6 Ready Logo testing, then my opinion is that it's a tussle between those certification tests and those parts of the IPv6 standards that are not actually revised by the successor to RFC 4291.

---

From: Timothy Winters <[email-masked]>
Date: Tue, 7 Mar 2017 13:50:10 -0500

Hi James,

It's valid to ignore it for SLAAC, but not ND.   RFC 4861 is clear about
processing the PIO for on-link determination, LwIP isn't following ND spec.

Regards,
Tim

On Tue, Mar 7, 2017 at 1:44 PM, james woodyatt <[email-masked]> wrote:

> I’ll run away and think about this some more, but right now I think it
> might still be a valid interpretation of the RFC 4862 requirement language
> to ignore PIO entirely if Prefix Length is not valid for the link type. If
> that means LwIP fails USGv6 and IPv6 Ready Logo testing, then my opinion is
> that it's a tussle between those certification tests and those parts of the
> IPv6 standards that are not actually revised by the successor to RFC 4291.
>
>

--

---

From: james woodyatt <[email-masked]>
Date: Tue, 7 Mar 2017 10:52:35 -0800

On Mar 6, 2017, at 17:11, 神明達哉 <[email-masked]> wrote:
> RFC4861.

LwIP ignores all PIO with Prefix Length not 64, which is the prefix length on all the link types it supports, regardless of A and L flag values.

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 7 Mar 2017 19:49:35 +0100

Le 07/03/2017 à 17:38, Sander Steffann a écrit :
>> YEs, that covers the 64bit rightmost part.  But that does not say
>> what to put between /10 and /64.
>

Here it goes: FE80:1::1 does not contain 0s.

Nothing can stop me from putting a 1 there.

The RFCs should get corrected.

> I'm going to stop this thread, this discussion is going nowhere...
> You seem to have made up your mind that you *want* to interpret the
> RFCs in a way that doesn't make sense, and it's not my job to fix
> that...

"prefix FE80::0" is incorrect please remove that from that RFC.  Say 
"prefix FE80::/10" instead.

Alex

---

From: james woodyatt <[email-masked]>
Date: Tue, 7 Mar 2017 10:59:19 -0800

On Mar 7, 2017, at 10:50, Timothy Winters <[email-masked]> wrote:
> 
> It's valid to ignore it for SLAAC, but not ND.   RFC 4861 is clear about processing the PIO for on-link determination, LwIP isn't following ND spec.
> 
I’m happy to defer to your considerable expertise in these matters.

Question: could you point me at the requirements language in RFC 4861 that LwIP is specifically violating? I’m confused because when I search on the phrase "Prefix Length” in the text, the relevant excerpt that seems to apply is this one:

>>       Note: Implementations can choose to process the on-link aspects of
>>       the prefixes separately from the stateless address
>>       autoconfiguration aspects of the prefixes by, e.g., passing a copy
>>       of each valid Router Advertisement message to both an "on-link"
>>       and an "addrconf" function.  Each function can then operate
>>       independently on the prefixes that have the appropriate flag set.

The way I read this is that implementations MAY choose to process the Prefix Length validation differently in on-link determination and SLAAC functions, but that it doesn’t seem to be expressly REQUIRED. Sadly, there don’t seem to be any other relevant texts about the Prefix Length.

I can believe that LwIP is violating RFC 4861, but before I file an error report for this, I’d like to be able to cite the actual requirements keywords, and I’m concerned about the possibility this Note above may be used by the LwIP maintainers as a justification to reject the problem report.

---

From: Timothy Winters <[email-masked]>
Date: Tue, 7 Mar 2017 14:05:34 -0500

Hi James,

Last Paragraph of Section 6.3.4

"  Similarly,[ADDRCONF] may impose certain restrictions on the prefix
length for
   address configuration purposes.  Therefore, the prefix might be
   rejected by [ADDRCONF] implementation in the host.  However, the
   prefix length is still valid for on-link determination when combined
   with other flags in the prefix option."

It allows for rejection in ADDRCONF as LwIP does, but requires on-link
determination.

~Tim

On Tue, Mar 7, 2017 at 1:59 PM, james woodyatt <[email-masked]> wrote:

> Question: could you point me at the requirements language in RFC 4861 that
> LwIP is specifically violating? I’m confused because when I search on the
> phrase "Prefix Length” in the text, the relevant excerpt that seems to
> apply is this one:
>
> The way I read this is that implementations MAY choose to process the
> Prefix Length validation differently in on-link determination and SLAAC
> functions, but that it doesn’t seem to be expressly REQUIRED. Sadly, there
> don’t seem to be any other relevant texts about the Prefix Length.
>
> I can believe that LwIP is violating RFC 4861, but before I file an error
> report for this, I’d like to be able to cite the actual requirements
> keywords, and I’m concerned about the possibility this Note above may be
> used by the LwIP maintainers as a justification to reject the problem
> report.
>
>

--

---

From: james woodyatt <[email-masked]>
Date: Tue, 7 Mar 2017 11:11:06 -0800

On Mar 7, 2017, at 11:05, Timothy Winters <[email-masked]> wrote:
> "  Similarly,[ADDRCONF] may impose certain restrictions on the prefix length for
> It allows for rejection in ADDRCONF as LwIP does, but requires on-link determination.

Respectfully, my concern is that the Note, which immediately follows that excerpt (see my previous message), provides sufficient clarification that on-link determination is not REQUIRED to proceed if Prefix Length is invalid for address configuration purposes in a host that implements RFC 4862. It is merely OPTIONAL.

---

From: Timothy Winters <[email-masked]>
Date: Tue, 7 Mar 2017 14:18:24 -0500

Hi James,

The NOTE in 4861 states implementations can choose to process them
independently.    I'm not sure where you it allows for dropping on-link
determination if it fails.     Can you point me at the line that allows
this?

Regards,
Tim

On Tue, Mar 7, 2017 at 2:11 PM, james woodyatt <[email-masked]> wrote:

> Respectfully, my concern is that the Note, which immediately follows that
> excerpt (see my previous message), provides sufficient clarification that
> on-link determination is not REQUIRED to proceed if Prefix Length is
> invalid for address configuration purposes in a host that implements RFC
> 4862. It is merely OPTIONAL.
>
>

--

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 7 Mar 2017 20:18:25 +0100

Le 07/03/2017 à 19:36, 神明達哉 a écrit :
> At Tue, 7 Mar 2017 11:44:04 +0100, Alexandre Petrescu
> <[email-masked]> wrote:
>
>> It is the case with the fe80:://10 needing to become a fe80::/64,
>> and it is also the case when PIO in RA has a P1::/63.
>
> At least the above text from Section 5.5.3 of RFC4862 is irrelevant
> to link-local addresses.  The entire Section 5.5 is about "Creation
> of Global Addresses" as the title shows.  In the case of creating
> global addresses, I can't think of an interpretation of this text
>
> If the sum of the prefix length and interface identifier length does
> not equal 128 bits, the Prefix Information option MUST be ignored.

The Host won't drop it because there's that other RFC needing it, right?
As such this RFC should say "the received PIO value MUST not be used as
such to generate an address; but it could be used if padded with 0s, or
trimmed of other bits".

> len=64.  RFC4862 requires not to do so with the MUST.  BSDs
> implement it that way, and so does Linux (according to what I heard
> here).  I'm also pretty sure that there's a conformance test tool
> like that for "IPv6 ready logo" or USGv6 that confirms the intent of
> the RFC.  And so I'm also pretty sure that other major OSes interpret
> the RFC as it intends.  So, overall, I don't think it's just what a
> document editor intends in his mind, but a widely accepted
> interpretation.
>
> That said, there's always someone who understands any seemingly
> clear text differently from the actual intent, not to mention the
> recent row about EH insertion.

And there are people looking deep into RFC details to understand what
could be implemented correctly, in order to solve this
"single-/64-per-Host" delivered by 3GPP.

> So I'm not surprised that there are such people. If you think this
> point is so unclear for so many people, I'd suggest you write a
> clarification draft or submit an errata.  If you think we should
> actually allow the creation in such a case, that's a protocol change,
> and I'd suggest you write a draft to update RFC4862.  With luck, that
> will become the new standard.
>
> I don't think continuing this topic in this thread brings us
> anywhere, so I'll stop here.

This is the topic of allowing or not allowing 64 limit.

I think continuing to defend that 64 limit makes no sense after all
these problems.

The problem is in all these RFCs, and there is no need of a new one.  We 
wrote already too many on this topic of 64.

Alex

---

From: 神明達哉 <[email-masked]>
Date: Tue, 7 Mar 2017 11:34:46 -0800

At Tue, 7 Mar 2017 10:59:19 -0800,

> The way I read this is that implementations MAY choose to process the Prefix Length validation differently in on-link determination and SLAAC functions, but that it doesn’t seem to be expressly REQ…

Hmm...are seeking an RFC2119 keyword REQUIRED, MUST or SHALL in
RFC4861 that would make the LwIP implementation non-compliant on this
point undeniably?  If so, I'm afraid there is no such explicit
keyword.

Personally, however, the overall text both in RFC4861 and RFC4862 is
so clear that such an implementation would be considered
non-compliant.  In addition to other things pointed out in this
discussion, if RFC4862 Section 5.5.3 bullet d

would be interpreted as it allows the host to ignore such a prefix
(with L=1) even for on-link determination, we'd also apply the same
logic for other cases, like this one:

    a)  If the Autonomous flag is not set, silently ignore the Prefix
      Information option.

But, I (hopefully) believe no one would ever argue that a host is
allowed to ignore a prefix with A=0 and L=1 for on-link determination
because of this bullet.  So, if you see the context rather than a
specific sentence without taking into account the context, it's also
pretty clear to me that bullet d only talks about SLAAC.

If these circumstantial evidences are really not enough to convince
LwIP implementers, maybe we should file an errata for RFC4861 and/or
4862 to clarify that point.  I believe we can at least reach a wg
consensus that it's the intent of the RFCs (I'm not sure if we can add
an RFC2119 keyword in an errata, though).

--
JINMEI, Tatuya

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 7 Mar 2017 22:19:21 +0100

Thanks to this discussion, I would like to promote the following fact 
that I did not know:

If you say "FE80::" without telling the prefix length, that actually 
means "FE80::/9" (and not FE80::/10, nor FE80::/64).  Because 0xFE80  is 
"1111 1110 1000 0000" in binary representation.

Alex

---

From: james woodyatt <[email-masked]>
Date: Tue, 7 Mar 2017 13:22:36 -0800

Hi Tim,

To be clear, I’m not trying to be combative. I’m trying to prepare a case for the LwIP maintainers so that when I ask for my pull request to be considered I can refer them to this thread. Please be patient with me here.

On Mar 7, 2017, at 11:18, Timothy Winters <[email-masked]> wrote:
> 
> The NOTE in 4861 states implementations can choose to process them independently.    I'm not sure where you it allows for dropping on-link determination if it fails.     Can you point me at the line that allows this?

Okay, I’m going to go through this line by line, because I think the case that LwIP is clearly violating RFC 4861 is open to question. Furthermore, I think the inference from the informative text rather clearly implies that LwIP is not violating even the *spirit* of the text, much less the letter of its RFC 2119 keyword language.

Please help me find where this argument fails.

In RFC 4862, §6.3.4 Processing Received Router Advertisements:

>> Similarly, [ADDRCONF] may impose certain restrictions on the prefix length for address configuration purposes.

I read this to say that additional requirements language MAY apply to processing the Prefix Length field in PIO elements (the relevant sections are quoted below) for hosts capable of stateless address configuration.

>> Therefore, the prefix might be rejected by [ADDRCONF] implementation in the host.

I read this as recognizing implicitly that it’s OPTIONAL (implicitly, because of the use of “might” instead of “may” here is not RFC 2119) for a host to reject a PIO because of the additional “certain restrictions on prefix length” it imposes, cited in RFC 4861.

>> However, the prefix length is still valid for on-link determination when combined with other flags in the prefix option.

I read this at face value: prefixes are valid for on-link determination when combined with other flags in the PIO element *and*, in light of the preceding sentence, when the “certain restrictions on prefix length” imposed by RFC 4862 do not apply, because for example, the host is configured not to use stateless address configuration for the interface where the RA message was received.

Further discussion is entailed here, because this where the argument gets a little twisty and legalistic, but as I said, I’m trying to prepare a case for defending the correctness of the USGv6 and IPv6 Ready Logo tests to the maintainers of the LwIP project by taking the opposite view.

At this point in the text, it’s an open question which document has primacy over the validity of a PIO in the case of a host that claims to conform with both RFC 4861 and RFC 4862, but see the following Note, which seems to be there for the express purpose of resolving the question.

>>       independently on the prefixes that have the appropriate flag set.

I read this as RFC 4861 again recognizing implicitly that it's OPTIONAL (using “can” instead of “may”) whether hosts process PIO elements for on-link determination even when they are rejected by RFC 4862.

For this reason, for hosts that choose to reject PIO elements, even for on-link determination, when the “certain restrictions on the prefix length” in RFC 4862 apply, the relevant text from RFC 4862 needs to be consulted.

In RFC 4862, §5.3 Creation of Link Local Addresses:

>> If the sum of the link-local prefix length and N is larger than 128, autoconfiguration fails and manual configuration is required.  The length of the interface identifier is defined in a separate link- type-specific document, which should also be consistent with the address architecture [RFC4291] (see Section 2).  These documents will carefully define the length so that link-local addresses can be autoconfigured on the link.

The key sentence in this passage is "The length of the interface identifier is defined in a separate link- type-specific document, which should also be consistent with the address architecture [RFC4291] (see Section 2).”

As we are preparing to publish a successor to RFC 4291, I will quote the relevant (and controversial) section of I-D.ietf-6man-rfc4291bis-07:

>> IPv6 unicast routing is based on prefixes of any valid length up to 128 [BCP198].  For example, [RFC6164] standardises 127 bit prefixes on inter-router point-to-point links.  However, the Interface ID of all unicast addresses, except those that start with the binary value 000, is required to be 64 bits long.  The rationale for the 64 bit boundary in IPv6 addresses can be found in [RFC7421].

In light of the plethora of updates to RFC 4291, I believe the above to be a reasonable clarification of the existing text in RFC 7136, §5, which expressly updates the original text in RFC 4291, §2.5.1 as follows:

>> For all unicast addresses, except those that start with the binary value 000, Interface IDs are required to be 64 bits long.  If derived from an IEEE MAC-layer address, they must be constructed in Modified EUI-64 format.

In both cases, RFC 4291 (updated by RFC 7136) and I-D.ietf-6man-rfc4291bis-07 (currently awaiting IESG writeup), the requirement is that IID length for all unicast addresses starting with 0b000 is 64 bits. Which is relevant to the excerpt above in RFC 4862, §5.3 saying that “the length of the interface identifier is defined in a separate link- type-specific document, which should also be consistent with the address architecture [RFC4291] (see Section 2).”

Note Well: the SHOULD in that sentence is a recommendation not a requirement.

So, I read RFC 4862 to REQUIRE that the IID length be defined in a separate link-type document and to RECOMMEND that the IID length be 64 bits. (Note: the LwIP implementation only supports link types where the IID length is already defined in standard documents to be 64 bits).

Now, this is important because RFC 4862, §5.5.3 Router Advertisement Processing is the text that imposes the “certain restrictions on prefix length” referenced in RFC 4861, §6.3.4 Processing Received Router Advertisements. Here’s what that says in ¶d after specifying how to form an address by stateless address configuration:

>> If the sum of the prefix length and interface identifier length does not equal 128 bits, the Prefix Information option MUST be ignored.

Reading this in light of the Note in RFC 4862, §6.3.4, it clearly imposes “certain restriction on prefix length” for the validity of PIO elements. It further REQUIRES that PIO elements with invalid Prefix Length fields not be used for stateless address configuration. It does not, however, explicitly override the Note in RFC 4862, §6.3.4 that clarifies that it is OPTIONAL for hosts to process PIO elements for on-link determination even when they have invalid Prefix Length for stateless address configuration.

>> The length of the interface identifier is defined in a separate link-type specific document, which should also be consistent with the address architecture [RFC4291] (see Section 2).

Here again, RFC 4862 repeats its previous guidance to REQUIRE that the IID length be defined in a separate link-type document and to RECOMMEND that the IID length be 64 bits (which LwIP requires of all supported interface types).

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.)

Another text relevant to this discussion is IPv6 Subnet Model [RFC 5942], which has this to say in §5 Observed Incorrect Implementation Behavior:

>> One incorrect implementation behavior illustrates the severe consequences when the IPv6 subnet model is not understood by the implementers of several popular host operating systems.  In an access concentrator network ([RFC4388]), a host receives a Router Advertisement message with no on-link prefix advertised.

For the purposes of this discussion, I invite the reader to imagine in this scenario the additional consideration that the Prefix Length is not valid for stateless address configuration and the A flag is also zero. In other words, a scenario where the rules in question here are relevant.

>> An address could be acquired through the DHCPv6 identity association for non-temporary addresses (IA_NA) option from [RFC3315] (which does not include a prefix length), or through manual configuration (if no prefix length is specified).

This address would have to have a valid IID for the link type, according to RFC 4291. The PIO element here with A=0 and L=0 and Prefix Length > 64 is simply advertising legitimately that the router provides reachability to this longer prefix only to a subset of the valid host addresses on the subnet. Hosts are not required to add the prefix to the on-link prefix list, nor to configure an address in that prefix.

Hosts could be manually configure addresses with that prefix or obtain them from DHCPv6 (they would be reachable), but they cannot use SLAAC to assign addresses with that prefix. And RFC 5942 says they cannot add the prefix to the on-link prefix list. (It does have some squirrels bits about RFC 4903.)

The rest of this text in RFC 5942 goes on to describe the observed incorrect behavior in this scenario, and it’s behavior that LwIP does not have.

>> The host incorrectly assumes an invented prefix is on-link.

In other words, it’s violating RFC 4861 by failing to recognize what L=0 signifies.

>> This invented prefix typically is a /64 that was written by the developer of the operating system network module API to any IPv6 application as a "default" prefix length when a length isn't specified. This may cause the API to seem to work in the case of a network interface initiating stateless address autoconfiguration (SLAAC); however, it can cause connectivity problems in Non-Broadcast Multi-Access (NBMA) networks.  Having incorrectly assumed an invented prefix, the host performs address resolution when the host should send all non-link-local traffic to a default router. Neither the router nor any other host will respond to the address resolution, preventing this host from sending IPv6 traffic.

I should observe again here that LwIP performs correctly here, despite having an implementation defined restriction on link types that have IID length of 64 bits. It does not add the prefix for two reasons, not just one: the L flag is zero, and the Prefix Length is invalid.

Its behavior also complies with all the rules defined in RFC 5942, §4 Host Rules, which I will not repeat here.

—

In summary, there is a deficit of RFC 2119 keyword language here, and we have to make the case that the standards texts make a sufficiently strong implicit case rather than an explicit normative requirement.

As explained above, it sure looks to me like a very fair reading of the implicit requirements language is that LwIP is within the limits of RFC 4291, RFC 4861 and RFC 4862 when it choose the option of ignoring PIO elements with invalid prefix length for IID on the underlying link type.

Yes, the USGv6 and IPv6 Ready Logo tests are well within their rights to apply additional requirements beyond the IETF standards, but it seems like a strict interpretation of the standards allow for LwIP to claim conformance.

How can we counter this argument?

---

From: Mark Smith <[email-masked]>
Date: Wed, 8 Mar 2017 08:33:31 +1100

Hi Alex,

I don't think it is necessary to come up with a further text representation
to distinguish between addresses and prefixes.

A prefix is a general concept, it specifies, within a set of bits, the set
and values of the bits that are defined, and the range of bits that are
ignored, in the context where the prefix is used.

fe80::/10 is the link-local prefix from within which all more specific link
local prefixes come from.

An address is a specific example of a prefix, where all bit's value are
defined, meaning none are ignored. An address is therefore a prefix with a
/128 prefix length.

A prefix without a shown prefix length is assumed to have a prefix length
of /128. If that doesn't make sense in context, then the error is that the
prefix length hasn't been specified. That's the fault of the writer not the
reader.

We could entirely eliminate the term 'address' by replacing it with '/128
length prefix'. It would be entirely correct, but clumsy.

This is all true for IPv4 too, as that is where it has come from. It has
been accurate for long enough that trying to change it may cause more
confusion not less.

Regards,
Mark.

On 8 Mar. 2017 2:06 am, "Alexandre Petrescu" <[email-masked]>
wrote:

Yes.

A useful equation for programmer is like this: m+n MUST equal 128.  You are
not allowed to pad if you receive a /63 in RA, or if you have a
IID-shorter-than-64; you are not allowed to make addresses of length 129.

Alex

---

From: [email-masked]
Date: Tue, 7 Mar 2017 22:33:58 +0100

> Thanks to this discussion, I would like to promote the following fact that I did not know:
> 
> If you say "FE80::" without telling the prefix length, that actually means "FE80::/9" (and not FE80::/10, nor FE80::/64).  Because 0xFE80  is "1111 1110 1000 0000" in binary representation.

No it doesn't.

FE80:: means FE80:0000:0000:0000:0000:0000:0000:0000

Cheers,
Ole

---

From: [email-masked]
Date: Tue, 7 Mar 2017 22:41:55 +0100

> On 7 Mar 2017, at 22:22, james woodyatt <[email-masked]> wrote:
> 

We're not writing law, we're specifying what it takes to have implementations of a specification interoperate.

That implementation would fail to interoperate.

Cheers,
Ole

---

From: Mark Andrews <[email-masked]>
Date: Wed, 08 Mar 2017 14:28:26 +1100

> "1111 1110 1000 0000" in binary representation.

No.

FE80:: is always 128 bits.
FE80::/9 says take the first 9 bits from those 128 bits.
FE80::/10 says take the first 10 bits from those 128 bits.
FE80::/64 says take the first 64 bits from those 128 bits.
FE80::/128 says take the first 128 bits from those 128 bits.

All link local addresses have a prefix of FE80::/10.
Link local addresses on ethernet are further restricted to
have a prefix of FE80::/64.  They are a strict subset of
all valid link local addresses.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Mark Smith <[email-masked]>
Date: Wed, 8 Mar 2017 16:26:08 +1100

No it doesn't.

Or

FE80:0000:0000:0000:0000:0000:0000:0000/128

which is an address within the LL space.

Possible a statement that a /128 is implied if no prefix length is stated,
and is the definition of an "address", could be put in RFC4291bis during
AUTH48? Is it a trivial enough change (I think it probably isn't, although
it'd be a bit of a shame to have to wait until the next RFC revision of it.)

Regards,
Mark.

Cheers,
Ole

---

From: [email-masked]
Date: Wed, 8 Mar 2017 08:36:13 +0100

Mark,

> Possible a statement that a /128 is implied if no prefix length is stated, and is the definition of an "address", could be put in RFC4291bis during AUTH48? Is it a trivial enough change (I think it probably isn't, although it'd be a bit of a shame to have to wait until the next RFC revision of it.)

I don't see why it would be necessary to imply anything.
FE80:: is an address. Not a prefix. E.g. you wouldn't say the packet was sent from the source FE80::/128.

Cheers,
Ole

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 8 Mar 2017 09:00:27 +0100

> FE80::/9 says take the first 9 bits from those 128 bits.

YEs, and so it is if we just say "prefix FE80::" without specifying a plen.

> FE80::/10 says take the first 10 bits from those 128 bits.

YEs, and thus FE81::, FE82:: ... FEBF:: are all LL addresses.

I wonder why people only say FE80:: when talking LL address?

> All link local addresses have a prefix of FE80::/10.

But that does not mean that the notation of all LLs must start precisely 
with "FE80".

These notations could start with "FE81", "FE82" ... "FEBF".  Up to 
"FEC0" which is a GUA not an LL.

As such, a better way would be to say that LL addresses are of the form 
"FE##" where ## range from 81 to BF hexa.

> all valid link local addresses.

YEs, and moreover, in this particular LL case, I suppose not only 
IP-over-Ethernet requires FE80::/64 but also SLAAC.  I.e. SLAAC on _any_ 
link (be it Ethernet or any other future link) seems to require the use 
of FE80::/64 prefix and does not allow for "FE81" or "FEBF".

An I-D describing the formation of LL addresses out of "FE##:://10" 
prefixes could make sense.

Alex

---

From: Mark Smith <[email-masked]>
Date: Wed, 8 Mar 2017 21:07:38 +1100

On 8 Mar. 2017 6:36 pm, <[email-masked]> wrote:

Mark,

>I don't see why it would be necessary to imply anything.

I say implied, because when "FE80::" is written that way, it is saying
that for the purposes of IPv6 processing (what ever that processing
may be), all 128 bits are significant - the "/128" is implicit.
"FE80::/128" is also saying that, except that it is explicitly stating
that all 128 bits are significant.

>FE80:: is an address. Not a prefix.

If it isn't a prefix because it doesn't have "/128" on it, then that
is what makes it an "address". However, "FE80::/128" is an entirely
accurate and exact equivalent replacement for it, so functionally,
"FE80::" and "FE80::/128" are equal.

>E.g. you wouldn't say the packet was sent from the source FE80::/128.

You wouldn't say it, but you could say it, it would be correct.

Here's an example of their equivalence.

I assign an IPv6 address to an interface under Linux, and it shows it
as a /128 prefix.

[root@opy mark]# ip -6 addr add 2001:db8::1 dev dummy0
[root@opy mark]# ip -6 addr show dev dummy0
9: dummy0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 state UNKNOWN qlen 1000
    inet6 2001:db8::1/128 scope global
       valid_lft forever preferred_lft forever
    inet6 fe80::c087:1cff:fe7a:413c/64 scope link
       valid_lft forever preferred_lft forever
[root@opy mark]#

I suppose under Linux, packets are sourced from /128s ;-)

Regards,
Mark.

---

From: [email-masked]
Date: Wed, 8 Mar 2017 11:15:36 +0100

Mark,

[...]

> I suppose under Linux, packets are sourced from /128s ;-)

Many implementations conflate configuring an address and configuring an onlink prefix / connected route.
That doesn't mean they are the same thing.

Aren't we already far out into the weeds with this discussion?

Ole

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 8 Mar 2017 12:03:42 +0100

> Aren't we already far out into the weeds with this discussion?

The discussion went far indeed.

If I were to conclude:

RFC4291bis should clear the current confusion between FE80::/9, 
FE80::/10 and FE80::/64.  Keep FE80::/10 only, add statement that is not 
a /9 (despite its last set bit at position number 9), and remove 
FE80::/64 throughout.

RFC4862 should no longer say "prefix FE80::" because it is confusing. 
There is more to be fixed there, but separate discussion.

It would be good too if RFC4291bis said in a small place that "FEBF::1 
is a Link-local address too".

The fact that everybody always says "an FE80 is an LL", or "an LL is an 
FE80" does not mean FEBF::1 is not an LL too.  And that has deep 
consequences to address plans.

Alex

---

From: [email-masked]
Date: Wed, 8 Mar 2017 12:18:28 +0100

> The discussion went far indeed.

You probably shouldn't.

> RFC4291bis should clear the current confusion between FE80::/9, FE80::/10 and FE80::/64.  Keep FE80::/10 only, add statement that is not a /9 (despite its last set bit at position number 9), and remove FE80::/64 throughout.

No. I don't think anyone apart from you have been confused.

> RFC4862 should no longer say "prefix FE80::" because it is confusing. There is more to be fixed there, but separate discussion.

Agree.

> It would be good too if RFC4291bis said in a small place that "FEBF::1 is a Link-local address too".

No. It says the link-local prefix is FE80/10 + zeroes + interface-id.
If you have a 118 bit long IID you can create the above link-local address, but that really does not have to be stated.

> The fact that everybody always says "an FE80 is an LL", or "an LL is an FE80" does not mean FEBF::1 is not an LL too.  And that has deep consequences to address plans.

No it hasn't.

Ole

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 8 Mar 2017 12:27:46 +0100

Le 08/03/2017 à 12:18, [email-masked] a écrit :
[...]
> No. It says the link-local prefix is FE80/10 + zeroes +
> interface-id. If you have a 118 bit long IID you can create the above
> link-local address, but that really does not have to be stated.

But to let that happen, it should also refrain from picturing or writing 
that IIDs must be of 64bit length.  If it needs to give examples it 
should rather use "e.g. /118".

>> The fact that everybody always says "an FE80 is an LL", or "an LL
>> is an FE80" does not mean FEBF::1 is not an LL too.  And that has
>> deep consequences to address plans.
>
> No it hasn't.

Well...

Alex

---

From: [email-masked]
Date: Wed, 8 Mar 2017 12:35:10 +0100

> But to let that happen, it should also refrain from picturing or writing that IIDs must be of 64bit length.  If it needs to give examples it should rather use "e.g. /118".

Write an IPv6 over foo document with 118 bit IIDs.

There is a good reason the prefix-length of the link-local address space is explicitly specified.
If all nodes on a link didn't agree on this value, you would get into problems with protocols using the link-local address.
E.g. address resolution for the default router, or sending packets from DHCP server to host...

Ole

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 8 Mar 2017 15:23:54 +0100

Le 08/03/2017 à 12:35, [email-masked] a écrit :
>>> interface-id. If you have a 118 bit long IID you can create the
>>> above link-local address, but that really does not have to be
>>> stated.
>>
>> But to let that happen, it should also refrain from picturing or
>> writing that IIDs must be of 64bit length.  If it needs to give
>> examples it should rather use "e.g. /118".
>

Invitation considered.

> space is explicitly specified.

Well, I think there is no such reason.

> If all nodes on a link didn't agree on this value, you would get into
> problems with protocols using the link-local address.

Well, I dont think so.

> E.g. address resolution for the default router,

Well, address resolution: the default router sends NA including its 
source address.  It does not include a plen.

If the Host does not want to wait for the NA it will send an NS; this NS
does not include a plen either.

I dont know where do you see the need to agree on a plen for the LL
addresses?  Can I know?

> or sending packets from DHCP server to host...

Well... it's the same: NS and NA are needed, and these dont use a plen.

Besides, LL addresses are only valid on a link; so there is no need to 
perform some matching in the tables to identify whether should go to rt 
table or to neighbor cache (which would need plen, or otherwise exact 
match).

Alex

>>>> The fact that everybody always says "an FE80 is an LL", or "an
>>>>  LL is an FE80" does not mean FEBF::1 is not an LL too.  And
>>>> that has deep consequences to address plans.
>>>
>>> No it hasn't.
>>
>> Well...
>
> Ole
>

---

From: [email-masked]
Date: Wed, 8 Mar 2017 15:34:05 +0100

Alex,

> Well, address resolution: the default router sends NA including its source address.  It does not include a plen.
> 

https://tools.ietf.org/html/rfc4861#section-5.2

Has a good introduction to the topic.

> Besides, LL addresses are only valid on a link; so there is no need to perform some matching in the tables to identify whether should go to rt table or to neighbor cache (which would need plen, or otherwise exact match).

on-link determination also applies to link-local addresses.

Are you by any chance talking about how you _would_ have liked the IPv6 specifications to be, as opposed to how they actually are?

Ole

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 8 Mar 2017 16:45:49 +0100

Le 08/03/2017 à 15:34, [email-masked] a écrit :
[...]

I guess you refer to this part of that section:
> The sender performs a longest prefix match against the Prefix List to
> determine whether the packet's destination is on- or off-link.

With LL addresses the destination is necessarily on-link, so why 
performing that check?

Second, a "fe80::/64" is the same on each interface, so performing that 
check can not distinguish between interfaces.  It could as well be a 
"fe80::/10."

Or maybe you referred to another paragraph that I miss.

Yours,

Alex

---

From: james woodyatt <[email-masked]>
Date: Wed, 8 Mar 2017 12:20:38 -0800

> We're not writing law, we're specifying what it takes to have implementations of a specification interoperate.

I agree, and I contend there's something missing here in what we’ve said it takes to interoperate.

> That implementation would fail to interoperate.

As I wrote to the other participants in this exchange off list, I remain convinced that the interoperability issue here is due to system administrators ignoring the recommendation in RFC 4862 to always use a valid Prefix Length for the link type in PIO elements without also ensuring that all hosts on the link implement behavior that RFC 4861 implies is OPTIONAL for performing on-link determination.

Here I will add that I’m not going to push for changes to LwIP either locally or upstream until I’m persuaded this interpretation of the existing text is wrong.

---

From: David Farmer <[email-masked]>
Date: Wed, 8 Mar 2017 15:04:54 -0600

On Wed, Mar 8, 2017 at 2:20 PM, james woodyatt <[email-masked]> wrote:

> In summary, there is a deficit of RFC 2119 keyword language here, and we
> have to make the case that the standards texts make a sufficiently strong
> implicit case rather than an explicit normative requirement.
>
> As explained above, it sure looks to me like a very fair reading of the
> implicit requirements language is that LwIP is within the limits of RFC
> 4291, RFC 4861 and RFC 4862 when it choose the option of ignoring PIO
> elements with invalid prefix length for IID on the underlying link type.
>
> Yes, the USGv6 and IPv6 Ready Logo tests are well within their rights to
> apply additional requirements beyond the IETF standards, but it seems like
> a strict interpretation of the standards allow for LwIP to claim
> conformance.
>
> We're not writing law, we're specifying what it takes to have
> implementations of a specification interoperate.
>
>
> As I wrote to the other participants in this exchange off list, I remain
> convinced that the interoperability issue here is due to system
> administrators ignoring the recommendation in RFC 4862 to always use a
> valid Prefix Length for the link type in PIO elements without also ensuring
> that all hosts on the link implement behavior that RFC 4861 implies is
> OPTIONAL for performing on-link determination.
>
> Here I will add that I’m not going to push for changes to LwIP either
> locally or upstream until I’m persuaded this interpretation of the existing
> text is wrong.
>

So one question, where in your mind do the standards say what is a valid
prefix for PIO on link? Or the conversely, where does it define invalid
prefixes for such?

Thanks

---

From: Timothy Winters <[email-masked]>
Date: Wed, 8 Mar 2017 16:54:43 -0500

Hi James,

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:
https://mailarchive.ietf.org/arch/search/?email_list=ipv6&q=Requirement+for+64bit+I%2FF+ID&so=date&gbt=1&index=rJtLf5Krh0X9vg3vYts_xO1oUCw

Final Decision:
https://mailarchive.ietf.org/arch/msg/ipv6/IfWdv79U0k9PbwK6-lAIk4yeyK4

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).

~Tim

--

---

From: james woodyatt <[email-masked]>
Date: Wed, 8 Mar 2017 14:38:21 -0800

On Mar 8, 2017, at 13:54, Timothy Winters <[email-masked]> 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:
> https://mailarchive.ietf.org/arch/search/?email_list=ipv6&q=Requirement+for+64bit+I%2FF+ID&so=date&gbt=1&index=rJtLf5Krh0X9vg3vYts_xO1oUCw <https://mailarchive.ietf.org/arch/search/?email_list=ipv6&q=Requirement+for+64bit+I/F+ID&so=date&gbt=1&index=rJtLf5Krh0X9vg3vYts_xO1oUCw>
> 
> Final Decision:
> https://mailarchive.ietf.org/arch/msg/ipv6/IfWdv79U0k9PbwK6-lAIk4yeyK4 <https://mailarchive.ietf.org/arch/msg/ipv6/IfWdv79U0k9PbwK6-lAIk4yeyK4>
> 
> 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.

 	<https://mailarchive.ietf.org/arch/msg/ipv6/oZ3dnjn3-tl8y1Gypgo3Eycco6g <https://mailarchive.ietf.org/arch/msg/ipv6/oZ3dnjn3-tl8y1Gypgo3Eycco6g>>

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

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.

---

From: Timothy Winters <[email-masked]>
Date: Wed, 8 Mar 2017 18:23:55 -0500

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
prefix)
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
revised/relaxed
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...

Regards,
Tim

On Wed, Mar 8, 2017 at 5:38 PM, james woodyatt <[email-masked]> wrote:

> https://mailarchive.ietf.org/arch/search/?email_list=ipv6&
> q=Requirement+for+64bit+I%2FF+ID&so=date&gbt=1&index=
> rJtLf5Krh0X9vg3vYts_xO1oUCw
> <https://mailarchive.ietf.org/arch/search/?email_list=ipv6&q=Requirement+for+64bit+I/F+ID&so=date&gbt=1&index=rJtLf5Krh0X9vg3vYts_xO1oUCw>
>
> Final Decision:
> 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.
>
>   <https://mailarchive.ietf.org/arch/msg/ipv6/oZ3dnjn3-tl8y1Gypgo3Eycco6g>
>
> >> 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.
>
> >> 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.
>
>

--

---

From: 神明達哉 <[email-masked]>
Date: Wed, 8 Mar 2017 16:33:50 -0800

At Wed, 8 Mar 2017 16:54:43 -0500,

> https://mailarchive.ietf.org/arch/search/?email_list=ipv6&q=Requirement+for+64bit+I%2FF+ID&so=date&gbt=1&index=rJtLf5Krh0X9vg3vYts_xO1oUCw

I guess a more relevant discussion is this:
https://mailarchive.ietf.org/arch/search/?email_list=ipv6&q=Reception+of+prefix+option+with+prefix+length+%3E+64&so=date&gbt=1

In that thread, I asked the very same question as that we are having now:

>> For example, assuming a 64-bit interface identifier, if we receive
>> an RA containing an prefix information option with 80-bit prefix
>> length and with the L and A bits both being set, [...]

>> [...] I think the receiving node should still consider the
>> prefix as valid in terms of ND (i.e., consider it as "on-link") and
>> modify the next-hop determination accordingly.

>> The questions are:

>> 1. is this a correct understanding of the intention of RFC2461?

And, Erik Nordmark ("the father of ND") gave a "yes" answer to the
question:
https://www.ietf.org/mail-archive/web/ipv6/current/msg01801.html

So, the fact is that:
- the "lenient behavior" (like what BSDs or Linux implementations do)
  is the intent of the very original designer of ND
- we explicitly discussed this in the work on rfc2461bis and confirmed
  it

I'm not sure if this helps the current discussion, though, since one
may still insist that he is not convinced unless the RFC enforces this
intent with a strongest RFC2119 keyword (e.g., a MUST).

--
JINMEI, Tatuya

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 9 Mar 2017 08:58:38 +0100

Hi,

Thanks for the pointers to the earlier discussion.

Le 08/03/2017 à 22:54, Timothy Winters a écrit :
> Hi James,
>
> 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:
> https://mailarchive.ietf.org/arch/msg/ipv6/IfWdv79U0k9PbwK6-lAIk4yeyK4

I think that decision is that ND should work with arbitrary plens, not
just 64.

In light of that ND decision, it is strange to see an RFC at the same
time IPv6 Addressing Architecture mandating IIDs 64 (and implicit
mathematical plen 128).

Retrospectively:

At time of that discussion, year 2004, there was no IPv6 on cellular
links, [I-D]. Since then 3GPP got many recommendations from IETF about
how to run IPv6. The result is 3GPP User Equipment links only support a
single 64 today.

My supposition, and many indications converge, is that the 64
recommendation from the IPv6 Addressing Architecture RFC led to this
undesirable situation of a single 64 for an UE.

If we were again in 2004, I would tell that decision maker: not only ND
should avoid the 64 limit, but the IPv6 Addressing Archi should too.

That would have saved us many recent RFCs discussing 64 (the BCP CIDR
IPv6, the multiple-address per Host recommendation, the why64 RFC, and
many others I mistakenly forgot).

We are now in 2017...

Alex

---

From: [email-masked]
Date: Thu, 9 Mar 2017 09:18:34 +0100

Alex,

[...]

> undesirable situation of a single 64 for an UE.

That is one speculation. You may reconstruct history differently:
If it wasn't for RFC6177/RFC3177 combined with the 64-bit boundary (and SLAAC), what you would have had on a UE would be a single IPv6 address.

Cheers,
Ole

---

From: Erik Kline <[email-masked]>
Date: Thu, 9 Mar 2017 20:39:43 +0900

On 9 March 2017 at 17:18, <[email-masked]> wrote:

> If it wasn't for RFC6177/RFC3177 combined with the 64-bit boundary (and
> SLAAC), what you would have had on a UE would be a single IPv6 address.
>

Precisely.

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 9 Mar 2017 13:51:58 +0100

Le 09/03/2017 à 09:18, [email-masked] a écrit :
> Alex,
>
>
> [...]
>
>> Retrospectively:
>>
>> At time of that discussion, year 2004, there was no IPv6 on
>> cellular links, [I-D]. Since then 3GPP got many recommendations
>> from IETF about how to run IPv6. The result is 3GPP User Equipment
>> links only support a single 64 today.
>>
>> recommendation from the IPv6 Addressing Architecture RFC led to
>> this undesirable situation of a single 64 for an UE.
>
> That is one speculation. You may reconstruct history differently: If
> it wasn't for RFC6177/RFC3177 combined with the 64-bit boundary (and

:-) I can agree :-(

But I cant continue that way...

Alex

---

From: Mark Andrews <[email-masked]>
Date: Fri, 10 Mar 2017 09:40:14 +1100

In message <[email-masked]>, Alexandre Petrescu writes:
> Le 08/03/2017 =E0 22:54, Timothy Winters a =E9crit :
> > Hi James,
> >
> > https://mailarchive.ietf.org/arch/search/?email_list=3Dipv6&q=3DRequireme=
> nt+for+64bit+I%2FF+ID&so=3Ddate&gbt=3D1&index=3DrJtLf5Krh0X9vg3vYts_xO1oUCw
> >
> >
> >
> >
> Final Decision:

No.  The deliberate decision to ignore DHCP-PD lead to it.  It was too
new / too late in the process / not enough implementations / not enough
experience.