Subject: Re: Section 2.4 of rfc4291bis

From: 神明達哉 <[email-masked]>
Date: Tue, 1 Aug 2017 10:35:06 -0700

At Tue, 1 Aug 2017 16:10:16 +1000,
Mark Smith <[email-masked]> wrote:

>> In my opinion the current text gives the false impression that there is
>> always a common prefix for address assignment and on-link determination, or
>> the subnet prefix and the on-link prefix are the same, which they
>> frequently are, but are not require to be.
>
> This is confusing. What address generation and configuration method is
> being used? DHCPv6, SLAAC or manual configuration?
>
> I don't understand how the subnet prefix and the onlink (subnet) prefix can
> be different.

For simplicity let's focus on SLAAC for address configuration and
RA-based on-link determination.  Then, do you mean you don't
understand how these two can be different?
- a prefix advertised in an RA PIO with the A flag on, for SLAAC
- a prefix advertised in an RA PIO with the L flag on, for on-link
  determination

If that's what you mean, I'd suggest you read
draft-jinmei-6man-prefix-clarify-00.  Essentially, there's nothing new
in this draft itself - one can reach the conclusion from existing
RFCs, but this draft gives a set of facts regarding this specific
question.  You may not like the conclusion or might even want to call
it "broken configuration" etc, but at least today these two can be
different.  And that's intentional for the protocol designer,
explicitly discussed while the wg worked on rfc2462bis and confirmed.

--
JINMEI, Tatuya

---

From: 神明達哉 <[email-masked]>
Date: Tue, 1 Aug 2017 11:11:40 -0700

At Mon, 31 Jul 2017 17:32:34 -0500,
David Farmer <[email-masked]> wrote:

> Recent discussion on the list have convinced me that section 2.4 really
> needs to discuss on-link prefixes in some detail.  It needs to describe
> their format similar to how the format of subnet prefixes are described,
> and describe how on-link prefixes are used by nodes. Also, a description of
> how subnet prefixes are used is needed to differentiate the two types of
> prefixes are used.  Several other changes were needed to integrate these
> major changes with the rest of the text, with other additional editorial
> changes.
[...]
> What do others think?

Personally, I can generally live with the proposed text in terms of
making progress (with one reservation, see below), but I don't see
much advantage over the way simpler proposal by Brian:

On Sat, Jul 22, 2017 at 1:47 PM, Brian E Carpenter
<[email-masked]> wrote:

>> Here's a thought. How would it be if the contentious sentence in 4291bis
>> read, in its entirety:
>>
>> "Interface Identifiers are 64 bits long when used for Stateless
>> Address Autoconfiguration (SLAAC) [RFC4862]."

to be more specific, this is the actual proposed text:

> A node may also be aware of on-link prefix(es) for the link(s) it is
> attached to. Such nodes may use the on-link prefix(es) to determine
> the unicast addresses for which packets may be locally delivered on
> the attached link(s). Where different link(s) may have different
> values for n:
>
> |           n bits              |           128-n bits            |
> +-------------------------------+---------------------------------+
> |       on-link prefix          |          interface ID           |
> +-------------------------------+---------------------------------+

I'm afraid this is not only controversial but also technically not
very accurate.  If a host receives an on-link prefix 2001:db8:1:abc0:/60
in an RA PIO, for example, this prefix might actually be an aggregated
on-link prefix for the following 16 /64 prefixes:
2001:db8:1:abc0::/64
2001:db8:1:abc1::/64
...
2001:db8:1:abcf::/64
each of which is used as the subnet prefix for SLAAC.  In this case
the intermediate 4 bits are actually used as some intra-link group
ID, and the remaining 64 bits are the "interface identifier".  We
could still call the combined 68 bits an "interface identifier" (after
all, when you introduce a new definition it can have any name as you
like), but I think it's rather confusing.

--
JINMEI, Tatuya

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Tue, 1 Aug 2017 18:58:55 +0000

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of [Tatuya Jinmei]

> For simplicity let's focus on SLAAC for address configuration
> and RA-based on-link determination.  Then, do you mean you
> don't understand how these two can be different?

To me, the simplest way to get the point across is to explicitly state that in principle, SLAAC can be used to configure interfaces that are not on-link. And then, you let the reader wonder what good such addresses would be. But the point is simple enough to make, using your example. It is conceivable that SLAAC creates an address, but too bad, so sad, it can’t be used on this link.

>> Address Autoconfiguration (SLAAC) [RFC4862]."

Yes, stating also this explicitly helps, and it eliminates the need to list exceptions. As of today, I don’t think there's any intention of creating IIDs other than 64 bits using SLAAC, *and* I don’t think there's any desire to create IIDs longer than 64 bits at all. But that last point could potentially change in the future.

> for example, this prefix might actually be an aggregated on-link prefix
> for the following 16 /64 prefixes:
> 2001:db8:1:abc0::/64
> 2001:db8:1:abc1::/64
> ...
> 2001:db8:1:abcf::/64

Agreed. I've wondered about this very example. However, if IIDs longer than 64 bits are not contemplated, then the situation is identical to what is already the case in IPv4. A prefix assigned by, say, an ISP, can be further lengthened on your premises. On the other hand, there's also no reason to dismiss the possibility of IIDs longer than 64 bits, on certain links, for whatever weird circumstances in the future.

Bert

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Tue, 1 Aug 2017 19:11:43 +0000

Just to clarify this:

"To me, the simplest way to get the point across is to explicitly state that in principle, SLAAC can be used to configure interfaces that are not on-link."

This would not be the responsibility of RFC 4291-bis, I shouldn't think. It's a quirk of SLAAC that RFC 4862-bis should elaborate.

Bert

---

From: 神明達哉 <[email-masked]>
Date: Tue, 1 Aug 2017 15:35:03 -0700

>> frequently are, but are not require to be.

Oops, I've just noticed I made a cut-and-paste error and referred to
the wrong text.  What I meant here is this one:

>> I have use Interface Identifier as the right-hand side of the
>> on-link prefix, but this could have a different name if that is the
>> consensus of the work group, but I think Interface Identifier makes
>> the most sense.

The rest of my point was about this text.  Sorry for any possible
confusion due to the error.

---

From: Mark Smith <[email-masked]>
Date: Wed, 2 Aug 2017 14:42:18 +1000

On 2 Aug. 2017 03:35, "神明達哉" <[email-masked]> wrote:

No, completely understand that e.g.

https://www.slideshare.net/mobile/MarkSmith214/ipv6-ras-mostly-necessary

I'm pretty confident of my understanding of all of these things. That's why
I don't understand the need for any new terminology or concepts. The need
is not obvious to me, which is why I need more stated and explained context
and description of the problem and confusion.

The problem may be that some of the concepts aren't as clear to others. I
think that would argue for more clarity and explanation, perhaps in another
ID. I think creating new terms and concepts may create more confusion
rather than eliminating it.

in this draft itself

Agree.

I haven't fully read it, however one thing I'd suggest adding (discovered
missing by searching for 'DHCP') is that the use of stateful DHCPv6 for
addressing is only an alternative to SLAAC addressing, and is not making
any implied statements about the prefix the DHCPV6 addresses are coming
from.

If nodes receiving addresses via DHCPV6 are to consider other addresses in
the link's prefix onlink, then there also needs to be an RA PIO with the L
bit set for the prefix.

I'd also mention that SLAAC and DHCPv6 addressing can coexist within the
same prefix (and do in deployed practice, because that is the default IPv6
configuration for OpenWRT/LEDE).

- one can reach the conclusion from existing

Regards,
Mark.

--
JINMEI, Tatuya

---

From: Simon Hobson <[email-masked]>
Date: Wed, 2 Aug 2017 14:02:33 +0100

"Manfredi, Albert E" <[email-masked]> wrote:

> To me, the simplest way to get the point across is to explicitly state that in principle, SLAAC can be used to configure interfaces that are not on-link.

Do you mean "configure interface addresses" that are no "on link" ? If so, then I agree - but it's also not confined to SLAAC.

> And then, you let the reader wonder what good such addresses would be. But the point is simple enough to make, using your example. It is conceivable that SLAAC creates an address, but too bad, so sad, it can’t be used on this link.

Not "on link" =/= "not usable on this link". AIUI, all it means is that other nodes (with addresses in the same prefix) will need to use a router to get packets to you.
AIUI some network types, either generally or as an option, restrict direct node-node communications. Either due to physical constraints, or for better control of traffic/security/privacy.

Or have I misunderstood ?

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Wed, 2 Aug 2017 19:09:41 +0000

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Simon Hobson

>> To me, the simplest way to get the point across is to explicitly state
>> that in principle, SLAAC can be used to configure interfaces that are
>> not on-link.
>
> Do you mean "configure interface addresses" that are no "on link" ?

Yes, sorry.

> Not "on link" =/= "not usable on this link". AIUI, all it means is that
> other nodes (with addresses in the same prefix) will need to use a
> router to get packets to you.

Okay. I suppose this could be true in some odd cases like IPv6 over ATM, or whatever, or it could be that the prefix is not on link at all. Don't want to speculate on all the ramifications or possible uses.

However I agree with Mark, this has no impact on address format. It's not a "different type" of IPv6 unicast address. RFC 4291 is about address architecture, so the fine nuances of SLAAC don't need to be addressed here at all?

Bert

---

From: 神明達哉 <[email-masked]>
Date: Thu, 3 Aug 2017 11:09:43 -0700

At Wed, 2 Aug 2017 14:42:18 +1000,

[...]
> rather than eliminating it.

Okay, now I see what you mean, but I'm afraid your original message
didn't read that way.  Personally, I think it makes sense to introduce
a new term, since when there's a confusion naming things appropriately
is a good first step to clarify it.  But I wouldn't be surprised if
some others don't see the need for it.  Whether a particular term
(like "on-link prefix") is good choice or whether introducing a new
term is a good way forward for rfc4291bis is a different question.

--
JINMEI, Tatuya

---

From: David Farmer <[email-masked]>
Date: Thu, 3 Aug 2017 22:39:09 -0500

On Tue, Aug 1, 2017 at 11:42 PM, Mark Smith <[email-masked]> wrote:

> I'm pretty confident of my understanding of all of these things. That's
> why I don't understand the need for any new terminology or concepts. The
> need is not obvious to me, which is why I need more stated and explained
> context and description of the problem and confusion.
>

So a question for you Mark, when RFC4291 says "subnet prefix", in your mind
what PIO flags does this translate to?

To me, since RFC 4291 also says that an IID must be 64 bits, I feel it must
only be referring to a PIOs with the A flag set, because RFC4682 is clear
that you need a PIO with a length of 64 bits and the A flag set to use
SLAAC.  However, both RFC4681 and RFC4682 are quite clear that a PIO with
the L flag set can be any length. So if a subnet is fixed at 64 bits, then
how can it be referring to PIOs with only the L flag set which can be any
length, therefore PIOs with only the L flag set must be something separate
from a subnet prefix as defined in RFC4291.

Now if a subnet prefix can be any length and then it could be referring to
a PIO with only the L flag set.  However, then something needs to constrain
IIDs to 64 bits, but only for SLAAC. In my opinion, we either need to talk
about on-link prefixes or we need to change the constraints on the
definition of a subnet in RFC4291bis so it fits PIOs with the A flag set or
PIOs with only the L flag set.

So I think something like this would work;

IPv6 unicast routing and on-link determination are based on prefixes
of any valid length up to 128 bits[BCP198]. However, 64 bit prefixes
are recommended for both subnet assignment and on-link determination.

and;

64 bit Interface Identifiers are required for Stateless Address
Autoconfiguration (SLAAC)[RFC4862], except if the first three bits of
the address are 000, otherwise 64 bit Interface Identifiers are
recommended. The rationale for using 64 bit Interface

Identifiers can be found in [RFC7421].

A definition of subnet prefix and IID something like that leaves room for
it to be referring to PIOs with the A flag set or PIOs only the L flag set,
then the gory details can be left to RFC4681 and RFC4682.  However a
definition tightly constrained to 64 bits for subnet prefixes and IIDs
means it can't be referring to PIOs with only the L flag set, and I believe
they are architectural important, therefore something needs to describe
them that is distinct from a subnet prefix, in my mind that would be an
on-link prefix.

So, if you think the details of on-link prefixes don't belong in
RFC4291bis, I'm fine with that, then just relax the definition of a subnet
prefix so that PIOs with only the L flag fit within the definition of a
subnet prefix.

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: Brian E Carpenter <[email-masked]>
Date: Fri, 4 Aug 2017 15:55:15 +1200

On 04/08/2017 15:39, David Farmer wrote:

...
> because RFC4682 is clear
> that you need a PIO with a length of 64 bits
No it isn't. Quite the opposite; it's carefully written to avoid
such a statement.

   Brian

---

From: David Farmer <[email-masked]>
Date: Thu, 3 Aug 2017 23:18:32 -0500

> No it isn't. Quite the opposite; it's carefully written to avoid

Well, yes, by itself it it was carefully worded not to say that, but
combined with RFC4291 its quite clear, and I'm not aware of any
implementations of SLAAC that will generate addresses for PIOs with the A
flag set and any-other length than 64. (If you are please tell, I'd really
like to be able to argue this differently)

So, I don't think the combination of RFC4291bis and RFC4682 could
legitimately allow any-other length than 64 for PIOs with the A flag set as
well, otherwise its more than a just a bis, it would be an actual change.

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: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Thu, 03 Aug 2017 21:59:41 -0700

At Thu, 3 Aug 2017 23:18:32 -0500,

> like to be able to argue this differently)
 
I'm afraid we're now in another distraction for 4291bis, but I'll
answer this particular question.  I'd say the SLAAC
implementation of most if not all BSD variants carefully interpret the
sense of RFC4862 in that the SLAAC spec itself doesn't specify the IID
(or subnet prefix) length.   As I'll explain below, it's true that
this implementation (happens to) only allow 64-bit IID for SLAAC, but
it has nothing to do with RFC4291.

To be more specific, see the prelist_update() function of the FreeBSD
implementation:
https://github.com/freebsd/freebsd/blob/master/sys/netinet6/nd6_rtr.c#L1469
in particular, this part:

		/*
		 * Prefix Length check:
		 * If the sum of the prefix length and interface identifier
		 * length does not equal 128 bits, the Prefix Information
		 * option MUST be ignored.  The length of the interface
		 * identifier is defined in a separate link-type specific
		 * document.
		 */
		ifidlen = in6_if2idlen(ifp);
...
		if (ifidlen + pr->ndpr_plen != 128) {
			nd6log((LOG_INFO,
			    "prelist_update: invalid prefixlen "
			    "%d for %s, ignored\n",
			    pr->ndpr_plen, if_name(ifp)));
			goto end;
		}

and, you can see the implementation of in6_if2idlen():
https://github.com/freebsd/freebsd/blob/master/sys/netinet6/in6.c#L1961
It only refers to link-type spec like RFC2464, etc, and has nothing to
do with the addressing architecture (if you read the entire function
you may find the default case interesting in this context, but this
should actually be an "impossible" case, and in any event irrelevant
to the addressing architecture).

So, yes, the current implementation only allows 64-bit IID in the end,
but that's simply because all published link-type specifications adopt
this value.  The "SLAAC implementation" (the prelist_update()
function()) itself is completely agnostic about these values, and if
and when some link type defines a non-64-bit IID, all you have to do
would be to update another 'case' to in6_if2idlen() (which is an
implementation of "link-type specification", not SLAAC itself).

> well, otherwise its more than a just a bis, it would be an actual change.

I tend to agree on the conclusion (i.e., talking about non-64 IID for
SLLAC would be a subject of bis), but to be very accurate, it's not
directly because of the combination of RFC4291 (or its bis) and
RFC4862.  It's because of the combination of RFC4862 and currently
published link-type specifications such as RFC2464 (RFC4862
assumes the latter is consistent with RFC4291, and it's the case
today, but that's an indirect cause).

--
JINMEI, Tatuya

---

From: DY Kim <[email-masked]>
Date: Fri, 4 Aug 2017 15:55:29 +0900

The only way to interpret the RFC 4291bis text

  "Interface Identifiers are 64 bit long except … when the addresses are manually
   configured”

should be that the length is 64 bits long if the addresses are auto-configured by SLAAC.

In constrast, SLAAC doesn’t for itself constrain the length of the IID.

Then, it’s RFC 4291bis which mandates the IID length of IID before anyone else does; even before any link-layer-specific documents mandate it.

I’d assume RFC 4291bis is the primary place for the idea of IID length of 64 bits. No one else to blame.

Am I correct?

Regards,
DY

> On 4 Aug 2017, at 13:59, JINMEI Tatuya / 神明達哉 <[email-masked]> wrote:
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Mark Smith <[email-masked]>
Date: Fri, 4 Aug 2017 18:06:17 +1000

Hi David,

On 4 August 2017 at 13:39, David Farmer <[email-masked]> wrote:
>> ID. I think creating new terms and concepts may create more confusion rather
>> than eliminating it.
>
>

So by itself, the term "subnet prefix" or an instance of a subnet
prefix (e.g., 2001:db8::/64) doesn't really tell me anything about the
context it is being used in, so it doesn't automatically translate in
my mind into a set of PIO flags. A "subnet prefix" could be appearing
in a route table, in an ACL, in an RA PIO, or on a training course
page. I don't know or can accurately guess anything further about the
subnet prefix without knowing the use context.

If the use context is added, e.g. "a subnet prefix within a PIO", then
the associated properties of what the L and A bit values are become
relevant because the use context of the subnet prefix was stated.

> only be referring to a PIOs with the A flag set,

So in section 2.5, "Unicast Addresses", which I think is the formal
definition of the structure of addresses, there are no statements that
the context of the "subnet prefix" and "interface ID" definitions are
only when SLAAC is used to generate and configure them.

There isn't mention of any address generation or configuration method
at all (i.e, no mention of SLAAC, DHCPv6 or manual configuration), so
that says to me that those definitions of address format and structure
apply in all cases - they're properties of an address as an entity by
itself, and are not properties that may or may not apply for different
address configuration methods.

So from

"2001:db8::1/64"

you can say that the boundary between the subnet prefix and the IID is
64 bits into the address, that the subnet prefix value is 2001:db8:0:0
and the IID value is 0:0:0:1. However you cannot accurately say
anything else about it, because there is no other information provided
including use context.

> from a subnet prefix as defined in RFC4291.

I may not be fully understanding this, however I think you might be
saying that the following could be interpreted as valid in theory in
an RA:

RA PIO 1: 2001:db8::/64 [L=0][A=1]
RA PIO 2: 2001:db8::/120 [L=1][A=0]

meaning that for SLAAC's purposes, there are 64 bits available to
generate the IID, where as the host will only consider the range of
addresses 2001:db8::0 through 2001:db8::ff to be onlink, and the other
2^64 - 256 addresses within 2001:db8::/64 are off-link (or the
opposite could be valid in theory - the onlink prefix size is larger
than the SLAAC prefix size).

It might be valid. Although RFC4861 says,

"Prefix Information options: one Prefix Information option
             for each prefix listed in AdvPrefixList with the option
             fields set from the information in the AdvPrefixList entry
             as follows ..."

the subnet prefixes are have different prefix lengths so they are
different subnet prefixes.

If it were valid, I wonder if there is a useful use case. I suppose
you could use it to do something like divide the /64 subnet prefix up
into e.g. half SLAAC, half DHCP e.g., RA PIO 1: 2001:db8::/65
[L=0][A=1], and a DHCPv6 address range of 2001:db8:0:0:8000::/65.
Although in practice we now have 2 x /65s, the IID is still 64 bits in
size. A bit of a bodge.

>
> Now if a subnet prefix can be any length and then it could be referring to a
> PIO with only the L flag set.  However, then something needs to constrain
> A definition of subnet prefix and IID something like that leaves room for it
> to be referring to PIOs with the A flag set or PIOs only the L flag set,
> definition tightly constrained to 64 bits for subnet prefixes and IIDs means
> it can't be referring to PIOs with only the L flag set, and I believe they
> are architectural important, therefore something needs to describe them that
> is distinct from a subnet prefix, in my mind that would be an on-link
> prefix.
>
> So, if you think the details of on-link prefixes don't belong in RFC4291bis,
> I'm fine with that,

Broadly do.

While the line is probably already blurred, and perhaps it may not be
realistically possible, however it would be nice to have RFC4291bis
dealing with properties of addresses, subnet prefixes and IIDs that
are common across use contexts, and then have other RFCs provide and
describe those specific use contexts, and which then add properties to
the addresses and subnet prefixes that suit the specific use context.

> then just relax the definition of a subnet prefix so
> that PIOs with only the L flag fit within the definition of a subnet prefix.
>

Regards,
Mark.

---

From: 神明達哉 <[email-masked]>
Date: Fri, 4 Aug 2017 09:38:17 -0700

At Fri, 4 Aug 2017 15:55:29 +0900,

> I’d assume RFC 4291bis is the primary place for the idea of IID length of 64 bits. No one else to blame.

It's subtle.  The facts are:

- RFC4291 specifies the length of IIDs for some set of addresses to be
  64 bits.  rfc4291bis-09 introduces some more exceptions, but
  essentially it's the same as RFC4291 in this sense.
- Some link-type specifications such as RFC2464 also specify the
  length of IIDs independently (RFC2464 only refers to the addressing
  architecture RFC for the concept IID, not for the length of it).  As
  far as I know all existing such link-type specs use 64 bits for the
  length of IIDs.
- SLAAC spec (RFC4862) doesn't specify the length of IIDs.  It simply
  uses link-type specs for the primary reference of it with the
  assumption that those link-type specs are consistent with the
  addressing architecture.

>From these I can only say for sure that RFC4862 itself is agnostic
about the length of IIDs.  At least to me, it's not so obvious
whether "RFC 4291bis is the primary place for the idea of IID length
of 64 bits".

--
JINMEI, Tatuya

---

From: DY Kim <[email-masked]>
Date: Sat, 5 Aug 2017 02:19:09 +0900

RFC2464 is ‘by exception’, according to the wording used in RFC4291bis.

For that, RFC 4291bis should be the primary (albeit not ‘the only’) place mandating the IID length of 64 bits.

This is my understanding.

--------
Regards,
DY

> On 5 Aug 2017, at 01:38, 神明達哉 <[email-masked]> wrote:
>

---

From: 神明達哉 <[email-masked]>
Date: Fri, 4 Aug 2017 10:42:15 -0700

At Sat, 5 Aug 2017 02:19:09 +0900,

> RFC2464 is ‘by exception’, according to the wording used in RFC4291bis.

If you mean "by exceptions defined in standards track documents"

   Interface Identifiers are 64 bit long except if the first three bits
   of the address are 000, or when the addresses are manually
   configured, or by exceptions defined in standards track documents.

then no, this phrase actually has RFC6164 (and future similar RFCs) in
mind.  Besides, RFC2462 can't be an "exception" in this context as it
says the IIDs are 64 bit long.  RFC2462 is actually one of the cases
where link-type specifications and the addressing architecture are
consistent.

--
JINMEI, Tatuya

---

From: DY Kim <[email-masked]>
Date: Sat, 5 Aug 2017 02:53:59 +0900

Yes, although defined separately, RFC2462 comes up with the same IID length.

Other than that, do you know any other standards of the same case wherein the IID length is defined to be 64 bits long?

If such cases are not prevalent, ‘primary’ might be in place if not ‘only’.

---
DY

> On 5 Aug 2017, at 02:42, 神明達哉 <[email-masked]> wrote:
> 
> Besides, RFC2462 can't be an "exception" in this context as it

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Fri, 4 Aug 2017 18:45:45 +0000

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of DY Kim

> mandating the IID length of 64 bits.

I don’t agree. I think that Tatuya Jinmei said it very concisely here:

"I'm afraid we're now in another distraction for 4291bis, but I'll answer this particular question.  I'd say the SLAAC implementation of most if not all BSD variants carefully interpret the sense of RFC4862 in that the SLAAC spec itself doesn't specify the IID (or subnet prefix) length.   As I'll explain below, it's true that
this implementation (happens to) only allow 64-bit IID for SLAAC, but it has nothing to do with RFC4291."

And then further down:

"It only refers to link-type spec like RFC2464, etc, and has nothing to do with the addressing architecture ..."

"So, yes, the current implementation only allows 64-bit IID in the end, but that's simply because all published link-type specifications adopt this value."

(Sorry for hacking up your fine prose, Jinmei-san.)

In my view, if there's an intention of being more insistent on 64-bit boundaries for SLAAC, which I think many people want, that belongs in an RFC 4862-bis, and not in the address architecture RFC. This makes any change in the future a lot simpler.

As of now, the only stipulation in RFC 4862 is that the IID length for SLAAC is the IID length of described in the IPv6-over-foo RFC, for that link type's LLA. (RFC 2464 sets IID length 64 bits for Ethernet. Oh by the way, it also mandates EUI-64!)

Bert

---

From: DY Kim <[email-masked]>
Date: Sat, 5 Aug 2017 05:05:52 +0900

I’m not sure whether you agree or don’t.

So, the only practical places to confine the IID length to 64 bits are the link-type specs like rfc2464.

Then, why not simply state as such in rfc4291bis like, e.g.:

  “The length of the interface identifier is defined in link-layer-specific standard track documents.” PERIOD,

which should replace the current text,

   Interface Identifiers are 64 bit long except if the first three bits
   of the address are 000, or when the 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]. An example of a standards track exception is [RFC6164]
   that standardises 127 bit prefixes on inter-router point-to-point
   links.

---
DY

> On 5 Aug 2017, at 03:45, Manfredi, Albert E <[email-masked]> wrote:
>

---

From: 神明達哉 <[email-masked]>
Date: Fri, 4 Aug 2017 13:13:45 -0700

At Sat, 5 Aug 2017 02:53:59 +0900,

> Yes, although defined separately, RFC2462 comes up with the same IID length.

(BTW, I made a confusing typo: it should have been RFC2464, not 2462).

> Other than that, do you know any other standards of the same case wherein the IID length is defined to be 64 bits long?

RFC2467, RFC2470, RFC2497, RFC2590, RFC3146, RFC5072.
Perhaps some more.

> If such cases are not prevalent, ‘primary’ might be in place if not ‘only’.

Whether something is "primary" is quite subjective in general, and
especially so in this specific case.  I respect your own opinion, but,
to me, it's not that obvious as I explained in a few messages ago.
Anyway, almost lost in context I don't what you're trying to achieve,
but at least I'm pretty sure it's even quite difficult to reach a
consensus that rfc4291bis is the primary reference about the IID
length.

--
JINMEI, Tatuya

---

From: DY Kim <[email-masked]>
Date: Sat, 5 Aug 2017 05:19:59 +0900

OK. Let’s pin down two points:

  o SLAAC is agnostic to the length of IID.
  o Explicit definition on the length of IID are with other standard track documents.

which should replace the whole of the current related text,

---
DY

> On 5 Aug 2017, at 05:13, 神明達哉 <[email-masked]> wrote:
>

---

From: David Farmer <[email-masked]>
Date: Fri, 4 Aug 2017 15:33:28 -0500

On Fri, Aug 4, 2017 at 3:13 PM, 神明達哉 <[email-masked]> wrote:

> > Other than that, do you know any other standards of the same case
> wherein the IID length is defined to be 64 bits long?
>

I think we give a non-normative statement that gives a sense of the answer
in RFC4291bis like they "are usually 64 bits" and then point to where is is
normatively defined. That seems like the what should be said in an
architectural document like RFC4291bis.

---

From: 神明達哉 <[email-masked]>
Date: Fri, 4 Aug 2017 13:34:06 -0700

At Sat, 5 Aug 2017 05:19:59 +0900,

>   o Explicit definition on the length of IID are with other standard track documents.

You can't ignore this:

   o RFC4291 and rfc4291bis also say the length of IID is 64 bits for
   some set of IPv6 addresses.

Reconciling the 2nd and 3rd points would be quite tricky, and that's
one main reason why I don't think "what's the primary definition" is
so obvious.  So...

>  “The length of the interface identifier is defined in link-layer-specific standard track documents.” PERIOD,

...it can't be that simple anyway.  In addition, (in my understanding)
because it's too substantial a change from RFC4291.  rfc4291bis is
basically an attempt of elevating the original RFC to an Internet
Standard, so, in general, we can only make clarifications or minor
changes.

>From a purely technical point of view, such a change can be a subject
of discussion.  IIRC some people have actually proposed ideas like
that.  But this won't be in the scope of rfc4291bis.

--
JINMEI, Tatuya

---

From: DY Kim <[email-masked]>
Date: Sat, 5 Aug 2017 05:48:02 +0900

Which some? Some other than ‘standard track documents'?

Could you please point me to?

---
DY

> On 5 Aug 2017, at 05:34, 神明達哉 <[email-masked]> wrote:
>

---

From: DY Kim <[email-masked]>
Date: Sat, 5 Aug 2017 06:00:12 +0900

In light of the upcoming standard track document <draft-ietf-v6ops-unique-ipv6-prefix-per-host-07> which deals with ‘host prefix’, may I suggest to change the text now in the beginning of Sec. 2.4

  |          n bits               |           128-n bits            |
  +-------------------------------+---------------------------------+
  |       subnet prefix           |           interface ID          |
  +-------------------------------+---------------------------------+

to

  |          n bits               |           128-n bits            |
  +-------------------------------+---------------------------------+
  |          prefix               |           interface ID          |
  +-------------------------------+————————————————————————---------+

for generalization and to leave room for other types of prefix could chip in?

---
DY

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Fri, 4 Aug 2017 21:00:40 +0000

-----Original Message-----
From: DY Kim [mailto:[email-masked]] 
Sent: Friday, August 04, 2017 16:06

> link-type specs like rfc2464.

Exactly.

> standard track documents.” PERIOD,

Exactly.

Yes again. That text can be greatly simplified, as Brian Carpenter and others have suggested in the course of this thread. Maybe "recommended," or "default," at 64 bits, would make sense.

I think the details of SLAAC belong in an RFC 4862-bis, but wouldn't change a lot in practice. Most LLA IIDs, as specified in whatever link-type-specific RFCs, are already 64 bits long, so that carries over to the SLAAC format. But not necessarily to other ways of formatting unicast addresses (DHCPv6, manual static assignments).

And even if the reason for LLA IIDs at 64 bits is no longer that the IID must be EUI-64, I think the general consensus is to keep those LLA IIDs at 64 bits.

Bert

---

From: DY Kim <[email-masked]>
Date: Sat, 5 Aug 2017 06:15:09 +0900

Fine with the general consensus.

But still, why not leave it open in rfc4291bis, like…:

	“The length of the interface identifier is defined in link-layer-specific
	standard track documents.” PERIOD

---
DY

> On 5 Aug 2017, at 06:00, Manfredi, Albert E <[email-masked]> wrote:
> 
> I think the general consensus is to keep those LLA IIDs at 64 bits.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 5 Aug 2017 11:34:38 +1200

> Standard, so, in general, we can only make clarifications or minor

Correct. That's why I most recently suggested:

That's a statement of fact. IMNSHO anything more than that is basically
noise, in terms of rough consensus and running code.
 
> that.  But this won't be in the scope of rfc4291bis.

Correct.

    Brian

---

From: DY Kim <[email-masked]>
Date: Sat, 05 Aug 2017 02:19:27 +0000

On Sat, 5 Aug 2017 at 08:34 Brian E Carpenter <[email-masked]>

> Address Autoconfiguration (SLAAC) [RFC4862]."
Why do you have to mention SLAAC at all here? It will by itself generate 64
bit IIDs based on other link-layer-specific standard track documents,
without necessarily resorting to 4291bis.

4291bis just can leave any more details of IID to SLAAC and other std track
docs.

-- 
DY

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 5 Aug 2017 15:04:43 +1200

On 05/08/2017 14:19, DY Kim wrote:
> Why do you have to mention SLAAC at all here? 

1) Because it is a fact that SLAAC today uses 64 bit IIDs, and the purpose of
a full Internet Standard is to define precisely the solution that has been
proved to work by widely deployed running code.

2) Because there is no need to define a globally fixed IID length for other
methods of address generation.

(Yes, there is an alternative - to say nothing about the length in 4291bis,
and define it either in a 4862bis or a completely separate document, but
that seems like more work for no gain. The result will be the same whatever
we do: SLAAC will continue to use 64 bit IIDs, and nobody will change a thing
in their software or configurations.)

    Brian

---

From: DY Kim <[email-masked]>
Date: Sat, 5 Aug 2017 13:24:56 +0900

‘Architecture’ of any kind by nature should deal with the generic part of the matter, leaving implementation specifics to companion protocol specs.

It is taken that the community consensus is to use 64 bits IID for SLAAC, no objection to that.

However, ‘architecture’ should not indulge into that implementation specifics, and, to the same effect as you note, SLAAC and other link-layer-specific standard track documents will take good care so that only prefixes of length 64 will be accepted by SLAAC and IIDs of the same length would be generated.

‘Architecture’ is a parent/reference document and should not rely on any implementation specific children specs like SLAAC.

I do think it’s enough to state in 4291bis

  “The length of the interface identifiers are defined in separate link-layer-specific standard track document.”

to the same implementation effect you’re concerned about.

---
DY

> On 5 Aug 2017, at 12:04, Brian E Carpenter <[email-masked]> wrote:
>

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 5 Aug 2017 16:38:00 +1200

> to the same implementation effect you’re concerned about.

In theory I agree with that, but we didn't reach consensus on that approach
when it was proposed some months ago. I'm hoping we can reach rough consensus
on something, sometime.

   Brian

---

From: DY Kim <[email-masked]>
Date: Sat, 5 Aug 2017 15:53:51 +0900

This is indeed very regretful. So long as the document is addressing ‘architecture’, addresses (or part thereof) (A) should best be described independently of the way (B) they are generated. B surely should be subject to A, but not the other way around. The logical relation should be unidirectional (A -> B), not looped bidirectional (A <-> B).

If the two are bidirectionally looped, the next immediate question should be 'which overrides the other?' Now that they are loop-linked, none of which, or both are equal… confusion,... logical fallacy.

This logical fallacy, I’d think, might be one of the sources of reasons for the endless debates on this list in regard to the IID length.

It’d be my last intention ever to represent any of the two camps, but before any debates I’d hope the group acknowledge that the document in this specific part is subject to logical fallacy, lacking in logical integrity. Before anything, one might clean up the text, fist of all, I’d hope.

---
DY

> On 5 Aug 2017, at 13:38, Brian E Carpenter <[email-masked]> wrote:
>

---

From: DY Kim <[email-masked]>
Date: Mon, 7 Aug 2017 08:07:30 +0900

The firm reference pole

	RFC7421

along with a number of docs prescribing 64 bits for the IID length

	RFC2464, RFC2467, RFC2470, RFC2497, RFC2590, RFC3146, RFC5072
	(thanks to Tatuya Jinmei for the list)

would be enough to ensure that

	SLAAC will accept only 64-bit long prefixes
		and produce 64-bit long IIDs.

not to disturb the wide deployment of SLAAC implementation as such.

RFC4291bis doesn’t need (or even ought not to, for it's about ‘architecture’) mention or mandate the length of IID, leaving such implementation specific details to companion docs like those listed above.

---
DY

> On 5 Aug 2017, at 15:53, DY Kim <[email-masked]> wrote:
>

---

From: Erik Kline <[email-masked]>
Date: Mon, 7 Aug 2017 20:10:18 -0700

I still don't think any of these changes are appropriate for just
moving the doc to standard.

---

From: David Farmer <[email-masked]>
Date: Tue, 8 Aug 2017 11:43:01 -0500

Erik,

I think your point is valid, but do you have any suggestions how to move
this forward, other than that ain't it?

I think some version of Brian's suggestion of scoping the requirement for
64 bit IIDs to SLAAC with a recommendation for 64 bit prefixes for subnets
and on-link determination works, what do you think of that?

Thanks.

On Mon, Aug 7, 2017 at 10:10 PM, Erik Kline <[email-masked]> wrote:

> > RFC4291bis doesn’t need (or even ought not to, for it's about
> ‘architecture’) mention or mandate the length of IID, leaving such
> implementation specific details to companion docs like those listed above.
> >
> > ---
> > DY
> >
> >> This is indeed very regretful. So long as the document is addressing
> ‘architecture’, addresses (or part thereof) (A) should best be described
> independently of the way (B) they are generated. B surely should be subject
> to A, but not the other way around. The logical relation should be
> unidirectional (A -> B), not looped bidirectional (A <-> B).
> >>
> >> If the two are bidirectionally looped, the next immediate question
> should be 'which overrides the other?' Now that they are loop-linked, none
> of which, or both are equal… confusion,... logical fallacy.
> >>
> >> This logical fallacy, I’d think, might be one of the sources of reasons
> for the endless debates on this list in regard to the IID length.
> >>
> >> It’d be my last intention ever to represent any of the two camps, but
> before any debates I’d hope the group acknowledge that the document in this
> specific part is subject to logical fallacy, lacking in logical integrity.
> Before anything, one might clean up the text, fist of all, I’d hope.
> >>
> >> ---
> >> DY
> >>
> >>
> >>>> ‘Architecture’ of any kind by nature should deal with the generic
> part of the matter, leaving implementation specifics to companion protocol
> specs.
> >>>>
> >>>> However, ‘architecture’ should not indulge into that implementation
> specifics, and, to the same effect as you note, SLAAC and other
> link-layer-specific standard track documents will take good care so that
> only prefixes of length 64 will be accepted by SLAAC and IIDs of the same
> length would be generated.
> >>>>
> >>>> ‘Architecture’ is a parent/reference document and should not rely on
> any implementation specific children specs like SLAAC.
> >>>>
> >>>> “The length of the interface identifiers are defined in separate
> link-layer-specific standard track document.”
> >>>>

---

From: james woodyatt <[email-masked]>
Date: Tue, 8 Aug 2017 11:40:54 -0700

On Aug 8, 2017, at 09:43, David Farmer <[email-masked]> wrote:
> 
> I think your point is valid, but do you have any suggestions how to move this forward, other than that ain't it?
> 
> I think some version of Brian's suggestion of scoping the requirement for 64 bit IIDs to SLAAC with a recommendation for 64 bit prefixes for subnets and on-link determination works, what do you think of that? 

I completely share Erik’s view, but I’m not speaking for him here, and I would invite him to answer for himself.

My answer to your question is that if I-D.ietf-6man-rfc4291bis-09 cannot achieve sufficient consensus to publish, then I’d prefer to see the effort to promote RFC 4291 into the STD series abandoned. I’ve come to believe that the IPv6 world can thrive without a STD number for the IPv6 Addressing Architecture. Any further revisions to other IPv6 documents that we want to promote to Standard can be revised so they don’t make normative references to RFC 4291. In fact, that’s probably a good idea on general principle given this seemingly interminable debate.

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

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 9 Aug 2017 16:51:29 +0200

> Could you please point me to?

There are some I-Ds published on other purpose than this 64 dicussion,
and that could hint at IIDs for SLAAC.

The implementation of a Client forming an address out of a /56 or of /65
could be something like
'tcpdump|grep RA|grep prefix|grep plen
  && ifconfig add prefix::$RANDOM/plen eth0'.

Such mechanism and draft would not break anything.

Alex

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