Subject: <draft-ietf-6man-rfc4291bis-08.txt>

From: Bob Hinden <[email-masked]>
Date: Tue, 20 Jun 2017 15:14:18 +0300

Hi,

I published a new 6man w.g. version (-08) of the RFC4291bis draft.  See links below.

The summary of the changes are:

        o  Added Note: to Section 2 that the term "prefix" is used in
           different contexts in IPv6: a prefix used by a routing
           protocol, a prefix used by a node to determine if another
           node is connected to the same link, and a prefix used to
           construct the complete address of a node.

        o  Based on results of IETF last call and extensive w.g. list
           discussion, revised text to clarify that 64 bit Interface IDs
           are used except when the first three bits of the address are
           000, or addresses are manually configured, or when defined by
           a standard track document.  This text was moved from
           Section 2.4 and is now consolidated in Section 2.4.1. Also
           removed text in Section 2.4.4 relating to 64 bit Interface
           IDs.

        o  Removed instruction to IANA fix error in Port Number
           assignment.  IANA fixed the error on 4 March 2017.

        o  Editorial changes.

A diff from the previous version is available at:

  https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-rfc4291bis-08

This is part of the project to move the core IPv6 specifications to Internet Standard.

Thanks,
Bob

> A new version of I-D, draft-ietf-6man-rfc4291bis-08.txt
> has been successfully submitted by Robert M. Hinden and posted to the
> IETF repository.
> 
> Name:		draft-ietf-6man-rfc4291bis
> Revision:	08
> Title:		IP Version 6 Addressing Architecture
> Document date:	2017-06-20
> Group:		6man
> Pages:		33
> URL:            https://www.ietf.org/internet-drafts/draft-ietf-6man-rfc4291bis-08.txt
> Status:         https://datatracker.ietf.org/doc/draft-ietf-6man-rfc4291bis/
> Htmlized:       https://tools.ietf.org/html/draft-ietf-6man-rfc4291bis-08
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-6man-rfc4291bis-08
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-rfc4291bis-08
> 
> Abstract:
>   This specification defines the addressing architecture of the IP
>   Version 6 (IPv6) protocol.  The document includes the IPv6 addressing
>   model, text representations of IPv6 addresses, definition of IPv6
>   unicast addresses, anycast addresses, and multicast addresses, and an
>   IPv6 node's required addresses.
> 
>   This document obsoletes RFC 4291, "IP Version 6 Addressing
>   Architecture".

---

From: David Farmer <[email-masked]>
Date: Tue, 20 Jun 2017 16:34:13 -0500

I think this is getting really close.  However, there still seems to be an
implication that a subnet must be /64 or 64 bits for both address
generation and on-link determination.

Subnetting (for IPv4) is discussed in a series of RFCs[1], culminating in
the Internet Standard Subnetting Procedure [RFC950].  The closest thing to
a definition for the term subnet comes in the overview for RFC950. Subnets
"are logically visible sub-sections of a single Internet network." However,
it seems clear that the term is equally important to two of the aspects we
are talking about, it is about both address generation and on-link
determination.

If RFC4291bis is going to use the term subnet, it's use should either be
consistent with the meaning in RFC950, or it should be abundantly clear how
the use of the term differs from it's use in RFC950.  There should be no
ambiguity, unless clearly stated otherwise, the term subnet means what it
means in RFC950. In fact let's be clear, the reason the term is being used
here is because of the comfort level that comes from the decades of use of
the term as derived from it's RFC950 meaning.

Because the current use of the term "subnet" in RFC4291bis-08 doesn't seem
to distinguish between address generation and on-link determination, there
still seems to be an implication that a subnet must be /64, or 64 bits, for
both address generation and on-link determination.

One possible way to break this improper implication, would be to qualify
the statement that Interface Identifiers are 64 bits long to address
generation and add to the note that for on-link determination prefixes and
IIDs can be any length.  How about something like this;

   When generating an address, Interface Identifiers are required to be

   64 bits long except if the first three bits of the address are 000,

   when addresses are manually configured, or by exceptions defined in

   standards track documents. The rationale for using 64 bit Interface

   Identifiers can be found in [RFC7421
<https://tools.ietf.org/html/rfc7421>].  An example of a standards

   track exception is [RFC6164 <https://tools.ietf.org/html/rfc6164>]
that standardizes 127 bit prefixes on

   inter-router point-to-point links.

      Note: In the case of on-link determination and as a result when

      a prefix length is provide with a manually configured address, the

      Prefix and Interface Identifier can be any length as long as they

      add up to 128, but are recommended to be 64 bits.

Also, based on the definition of subnet, in section 2.4.4 it seems critical
that m>=1.  If it is not and m=0, then we can't be talking about /64
subnets, we are talking about a /64 network.  Therefore, "m" must be
greater than or equal to 1, for you to even be properly talking about the
term subnet in IPv6 addressing. Besides adding that point to this section,
a reference to RFC6177 seems appropriate too.

Thanks

David Farmer

[1] RFC917, RFC925, RFC932, RFC936, RFC940
https://tools.ietf.org/html/rfc917
https://tools.ietf.org/html/rfc925
https://tools.ietf.org/html/rfc932
https://tools.ietf.org/html/rfc936
https://tools.ietf.org/html/rfc940
https://tools.ietf.org/html/rfc950

-- 
===============================================
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: Brian E Carpenter <[email-masked]>
Date: Thu, 22 Jun 2017 09:38:04 +1200

> generation and on-link determination.

Yes, that's what it says, except for documented exceptions. As far as I
understand the motivation of my co-authors on draft-bourbaki, their main
objection to the previous rfc4291bis was that it didn't allow for those
documented exceptions.

Since SLAAC has always assumed that the two lengths are equal, I don't
see any discrepancy between rfc4291bis-08 and reality, which is as it
should be for an Internet Standard.

    Brian

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: james woodyatt <[email-masked]>
Date: Wed, 21 Jun 2017 15:04:37 -0700

> I published a new 6man w.g. version (-08) of the RFC4291bis draft.  See links below.

These changes make some of the improvements I recommended in <https://mailarchive.ietf.org/arch/msg/ipv6/F_RWP3lNRXyHOCaY8uUG-ejfwQo <https://mailarchive.ietf.org/arch/msg/ipv6/F_RWP3lNRXyHOCaY8uUG-ejfwQo>> but they leave a number of my criticisms unaddressed. It also introduces what I believe are several complications that follow from its new “note" about interface identifiers in manually configured addresses having any permissible length provided the prefix and the identifier add up to 128 bits. I think there are specific requirements for interface identifiers in RFC 4291 (and this -08 draft too) that are worded as if they apply regardless of the mechanism used to assign and configure them, e.g. uniqueness properties, and so on, that entail using the same length for all interface identifiers for a given link type. I’m not sure how that language can be interpreted properly if manual configuration allows for interface identifiers of any arbitrary length.

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

---

From: 神明達哉 <[email-masked]>
Date: Tue, 27 Jun 2017 14:39:24 -0700

At Thu, 22 Jun 2017 09:38:04 +1200,
Brian E Carpenter <[email-masked]> wrote:

> Since SLAAC has always assumed that the two lengths are equal,

What do you mean by this?  Do you mean "SLAAC has always assumed the
prefix length for address generation and the prefix length for on-link
determination are equal"?  Specifically which text of RFC4862 says
that (or are you referring to other RFCs for SLAAC)?

--
JINMEI, Tatuya

---

From: james woodyatt <[email-masked]>
Date: Tue, 27 Jun 2017 15:12:29 -0700

On Jun 21, 2017, at 14:38, Brian E Carpenter <[email-masked]> wrote:
> 
> Since SLAAC has always assumed that the two lengths are equal, I don’t see any discrepancy between rfc4291bis-08 and reality, which is as it should be for an Internet Standard.

I’m still further confused now. Are you now saying that LwIP is correctly interpreting RFC 4291 by assuming the two lengths must be equal and rejecting advertisements containing a different on-link prefix length than is the standard address configuration prefix length for the link type?

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 28 Jun 2017 13:02:48 +1200

On 28/06/2017 09:39, 神明達哉 wrote:
> determination are equal"?  

Yes.

> Specifically which text of RFC4862 says

It doesn't say that. But on a normal broadcast LAN nothing else
makes much sense, so I believe that users have always made this
assumption, regardless of what implementations might support.

On 28/06/2017 10:12, james woodyatt wrote:
...
> I’m still further confused now. Are you now saying that LwIP is correctly interpreting RFC 4291 by assuming the two lengths must be equal and rejecting advertisements containing a different on-link…

No, because RFC 4291 doesn't say that: it simply states the IID length.
So you're describing an implementation choice, which very possibly doesn't
conform to RFC 4862.

     Brian

---

From: David Farmer <[email-masked]>
Date: Wed, 28 Jun 2017 11:41:44 -0500

> assumption, regardless of what implementations might support.

I would agree the normal use of SLAAC is with "64 bits for both address
generation and on-link determination." For normal (common, default, etc...)
use that is fine, you will have a PIO for /64 with both A and L flags set,
and is as it probably should be most of the time. Further, for link-local
address generation and on-link determination 64 bits is always the case,
all valid link-local address are always on-link by definition.

However, the protocol itself doesn't require use of 64 bits for on-link
determination for GUA regardless of how the address is generated and I
think this is the root of the disagreement here.

In reality if it is made clear on-link determination may normally be based
on a /64, but is not required to be /64, then manual configuration of an
address with an on-link prefix of anything between 0 and 128 isn't actually
an exception, it is simply a consequence of how the protocol actually is
intended to work, and the same goes of DHCP with an on-link RA other than
/64.

Now in my option, with the exception of point-to-point links, on-link
determination based on /64 prefix is RECOMMENDED.

On 28/06/2017 10:12, james woodyatt wrote:
> ...
> > I’m still further confused now. Are you now saying that LwIP is
> correctly interpreting RFC 4291 by assuming the two lengths must be equal
> and rejecting advertisements containing a different on-link prefix length
> than is the standard address configuration prefix length for the link type?
>

And subnet prefix is tangled up in the definition of IID and it's length,
which without something saying otherwise from the definition and use of
subnet in IPv4 it is perfectly reasonable to make such an assumption.
Therefore we need to fix this misconception in RFC4291bis.

I believe the way to clear this up is to say "a 64 bit IID is REQUIRED for
address generation, and /64 prefix is RECOMMENDED for on-link
determination."

For the sake of discussion, lets say I have pair of nodes connected with an
ethernet, I manually configure one with 2001:db8::1:1/112 and the other
with 2001:db8::1:2/112.

The first node will have an interface will have a link-local address
of FE80::/64
with a random 64 bit IID, and a GUA with a subnet prefix of 2001:db8::1/112
and a 16bit IID of 1.  The second node will have an interface will have a
link-local address of FE80::/64 with a random 64 IID, and a GUA with a
subnet prefix of 2001:db8::1/112 and a 16bit IID of 2.

Now I add a router, and manually configure the address as
2001:db8::1:3/112, it will generate a link-local address of FE80::/64
probably with an EUI-64 as the IID, and a GUA with a subnet prefix of
2001:db8::1/112
and a 16bit IID of 3, the router will generate a RA with a PIO of
2001:db8::1/112
with L=1 and A=0, if A=1 this would be an invalid PIO.  Further, I could
tell the router to set M=1 in the RA, and configure a DHCPv6 server on the
router to respond with addresses  2001:db8::1:4 through  2001:db8::1:ffff.

Now, I can attach an additional node and if able it will receive and
address via DHCPv6 and for this discussion lets say it receives 2001:db8::1:4,
and from the RA it gets the on-link prefix of 2001:db8::1/112.

Lets be clear, this is not a recommended configuration, however it is
nevertheless a valid configuration, it doesn't violate protocol. And I
believe this is constant with saying "a 64 bit IID is REQUIRED for address
generation, and /64 prefix is RECOMMENDED for on-link determination."

However, if we simply say "a 64 bit IID is REQUIRED" then I believe it
implies "64 bits for both address generation and on-link determination is
required," which it is not.

Thanks.

---

From: james woodyatt <[email-masked]>
Date: Wed, 28 Jun 2017 10:52:25 -0700

On Jun 28, 2017, at 09:41, David Farmer <[email-masked]> wrote:
> 
> The first node will have an interface will have a link-local address of FE80::/64 with a random 64 bit IID, and a GUA with a subnet prefix of 2001:db8::1/112 and a 16bit IID of 1.  The second node will have an interface will have a link-local address of FE80::/64 with a random 64 IID, and a GUA with a subnet prefix of 2001:db8::1/112 and a 16bit IID of 2.
> […]

To define a /112 subnet prefix means the IID must be only 16 bits long. That’s not valid under RFC 4291.

Specifically, when the DHCPv6 server generates the IID for the addresses that it provides to hosts in IA_NA or IA_TA configuration options, those addresses do not have /112 subnet prefixes and 16 bit IIDs. They have /64 subnet prefixes and 64 bit IIDS. The first two paragraphs of RFC 4291 §2.5.1 are clear about the requirements for the uniqueness properties of IIDs, and these must be respected by SLAAC, DHCPv6 and any other address configuration mechanism.

>>    Interface identifiers in IPv6 unicast addresses are used to identify
>>    interfaces on a link.  They are required to be unique within a subnet
>>    prefix.  It is recommended that the same interface identifier not be
>>    assigned to different nodes on a link.  They may also be unique over
>>    a broader scope.  In some cases, an interface's identifier will be
>>    derived directly from that interface's link-layer address.  The same
>>    interface identifier may be used on multiple interfaces on a single
>>    node, as long as they are attached to different subnets.
>> 
>>    Note that the uniqueness of interface identifiers is independent of
>>    the uniqueness of IPv6 addresses.  For example, a Global Unicast
>>    address may be created with a local scope interface identifier and a
>>    Link-Local address may be created with a universal scope interface
>>    identifier.

To highlight the [@RFC2119] keywords in the above above….

"They are REQUIRED to be unique within a subnet prefix.”

"It is RECOMMENDED that the same interface identifier not be assigned to different nodes on a link."

"They MAY also be unique over a broader scope."

And just to drive the point home:

"Note that the uniqueness of interface identifiers is independent of the uniqueness of IPv6 addresses."
"Note that the uniqueness of interface identifiers is independent of the uniqueness of IPv6 addresses."
"Note that the uniqueness of interface identifiers is independent of the uniqueness of IPv6 addresses.”

There is no easy and straightforward way to break the /64 subnet prefix boundary declared by [@RFC4291] without making a major forklift upgrade to the language defining the uniqueness properties of interface identifiers independent of the uniqueness properties of IPv6 addresses. We should not be entertaining any discussion of doing that in the context of [@I-D.ietf-6man-rfc4291bis].

My principle criticism of [@I-D.bourbaki-6man-classless-ipv6] is that it tries to admit more variability in the length of interface identifiers without clarifying how the uniqueness properties of interface identifiers declared in [@RFC4291] are to be properly respected on links where varying interface identifier lengths are in use.

Shorter james: don’t try to do this in [@I-D.ietf-6man-rfc4291bis], and if you insist on trying to do this in another draft, then provide sufficient clarity about the uniqueness properties of interface identifiers on links where their length is variable and subject to dynamic operational configuration.

--james woodyatt <[email-masked]>

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Wed, 28 Jun 2017 19:41:15 +0000

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of james woodyatt
Sent: Wednesday, June 28, 2017 13:52

> That’s not valid under RFC 4291.

I don’t see why not. The IID has to be "unique within a subnet prefix," quoted directly from section 2.5.1. (Same as for IPv4.)

> Specifically, when the DHCPv6 server generates the IID for the
> addresses that it provides to hosts in IA_NA or IA_TA configuration
> options, those addresses do not have /112 subnet prefixes and 16 bit
> IIDs. They have /64 subnet prefixes and 64 bit IIDS. The first two
> paragraphs of RFC 4291 §2.5.1 are clear about the requirements for the
> uniqueness properties of IIDs, and these must be respected by SLAAC,
> DHCPv6 and any other address configuration mechanism.

DHCP can guarantee uniqueness with short IIDs, without any problem. I think that we're back to this problem again. Quoting from 2.5.1:

   For all unicast addresses, except those that start with the binary
   value 000, Interface IDs are required to be 64 bits long and to be
   constructed in Modified EUI-64 format.

Note that "and" clause. The assumption, in these older RFCs, is that EUI-64 format was used, and *therefore* the IID was going to be 64 bits long. Once that EUI-64 assumption becomes invalid, so does the rationale for 64-bit IIDs.

Now, for SLAAC, to minimize the chances of IID collisions, more bits is better than fewer bits. And some will argue that there are also security benefits with a sparsely populated IID field. But I do not think it is valid to quote RFCs that assumed EUI-64 as a reason why 64-bit IIDs are mandatory.

Doesn't matter. That was in a different context. If you go on the notion that EUI-64 embeds a MAC address, presumably it becomes a unique IID, and presumably, with SLAAC, you don't have to worry about collisions. There is no other rationale for global uniqueness of IIDs.

So, all of that is now out the window. SLAAC *will* require DAD, if the IID is chosen at random, even collision chances are slim. So the global uniqueness of IIDs is a moot point. They can’t be assumed to be globally unique, nor are they required to be, for SLAAC.

> My principle criticism of [@I-D.bourbaki-6man-classless-ipv6] is
> that it tries to admit more variability in the length of interface
> identifiers without clarifying how the uniqueness properties of
> interface identifiers declared in [@RFC4291] are to be properly
> respected on links where varying interface identifier lengths are in
> use.

The draft attempts to restore a sense of logic, because there's too much continued emphasis of a mandatory 64-bit IID, when the main rationale for it has been deprecated. If anything, the draft continues to be too conservative, e.g., in assuming that SLAAC can only work with 64-bit IIDs.

Bert

---

From: David Farmer <[email-masked]>
Date: Wed, 28 Jun 2017 15:41:42 -0500

On Wed, Jun 28, 2017 at 12:52 PM, james woodyatt <[email-masked]> wrote:

> > The first node will have an interface will have a link-local address of
> FE80::/64 with a random 64 bit IID, and a GUA with a subnet prefix of
> 2001:db8::1/112 and a 16bit IID of 1.  The second node will have an
> interface will have a link-local address of FE80::/64 with a random 64 IID,
> and a GUA with a subnet prefix of 2001:db8::1/112 and a 16bit IID of 2.
> > […]
>
> Specifically, when the DHCPv6 server generates the IID for the addresses
> that it provides to hosts in IA_NA or IA_TA configuration options, those
> addresses do not have /112 subnet prefixes and 16 bit IIDs. They have /64
> subnet prefixes and 64 bit IIDS.

DHCPv6 only provides a 128bit address it doesn't provide any subnet or IID
information at all. S must

> The first two paragraphs of RFC 4291 §2.5.1 are clear about the
> requirements for the uniqueness properties of IIDs, and these must be
> respected by SLAAC, DHCPv6 and any other address configuration mechanism.
>

Please explain how those uniqueness requirements are not met in this
situation I described?  And if they are not meet for DHCPv6 in the
situation I described they are not meet for manual configuration either.

> There is no easy and straightforward way to break the /64 subnet prefix
> boundary declared by [@RFC4291] without making a major forklift upgrade to
> the language defining the uniqueness properties of interface identifiers
> independent of the uniqueness properties of IPv6 addresses. We should not
> be entertaining any discussion of doing that in the context of
> [@I-D.ietf-6man-rfc4291bis].
>
> My principle criticism of [@I-D.bourbaki-6man-classless-ipv6] is that it
> tries to admit more variability in the length of interface identifiers
> without clarifying how the uniqueness properties of interface identifiers
> declared in [@RFC4291] are to be properly respected on links where varying
> interface identifier lengths are in use.
>
> Shorter james: don’t try to do this in [@I-D.ietf-6man-rfc4291bis], and if
> you insist on trying to do this in another draft, then provide sufficient
> clarity about the uniqueness properties of interface identifiers on links
> where their length is variable and subject to dynamic operational
> configuration.
>

You seem to be calming the uniqueness properties are not met, could I ask
where you see a problem, because I don't see one.

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: james woodyatt <[email-masked]>
Date: Wed, 28 Jun 2017 14:04:16 -0700

> I don’t see why not. The IID has to be "unique within a subnet prefix," quoted directly from section 2.5.1. (Same as for IPv4.)

Because [@RFC4291] clearly says that interface identifiers in the 2001:db8:/32 prefix are 64 bits long. That’s why it’s not valid under [@RFC4291]. I get that you want [@I-D.ietf-6man-rfc4291bis] to change that, but the current revision does not change that. I don’t agree that changing it is appropriate in this draft. I’m willing to consider it appropriate to change in another draft, but not in [@I-D.ietf-6man-rfc4291bis]. Is that clear?

> Doesn't matter. That was in a different context. If you go on the notion that EUI-64 embeds a MAC address, presumably it becomes a unique IID, and presumably, with SLAAC, you don't have to worry ab…

The context is NOT different. It is exactly the sane context.

We are revising [@RFC4291] to promote it to Internet Standard. Yes, we have moved the “Modified EUI-64” format for interface identifiers into the historical appendix, but changing the uniqueness properties of interface identifiers is a completely different thing, and it is neither necessary nor warranted. It would be a significant technical change to the addressing architecture, and quite a significant departure from the earlier architecture compared with the change to stop using modified EUI-64 format.

>> My principal criticism of [@I-D.bourbaki-6man-classless-ipv6] is

You are not addressing my criticism here, and the draft does not succeed in its attempt to “restore” any sense of logic. It does the opposite.

The current language in [@I-D.ietf-6man-rfc4291bis] §2.4.1, which maintains the uniqueness properties of interface identifiers from [@RFC4291] even when the Modified EUI-64 Format has been moved to the historical appendix, is currently standard in the IPv6 addressing architecture and it’s apparently non-controversial to retain it in the revision we will promote to Internet Standard.

The current draft of [@I-D.bourbaki-6man-classless-ipv6] does not explain how these properties can be respected on links where interface identifier lengths are variable and subject to dynamic operational configuration. Neither does it update [@RFC4291] to relax the uniqueness properties of interface identifiers to those that the existing draft can accommodate. You need to do one or the other of those, and I’m objecting because you haven’t done either one.

---

From: 神明達哉 <[email-masked]>
Date: Wed, 28 Jun 2017 14:19:11 -0700

At Wed, 28 Jun 2017 13:02:48 +1200,

> assumption, regardless of what implementations might support.

Ah, okay, I don't necessarily disagree on that observation, but I'm
afraid it's quite difficult to interpret your original sentence that
way: the original sentence seemed to talk about assumptions of
protocol specification in the general case, while the actual intent is
based on what users would assume for a "normal broadcast LAN".

Anyway, I'm just trying to clarify a thread comment I happened to
notice.  I have no problem with draft-ietf-6man-rfc4291bis-08.txt
moving forward.

--
JINMEI, Tatuya

---

From: David Farmer <[email-masked]>
Date: Wed, 28 Jun 2017 16:37:02 -0500

> information at all. S must

Some how the last sentence got mangled. it was suppose to read;

This information must be provided by the RA.

>> Shorter james: don’t try to do this in [@I-D.ietf-6man-rfc4291bis], and
>> if you insist on trying to do this in another draft, then provide
>> sufficient clarity about the uniqueness properties of interface identifiers
>> on links where their length is variable and subject to dynamic operational
>> configuration.
>>
>

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Wed, 28 Jun 2017 21:38:27 +0000

> We are revising [@RFC4291] to promote it to Internet Standard. Yes,
> we have moved the “Modified EUI-64” format for interface identifiers
> into the historical appendix, but changing the uniqueness properties
> of interface identifiers is a completely different thing, and it is
> neither necessary nor warranted.

David responded succinctly to this point. In short, what is neither necessary, nor warranted, nor mandatory even in RFC 4291, is to require the IID to be anything more than unique within that subnet prefix. This is what I mean by "restoring logic." There is no logical rationale for insisting that the IID be anything more than locally unique. The fact that in the past, one form of IIU (i.e. EUI-64) was *presumed* to be globally unique created this odd concept, of multiple different uniqueness requirments for the IID. It was a mere artifact of EUI-64.

> It would be a significant technical change to the addressing
> architecture, and quite a significant departure from the earlier
> architecture compared with the change to stop using modified EUI-64
> format.

I may be wrong, but we seem to have gone around and around on this. And the result always seems to be the same. Even if we continue to mandate that SLAAC must only be computed with 64-bit IIDs, we also acknowledge that manual or DHCP methods can readily accommodate any length of IID. So I have never understood why some seem to make this such a hurdle. 

> respected

And I claim that this is no difficult task. The only uniqueness property that survives and that is mandated, even in RFC 4291, is the uniqueness within the subnet prefix, as I quoted previously. Anything more is no longer defensible, as far as I can determine. We're just overemphasizing text that has been superseded by events.

Perhaps, if anything, the draft can emphasize that any other uniqueness properties are not warranted?

Bert

---

From: james woodyatt <[email-masked]>
Date: Wed, 28 Jun 2017 15:25:11 -0700

On Jun 28, 2017, at 13:41, David Farmer <[email-masked]> wrote:
> Specifically, when the DHCPv6 server generates the IID for the addresses that it provides to hosts in IA_NA or IA_TA configuration options, those addresses do not have /112 subnet prefixes and 16 bit IIDs. They have /64 subnet prefixes and 64 bit IIDS. 
> 
> DHCPv6 only provides a 128bit address it doesn't provide any subnet or IID information at all.

Of course it doesn’t. The subnet prefix of 2001:db8::1:1 is 2001:db8::/64. The length of the IID is set by [@RFC4291] and DHCPv6 is not empowered to override that. 

> Please explain how those uniqueness requirements are not met in this situation I described?  And if they are not meet for DHCPv6 in the situation I described they are not meet for manual configuration either. 

Firstly to address your second point, as I’ve written repeatedly, the uniqueness requirements are set by [@RFC4291] completely independent of the method used for address configuration. It doesn’t matter whether the address is manually or automatically configured, with SLAAC or DHCPv6 or any bespoke protocol you can dream up.

The interface identifier uniqueness properties are separate from the uniqueness properties of IPv6 addresses that include them, and there are no drafts anywhere under discussion that will change that.

Now to address your first point— with apologies up front to the rest of the list for taking up so much space with an explanation of something so basic— the problem with allowing interface identifiers to have variable length subject to dynamic operational configuration, as [@I-D.bourbaki-6man-classless-ipv6] tries to do, hinges on how to interpret the various instances of the [@RFC2119] keyword phrases in §2.5.1 [@RFC4291] (and its forthcoming successor).

In the first case, "They are REQUIRED to be unique within a subnet prefix.” Here, the problem is that variable length subnet prefixes allow for overlapping subnet prefixes. Consider the case of two overlapping variable length subnet prefixes on the same link, e.g. 2001:db8::/64 and 2001:db8::100/112. It’s only possible to assign an address that respects the standard IID uniqueness properties in the former prefix as long as it does not also have the latter prefix.

One way (not the only way) that [@I-D.bourbaki-6man-classless-ipv6] could try to deal with that problem is to forbid overlapping subnet prefixes, but it doesn’t even recognize the problem, much less present a solution. It’s far from clear how to go about forbidding overlapping subnet prefixes in practice, and a more workable solution to the problem might be even more problematic.

In the second case, "It is RECOMMENDED that the same interface identifier not be assigned to different nodes on a link." A brief digression, for which I will explain the purpose below: strictly speaking, to comply with this recommendation entails choosing between one of two alternatives: a) ensuring that the same interface identifier is not assigned to different nodes on the same link, and b) providing a reasoned explanation for why special considerations require diverging from the recommendation. What isn’t, strictly speaking, permitted: simply ignoring the recommendation without providing any explanation for it.

So, let’s consider your example above. Two hosts, Alfa and Bravo.

	Alfa:
	  Link-local 	fe80::$ALFA 			subnet=/64
	  Global	2001:db8:$SUBNET1::$IID 	subnet=/112

	Bravo:
	  Link-local 	fe80::$BRAVO 			subnet=/64
	  Global	2001:db8:$SUBNET2::$IID 	subnet=/112

In this example, if $IID = $ALFA or $BRAVO, then it matters whether $SUBNET1 or $SUBNET2 are more than 32 bits long. Here is a concrete example of that case, which I will assume you accept as a valid manual configuration under [@I-D.bourbaki-6man-classless-ipv6]:

	Alfa:
	  Link-local	fe80::1		subnet=/64
	  Global	2001:db8::1:1	subnet=/112

	Bravo:
	  Link-local	fe80::2		subnet=/64
	  Global	2001:db8::2:1	subnet=/112

Here, Alfa has two addresses with the same IID:

	IID(address=fe80::1 length=64) -> 1
	IID(address=2001:db8::1:1 length=112) -> 1

And that’s okay, because [@RFC4291] says "The same interface identifier may be used on multiple interfaces on a single node, as long as they are attached to different subnets."

However, Bravo has the same IID as Alfa on one of its addresses:

	IID(address=fe80::2 length=64) -> 2
	IID(address=2001:db8::2:1 length=112) -> 1

In the concrete case, above, both Alfa and Bravo have the same IID=1 in their global IPv6 addresses if the subnet prefix is /112 in both cases, and therefore the recommended uniqueness property in [@I-D.ietf-6man-rfc4291bis] is not respected. Whereas, if the subnet prefix is /64 as [@RFC4291] requires, then both Alfa and Bravo have different IID as shown below:

	IID(address=2001:db8::1:1 length=64) -> 0x10001
	IID(address=2001:db8::2:1 length=64) -> 0x20001

Following up on my promise to explain the digression about recommendations above, the problem is that [@I-D.bourbaki-6man-classless-ipv6] doesn’t even recognize that this issue can arise, much less provide any guidance on how to ensure that the recommended uniqueness property is respected or what considerations might lead an operator to diverge intentionally from the recommendation. Picture the above scenario except using a mixture of configuration methods, SLAAC, DHCPv6, manual configuration, etc. Respecting the REQUIRED uniqueness properties for IPv6 addresses is handled by DAD, but respecting the RECOMMENDED uniqueness properties for interface identifiers cannot be done with DAD. Something else must do it, and nothing is defined, much less RECOMMENDED by [@I-D.bourbaki-6man-classless-ipv6]. Which would be okay PROVIDED that [@I-D.bourbaki-6man-classless-ipv6] simply updated [@RFC4291] to remove the recommendation to ensure that the same IID is not assigned to more than one node on the same link. But it does not do that.

Finally in the third case, "They MAY also be unique over a broader scope.” Now, you can argue over whether “unique” and “statistically unique” is a relevant distinction here, but with /112 subnet prefixes there isn’t much of a case for statistical uniqueness. To achieve broader uniqueness than just the subnet prefix for the address entails using some kind of interface identifier registration system completely apart from the address registration system that DHCPv6 provides. Again, [@I-D.bourbaki-6man-classless-ipv6] doesn’t even consider this problem. With very short IID lengths, it’s simply not true at all to say that they MAY also be unique over a broader scope, absent some unspecified registration system.

An additional complication with allowing subnet prefix lengths to vary dynamically according to operator configuration is the practical problem of ensuring that uniqueness properties, which applied when the address was assigned and configured, still apply after subnet prefix lengths are changed. Once again, [@I-D.bourbaki-6man-classless-ipv6] implies that this is possible, yet nothing is explicitly discussed about the complications for the address architecture by introducing such a change.

---

From: DY Kim <[email-masked]>
Date: Thu, 29 Jun 2017 08:26:10 +0900

Hi James,

> On 29 Jun 2017, at 07:25, james woodyatt <[email-masked]> wrote:
> 
> In the concrete case, above, both Alfa and Bravo have the same IID=1 in their global IPv6 addresses if the subnet prefix is /112 in both cases, and therefore the recommended uniqueness property in [@I-D.ietf-6man-rfc4291bis] is not respected.

The two IDs (1) are within different /112 subnet prefixes (2001:db8::1 vs 2001:db8::2).So each is unique within each subnet prefix. I’d think this configuration is in conformance with the recommendation in rfc4291bis:

   "They are required to be unique within a subnet prefix."

---

From: james woodyatt <[email-masked]>
Date: Wed, 28 Jun 2017 16:44:32 -0700

On Jun 28, 2017, at 16:26, DY Kim <[email-masked]> wrote:
>> On 29 Jun 2017, at 07:25, james woodyatt <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>    "They are required to be unique within a subnet prefix.”

But they do not meet the recommendation that the same IID not be assigned to different nodes on the same link. With long interface identifiers generated by pseudo-random or random number generators, the recommended uniqueness property is achieved by statistical uniqueness. If short interface identifiers are admissible, then some other mechanism must be recommended for achieving uniqueness. There is neither any such recommended method nor a relaxation of the uniqueness property declared by [@RFC4291]. That’s my point.

Fix that, and you’ve addressed my concern. Not sure how you can address it though...

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Wed, 28 Jun 2017 23:53:01 +0000

-----Original Message-----

> And that’s okay, because [@RFC4291] says "The same interface
> identifier may be used on multiple interfaces on a single node,
> as long as they are attached to different subnets."

Okay. Just like IPv4.

>	IID(address=2001:db8::2:1 length=112) -> 1

But the subnet prefix is different. Alfa's IID of 1 is used in an address with a different subnet prefix than Bravo's, so the addresses don’t conflict. What matters is only that hosts in subnet prefix 2001:db8::2:0 length 112 must have unique IIDs. (Reason is obvious.)

> In the concrete case, above, both Alfa and Bravo have the same
> IID=1 in their global IPv6 addresses if the subnet prefix is /112
> in both cases, and therefore the recommended uniqueness property in
> [@I-D.ietf-6man-rfc4291bis] is not respected.

This is the quote:

   They are required to be unique within a subnet
   prefix.  It is recommended that the same interface identifier not be
   assigned to different nodes on a link.

But again, it's clear why that is not mandated. It doesn't matter. The address is unique anyway. It might have been confusing back when EUI-64 was mandatory (two hosts, same EUI-64??). Even if the draft were to bring it up, the only reason would be to mention that recommendation text from the past.

Bert

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Thu, 29 Jun 2017 00:02:58 +0000

This is the quote from RFC 4291:

Here's another consideration, with respect to whether that recommendation even makes sense anymore.

With SLAAC, the way it's implemented today, that recommendation cannot be guaranteed. There is no check for it. If there are two subnet prefixes available on a link, perhaps one meant for only statically assigned addresses and the other for SLAAC, there is nothing to check for that type of IID uniqueness.

Bert

---

From: DY Kim <[email-masked]>
Date: Thu, 29 Jun 2017 09:14:27 +0900

Hi James,

[Quote]

  o They are required to be unique within a subnet prefix.
  o It is recommended that the same interface identifier not be assigned to different nodes on a link.

[QED}

Rather than reading the two sentences ‘literally, I’d think we might better read the two in the context. To me, the two are meant to say the same thing.

For example, the 2nd sentence could be read (or rewritten to avoid confusion):

   o It is recommended that the same interface identifier not be assigned to different nodes on the same subnet (or link) prefix.

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 29 Jun 2017 08:40:20 +0200

Le 28/06/2017 à 18:41, David Farmer a écrit :
> 
> 
> On Tue, Jun 27, 2017 at 8:02 PM, Brian E Carpenter 
> <[email-masked] <mailto:[email-masked]>>
> wrote:
> 
>> At Thu, 22 Jun 2017 09:38:04 +1200, Brian E Carpenter
>> <[email-masked]
> <mailto:[email-masked]>> wrote:
>> 
>>>> implication that a subnet must be /64 or 64 bits for both
>>>> address generation and on-link determination.
>>> 
>> What do you mean by this?  Do you mean "SLAAC has always assumed
>> the prefix length for address generation and the prefix length for
> on-link
>> Specifically which text of RFC4862 says that (or are you referring
>> to other RFCs for SLAAC)?
> 
> It doesn't say that. But on a normal broadcast LAN nothing else makes
> much sense, so I believe that users have always made this assumption,
> regardless of what implementations might support.
> 
> 
> I would agree the normal use of SLAAC is with "64 bits for both
> address generation and on-link determination." For normal (common,
> default, etc...) use that is fine, you will have a PIO for /64 with
> both A and L flags set, and is as it probably should be most of the
> time. Further, for link-local address generation and on-link
> determination 64 bits is always the case, all valid link-local
> address are always on-link by definition.
> 
> However, the protocol itself doesn't require use of 64 bits for
> on-link determination for GUA regardless of how the address is
> generated and I think this is the root of the disagreement here. In
> reality if it is made clear on-link determination may normally be 
> based on a /64, but is not required to be /64, then manual
> configuration of an address with an on-link prefix of anything
> between 0 and 128 isn't actually an exception, it is simply a
> consequence of how the protocol actually is intended to work, and the
> same goes of DHCP with an on-link RA other than /64.
> 
> On 28/06/2017 10:12, james woodyatt wrote: ...
> correctly interpreting RFC 4291 by assuming the two lengths must be 
> equal and rejecting advertisements containing a different on-link 
> prefix length than is the standard address configuration prefix 
> length for the link type?
> 
> No, because RFC 4291 doesn't say that: it simply states the IID
> length. So you're describing an implementation choice, which very
> possibly doesn't conform to RFC 4862.
> 
> 
> And subnet prefix is tangled up in the definition of IID and it's 
> length, which without something saying otherwise from the definition
> and use of subnet in IPv4 it is perfectly reasonable to make such an
>  assumption.  Therefore we need to fix this misconception in
> RFC4291bis.
> 
> I believe the way to clear this up is to say "a 64 bit IID is
> REQUIRED for address generation, and /64 prefix is RECOMMENDED for
> on-link determination."
> 
> For the sake of discussion, lets say I have pair of nodes connected
> with an ethernet, I manually configure one with 2001:db8::1:1/112 and
> the other with 2001:db8::1:2/112.
> 
> of FE80::/64 with a random 64 bit IID, and a GUA with a subnet prefix
> of 2001:db8::1/112 and a 16bit IID of 1.  The second node will have
> an interface will have a link-local address of FE80::/64 with a
> random 64 IID, and a GUA with a subnet prefix of 2001:db8::1/112 and
> a 16bit IID of 2.
> 
>  probably with an EUI-64 as the IID, and a GUA with a subnet prefix
> of 2001:db8::1/112 and a 16bit IID of 3, the router will generate a
> RA with a PIO of 2001:db8::1/112 with L=1 and A=0, if A=1 this would
> be an invalid PIO.  Further, I could tell the router to set M=1 in
> the RA, and configure a DHCPv6 server on the router to respond with
> addresses 2001:db8::1:4 through 2001:db8::1:ffff.
> 
>  address via DHCPv6 and for this discussion lets say it receives 
> 2001:db8::1:4, and from the RA it gets the on-link prefix of 
> 2001:db8::1/112.
> 
>  nevertheless a valid configuration, it doesn't violate protocol. And
> I believe this is constant with saying "a 64 bit IID is REQUIRED for

... sounds as if on-link determination happens better if the prefix len
were 64.  But it happens equally well if nodes used e.g. 112, as long as
all use the same value, and as long as the forwarding is set up towards
them.

> However, if we simply say "a 64 bit IID is REQUIRED" then I believe
> it implies "64 bits for both address generation and on-link
> determination is required," which it is not.

Hmm...

Alex

> 
> Thanks.
> 
> -- =============================================== 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 <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: David Farmer <[email-masked]>
Date: Thu, 29 Jun 2017 02:02:36 -0500

On Wed, Jun 28, 2017 at 6:44 PM, james woodyatt <[email-masked]> wrote:

> In the concrete case, above, both Alfa and Bravo have the same IID=1 in
> their global IPv6 addresses if the subnet prefix is /112 in both cases, and
> therefore the recommended uniqueness property in
> The two IDs (1) are within different /112 subnet prefixes (2001:db8::1 vs 2001:db8::2).So
> each is unique within each subnet prefix. I’d think this configuration is
> in conformance with the recommendation in rfc4291bis:
>
> But they do not meet the recommendation that the same IID not be assigned
> to different nodes on the same link. With long interface identifiers
> generated by pseudo-random or random number generators, the recommended
> uniqueness property is achieved by statistical uniqueness. If short
> interface identifiers are admissible, then some other mechanism must be
> recommended for achieving uniqueness. There is neither any such recommended
> method nor a relaxation of the uniqueness property declared by [@RFC4291].
> That’s my point.
>

Yes, you can derive situations with /112 prefixes that don't meet that
recommendation, but I can derive ones that do meet the recommendation. That
simply means ones set of situation are recommended and the others are not.
This would only truly be a problem if it were impossible to meet the
recommendation with a /112 prefix.

I can also derive a situation where the recommendation isn't meet even with
a /64 prefix. Manually assign 2001:db8:0:1::1 and 2001:db8:0:2::1 to two
different nodes. Does this mean /64 prefixes are invalid? No, that is why
this is a recommendation and it is not a requirement.

---

From: Philip Homburg <[email-masked]>
Date: Thu, 29 Jun 2017 11:27:33 +0200

> > To define a /112 subnet prefix means the IID must be only 16 bits long. Tha
> ts not valid under RFC 4291.
> >
> > Specifically, when the DHCPv6 server generates the IID for the addresses th
> at it provides to hosts in IA_NA or IA_TA configuration options, those addres
> ses do not have /112 subnet prefixes and 16 bit IIDs. They have /64 subnet pr
> efixes and 64 bit IIDS.

There is nothing that operationally links IA_NA to /64. An address is just
an address. A host can not derive any meaningfull semantics from the statement
that IIDs are 64 bits when dealing with IA_NA. In theory a DHCPv6 server
could refuse to operate on prefixes that are not /64, but that's an
implementation detail.

So I'd like to propose that we kill any connection between IA_NA and /64 from
all relevant documents. Keeping this will only create confusion and lead to
implementations that mistakenly derive (or restrict) prefix lengths related
to addresses configured this way. The same applies to manually configured
addresses.

---

From: Philip Homburg <[email-masked]>
Date: Thu, 29 Jun 2017 11:35:12 +0200

In your letter dated Wed, 28 Jun 2017 21:38:27 +0000 you wrote:
> There is no
> logical rationale for insisting that the IID be anything more than
> locally unique. The fact that in the past, one form of IIU (i.e.
> EUI-64) was *presumed* to be globally unique created this odd
> concept, of multiple different uniqueness requirments for the IID.
> It was a mere artifact of EUI-64.

Historically, EUI-64 IIDs were not assumed to be globally unique.

When EUI-64 was introduced as IID, manufacturing defects in ethernet cards
were common enough that any attempt to use them as world wide unique identifiers
was assumed to fail. Note that DAD was required from early on because it was
assumed that ethernet addresses are not always unique.

Beyond that, it is possible to interprate the IEEE standard such that a
device as a whole needs a unique ethernet address but can use that address
on multiple ports.

As far as I know, Sun was one of the first companies to do this. Which caused
all kinds of interesting issues in switches that assumed ethernet address would
be unique.

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 29 Jun 2017 19:41:50 +0200

> could refuse to operate on prefixes that are not /64, but that's an

It's common that DHCPv6 Clients set 64 as prefix len without anybody 
telling them do so, except, err... RFC4291.

> all relevant documents.

I agree.

Alex

> Keeping this will only create confusion and lead to

---

From: james woodyatt <[email-masked]>
Date: Thu, 29 Jun 2017 10:45:42 -0700

On Jun 29, 2017, at 00:02, David Farmer <[email-masked]> wrote:
> 
> Yes, you can derive situations with /112 prefixes that don't meet that recommendation, but I can derive ones that do meet the recommendation. That simply means ones set of situation are recommended and the others are not. This would only truly be a problem if it were impossible to meet the recommendation with a /112 prefix.

I disagree. There is a serious problem.

All the currently standard and best current practice methods of generating IPv6 interface addresses meet the recommendation provided you accept that statistical uniqueness is a adequate for the purpose. Changing the /64 subnet prefix length from a constant to a dynamic operational configuration parameter removes that condition, and that’s what makes this change inappropriate for an update intended for simply promoting [@RFC4291] to Internet Standard. Either drop the recommendation in another draft that updates the successor to [@RFC4291], or keep the recommendation and specify a method of meeting it with short interface identifiers that doesn’t rely on statistical uniqueness.

I think I have now restated this argument in sufficiently different terms that it should be clear to anyone legitimately confused about my reasoning, and any further repetition would be combative in my view. So, I’m done.

---

From: David Farmer <[email-masked]>
Date: Thu, 29 Jun 2017 13:59:35 -0500

On Thu, Jun 29, 2017 at 12:45 PM, james woodyatt <[email-masked]> wrote:

> All the currently standard and best current practice methods of generating
> IPv6 interface addresses meet the recommendation provided you accept that
> statistical uniqueness is a adequate for the purpose. Changing the /64
> subnet prefix length from a constant to a dynamic operational configuration
> parameter removes that condition, and that’s what makes this change
> inappropriate for an update intended for simply promoting [@RFC4291] to
> Internet Standard. Either drop the recommendation in another draft that
> updates the successor to [@RFC4291], or keep the recommendation and specify
> a method of meeting it with short interface identifiers that doesn’t rely
> on statistical uniqueness.
>
> I think I have now restated this argument in sufficiently different terms
> that it should be clear to anyone legitimately confused about my reasoning,
> and any further repetition would be combative in my view. So, I’m done.
>

OK then, please explain to me how you resolve the apparent conflicts
between the following;

RFC4291 basically states subnet prefixes and IIDs MUST be 64 bit, and since
the term subnet prefix is used this seems to imply this is true both for
address generation and on-link determination.

However, RFC4861 seems quite specific that prefixes for on-link
determination can be any length 0-128, and regardless if the prefix is
invalid for SLAAC, it is still valid for on-link determination.  This is
discussed in detail in draft-jinmei-6man-prefix-clarify-00. Furthermore,
the fact that on-link determination can be any length 0-128, seems to be
reinforced by RFC7608.

In my mind I resolve this by qualifying the MUST statement of RFC4291 to be
about address generation and go to a RECOMMENDED statement for on-link
determination.  Which to me means /64 prefixes are normal for both address
generation and on-link determination, However any length prefix is valid
but NOT RECOMMENDED for on-link determination.

But if you have another resolution to this conflict, I'm happy to listen.

Thanks

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Thu, 29 Jun 2017 19:23:19 +0000

> statistical uniqueness is a adequate for the purpose.

Then my recommendation would be, at most, for the draft to mention this "recommendation" in RFC 4291, to explain why it was made (duplicate EUI-64s may create confusion), and consequently, dismiss the recommendation as no longer being a concern?

If it's truly serious, it would have been a MUST, one would have to believe.

Bert