Subject: Fwd: New Version Notification for draft-farmer-6man-exceptions-64-05.txt

From: David Farmer <[email-masked]>
Date: Mon, 6 Aug 2018 16:04:42 -0500

Made some more updates;

      *  Fixed typo in organization tag from version 4

Changes made in version 4

      *  Changed references for RFC4291bis to RFC4291 except in
Acknowledgments
      *  Missed a 64-bit boundary, changing it to standard subnet boundary,
in the note in Section 2.1.
      *  Added that only 2000::/3 has bee release for allocations, in the
note in Section 2.1.
      *  Other miscellaneous editorial changes and typos fixed.
      *  Changes to Author's address

---------- Forwarded message ----------
From: <[email-masked]>
Date: Mon, Aug 6, 2018 at 10:46 AM
Subject: New Version Notification for draft-farmer-6man-exceptions-64-05.txt
To: David Farmer <[email-masked]>

A new version of I-D, draft-farmer-6man-exceptions-64-05.txt
has been successfully submitted by David Farmer and posted to the
IETF repository.

Name:           draft-farmer-6man-exceptions-64
Revision:       05
Title:          Exceptions to the Standard Subnet Boundary in IPv6
Addressing
Document date:  2018-08-06
Group:          Individual Submission
Pages:          15
URL:            https://www.ietf.org/internet-drafts/draft-farmer-6man-excep
tions-64-05.txt
Status:         https://datatracker.ietf.org/doc/draft-farmer-6man-exceptio
ns-64/
Htmlized:       https://tools.ietf.org/html/draft-farmer-6man-exceptions-64
-05
Htmlized:       https://datatracker.ietf.org/doc/html/draft-farmer-6man-exc
eptions-64
Diff:           https://www.ietf.org/rfcdiff?url2=draft-farmer-6man-excepti
ons-64-05

Abstract:
   This document clarifies exceptions to the standard subnet boundary in
   IPv6 addressing.  The exceptions include unicast IPv6 addresses with
   the first three bits 000, manually configured addresses, DHCPv6
   assigned addresses, IPv6 on-link determination, and the possibility
   of an exception specified in separate IPv6 link-type specific
   documents.  Further, operational guidance is provided, and Appendix A
   discusses the valid options for configuring the parameters of an IPv6
   subnet.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

-- 
===============================================
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: Brian E Carpenter <[email-masked]>
Date: Tue, 7 Aug 2018 14:55:03 +1200

>       *  Changed references for RFC4291bis to RFC4291 except in

Understandable, but a stretch goal for this effort is to find
a formulation for 4291bis that we can agree on, so that you could
cite the future Internet Standard.

>       *  Added that only 2000::/3 has bee release for allocations, in the

Good. But it's still not a formal statement that IANA should reserve
the other /3s. Is there are reason we can't just say that?

Thanks
    Brian

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

---

From: 神明達哉 <[email-masked]>
Date: Tue, 7 Aug 2018 15:30:20 -0700

>> has been successfully submitted by David Farmer and posted to the

I'd like to be sure about the high level intent of this document
before discussing specific details.  Am I correct that the plan is
to substitute this doc for the following paragraph of Section 2.4.1 of
draft-ietf-6man-rfc4291bis-09...

   Interface Identifiers are 64 bit long except [...]

... so that rfc4291bis can move forward to IS without controversy?

If this is correct, then does Section 2.5 of
draft-farmer-6man-exceptions-64-05 now mean that a new IPv6 link-type
specific document can define a non-64-bit IID length just "when
justified"?  Or, should farmer-6man-exceptions-64 be still interpreted
as a new link-type document cannot define a non-64-bit IID length
without being inconsistent with farmer-6man-exceptions-64 itself and
therefore should require an update to it (just like a new link-type
doc would have to update RFC4291 to define a non-64-bit IID today)?

--
JINMEI, Tatuya

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 8 Aug 2018 11:32:00 +1200

On 08/08/2018 10:30, 神明達哉 wrote:
> draft-ietf-6man-rfc4291bis-09...> 
> .... so that rfc4291bis can move forward to IS without controversy?

I don't know David's intention, but I have been thinking about
this. I think we should *modify* that paragraph of rfc4291bis,
rather than delete it.

The reason is that, judging by earlier discussions, we will
have great difficulty getting consensus to delete it.

In a separate message, I will propose a specific modification.
Note that we are aiming for Internet Standard for rfc4291bis,
but only for Proposed Standard or BCP for draft-farmer.

> justified"?

The actual phrase in rfc4291bis-09 is "or by exceptions defined in
standards track documents." That seems to me to be correct; whether
it is stated in rfc4291bis or in draft-farmer is a detail.
(It is true in any case: a new standards track document can always
update an old one.)

> Or, should farmer-6man-exceptions-64 be still interpreted

I think the answer depends on the final text of rfc4291bis. If the
"or by exceptions..." text is retained there, that will be
the governing document.

All IMHO, of course

    Brian

---

From: 神明達哉 <[email-masked]>
Date: Tue, 7 Aug 2018 16:58:42 -0700

At Wed, 8 Aug 2018 11:32:00 +1200,

> "or by exceptions..." text is retained there, that will be

I have a feeling that we're talking about slightly different
points...to be more specific, let's assume I'm writing a new
IPv6-over-link-type specification, where the IID length is 48 bits.
Also assume for simplicity that we retain the "or by exceptions..."
text in rfc4291bis.  In this case, are you saying that this new
IPv6-over-link-type must be a standard track document that updates
rfc4291bis so that it will be a document that meets the exception
requirement of "by exceptions defined in standards track documents"?
If yes, this essentially means the second interpretation of my
original message.

--
JINMEI, Tatuya

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 8 Aug 2018 13:25:43 +1200

On 08/08/2018 11:58, 神明達哉 wrote:
> Brian E Carpenter <[email-masked] <mailto:[email-masked]>> wrote:
> 

Yes. But I don't think it matters too much. If we revised
the text in rfc4291bis in some other way, the new IPv6-over-*
document would formally update draft-farmer instead. The result
would be the same.

I do agree that this needs to be clarified one way or the other.

    Brian

---

From: David Farmer <[email-masked]>
Date: Tue, 7 Aug 2018 21:49:54 -0500

Personally, I believe that an IPv6-over-FOO document needs provide
sufficient justification for an IID length other than 64 bits. Further, it
needs to explain how it won't create confusion with other the link-types
that it can be bridged with. In my mind this is possible only in two ways,
the link-type can't be bridged with 802.1 type technologies, or the like
type defines a new Ether-type.

With that, it should stand on its own as a Standards Track document.

But, that's my opinion, I really just want to do two things, move
RFC4291bis to Internet Standard and explain how subnets work so there is
much less confusion by people.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 08 Aug 2018 10:53:33 -0400

David Farmer <[email-masked]> wrote:
    > sufficient justification for an IID length other than 64 bits..
    > Further, it needs to explain how it won't create confusion with other
    > the link-types that it can be bridged with. In my mind this is
    > possible only in two ways, the link-type can't be bridged with 802.1
    > type technologies, or the like type defines a new Ether-type.

Present IPv6-over-DECT, BTLE, 802.15.4 and even RFC8163 (IPv6 over RS-485)
generate 64-bit IIDs, despite having in some cases 1-byte L2-addresses.
Each hopes for many many zeroes that can be compressed out, and/or compressed
using the L2 header values.

None can be bridged to ethernet.
Each would probably have done things slightly differently had a non-64-bit
IID been permissible.

    > RFC4291bis to Internet Standard and explain how subnets work so there
    > is much less confusion by people.

:-)
Thank you for the work, I think that we are making progress.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: 神明達哉 <[email-masked]>
Date: Wed, 8 Aug 2018 10:38:02 -0700

At Wed, 8 Aug 2018 13:25:43 +1200,

> document would formally update draft-farmer instead. The result

I'm afraid I still failed to make my point clear.  It's not about
*which* of rfc4291bis and draft-farmer the new IPv6-over-* should
formally update.  It's about *whether* a new IPv6-over-* should
formally update these as part of "justification".

And I thought this was very critical in terms of whether we can reach
some consensus this time.  See this feedback for
draft-ietf-6man-rfc4291bis-09:
https://www.ietf.org/mail-archive/web/ipv6/current/msg27937.html

That is, if this attempt means a new IPv6-over-* document can
introduce a non-64 IID just by being published as a standards track
document without formally updating rfc4291bis (or draft-farmer), then
the discussion will simply become another round of the same endless
debate as before.  I don't think draft-farmer now magically solves
this gridlock.

--
JINMEI, Tatuya

---

From: 神明達哉 <[email-masked]>
Date: Wed, 8 Aug 2018 10:47:54 -0700

At Tue, 7 Aug 2018 21:49:54 -0500,
David Farmer <[email-masked]> wrote:

> sufficient justification for an IID length other than 64 bits. [...]

> With that, it should stand on its own as a Standards Track document.

I suspect that the vague term of "sufficient justification" isn't
enough.  Unless it at least includes the condition that IPv6-over-FOO
formally updates rfc4291bis (or 6man-exceptions if it takes over the
normative part of rfc4291bis), I don't see any possibility that we
succeed this time.  See my response to Brian I just sent out.

> much less confusion by people.

I very much support the first goal.  And, in that sens, I'm afraid
there's no room for introducing one's "opinion".  Unless we preserve
the controversial part of the original RFC4291 (while not giving it an
"Internet Standard" stamp by moving it from rfc4291bis) as much as
possible, I see no possibility of making the discussion different this
time.

--
JINMEI, Tatuya

---

From: Ole Troan <[email-masked]>
Date: Wed, 8 Aug 2018 19:49:08 +0200

Jinmei,

> debate as before.  I don't think draft-farmer now magically solves

Do we any longer have justification for the IID length to be specific to the particular data-link layer type?

Best regards,
Ole

---

From: 神明達哉 <[email-masked]>
Date: Wed, 8 Aug 2018 11:10:40 -0700

At Wed, 8 Aug 2018 19:49:08 +0200,

> Do we any longer have justification for the IID length to be specific to
the particular data-link layer type?

Do you mean, now that we have non-link specific IIDs like RFC7217?  If
so, I tend to agree that it may make more sense to make specific data
link layers agnostic about the concept of IIDs, let alone their
length.  It would also mean updating RFC4862.  I don't oppose to
planning those ideas - in fact, I've always thought it's unfortunate
we have multiple, mostly independent documents that define some
parameters of IIDs.  But in the context of moving 4291bis forward, I
suspect these "cleanup" will just introduce further chaos.  I made my
above comment in that context.

--
JINMEI, Tatuya

---

From: David Farmer <[email-masked]>
Date: Wed, 8 Aug 2018 13:49:45 -0500

> above comment in that context.

I don't have a strong opinion that we need to allow for different IID
lengths by link-type the only reason I included it in my document is that
is how SLAAC is currently designed, it is part of the status quo as I see
it. My goal has been clear documentation of how all this works, there is
too much confusion.

However, I'm not sure opening up SLAAC to changes is going to lead to
consensus. Personally, I'm afraid that will lead straight to the question
why SLAAC needs to have a single IID length at all. We already have one
implementation that allows any IID length. I just don't think it is a good
idea to go there.

That's my $.02

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Wed, 8 Aug 2018 19:01:16 +0000

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Ole Troan

> Do we any longer have justification for the IID length to
> be specific to the particular data-link layer type?

That is the key question, and my answer is no. I think too much is being made of IPv6-over-foo. The rationale for "over foo" comes from an era in which hardware addresses were embedded in the IPv6 address. No more.

IID lengths are artificially constrained in SLAAC, meaning that SLAAC could easily work with other lengths of IID, and they are also constrained in other examples where it doesn't much matter (e.g. ULA and link local).

So for example, is there a theoretical problem bridging disparate networks at layer 2, with IPv6? Same IPv6 subnet, but packets framed differently across the bridge? Should be feasible, no? We played those games with ATM LANE, back when.

Bert

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 9 Aug 2018 11:02:25 +1200

> Do we any longer have justification for the IID length to be specific to the particular data-link layer type?

For the long term, I have no idea. That's why I think SLAAC is
correct to make it a parameter.

For the short term (let's say ten years, which seems like a typical
RFC lifetime in this area) I think the arguments for a single
standard length are solid.

    Brian

---

From: 神明達哉 <[email-masked]>
Date: Wed, 8 Aug 2018 16:38:12 -0700

Addressing

Now, this is my comments on the draft content:

General matters:

- I generally support the document as an attempt of helping rfc4291bis
  move to IS.  In that context, however, I'm afraid this draft talks
  about too  many things that are not directly related to this
  purpose.  The more topics we try to discuss, the more likely that
  it leads to another round of the same endless discussion.  In that
  sense, for example, I'd personally separate most of the
  "operational" discussions such as those in Section 3 and Appendix A
  and rather focus on the actual "exceptions" and relevant
  explanations.

- As a related point to the first bullet, it's a bit awkward that this
  draft keeps talking about "subnet (length)" while the most
  controversial part of rfc4291bis is "interface identifier (IID) and
  its length".  Although it's true that the length of the subnet
  prefix unilaterally determines the length of the IID, it's more
  direct and intuitive if it primarily discusses the IID length and
  its exceptions.  Then this document will be a more straightforward
  replacement of the "Interface Identifiers are 64 bit long except..."
  text of rfc4291bis.  If there's a strong reason for making subnets
  the main topic, I'd at least like to have a separate section to
  discuss the length of interface identifier and how it's related to
  Section 2.4.1 of rfc4291bis.

- I believe this document should have "Update" or "Obsolete" tag for
  RFC4291.  Also, if it wants to invalidate on-link prefixes longer
  than the length of "subnet assignment prefix", it should also have
  an "Update" tag for RFC4861 (since RFC4861 allows this combination).

Comments on draft text:

- Introduction: I found this section too long with discussing too many
  substantial topics rather than just provide an introductory
  context.  While I largely support what's written in this section, I
  personally think this should rather belong to a separate section.

- Introduction: probably partly because of the verbosity noted in the
  previous bullet, it's not super clear to me what's the "standard
  subnet boundary":

   By clarifying the following exceptions to the standard subnet
   boundary [...]

  On the other hand, if this were "the (standard) IID length (as
  currently defined in RFC4291)", that would be much clearer.  This is
  another reason why I'd prefer primarily talking about IIDs.

- Introduction: it introduces the term "subnet assignment prefix".  As
  far as I know this term is not defined in any other RFCs and is
  therefore newly introduced in this document.  I'd like the term to
  be defined as such.  (Perhaps same for "on-link prefix").

- Section 2.2

   Manually configured addresses MAY also include an associated on-link
   prefix length.

  What does this "include" mean?  I see that a manual address
  configuration is often accompanied with a manual on-link prefix
  configuration: if you do
  ifconfig en0 2001:db8:1:2::bad prefixlen 80
  it actually configures both
  - a 128-bit IPv6 address 2001:db8:1:2::bad
  - a 80-bit IPv6 on-link prefix 2001:db8:1:2::/80
  at the same time.  If you mean operations like this, I'd suggest
  rephrasing the text as, e.g.

   Manually configured addresses are often associated with an on-link
   prefix that covers the configured addresses.
 (no RFC2119 keyword)

- Section 2.2: related to the previous point, if we manually configure
  an address as above, what's the IID of this address?  Is it the
  lower 48 bits (0:0:bad)?  Or should the IID be considered empty as
  the address in this case is to be considered an "opaque 128-bit
  quantity"?

- Section 2.4:

   IPv6 on-link determination is an exception to the standard subnet
   boundary, in that IPv6 ND [RFC4861] does not require on-link prefixes
   to be 64 bits in length.

  I don't understand why this is an "exception" (to the standard).  In
  fact, this text itself says it's allowed by RFC4861.  I guess this
  questions is also related to subnet vs IID, and also about the
  meaning of "standard subnet boundary" (see above).

- Section 2.5: as I discussed in a separate message, I don't think we
  can succeed in the goal of helping rfc4291bis if we loosen the
  condition for such a link-type specific document to define a
  non-64-bit IID.  Today, RFC4862 allows link-type specific documents
  to define the IID length for the link but with an assumption that
  it's consistent with the "addressing architecture" (as defined in
  RFC4291).  Since the latter says it's 64-bit except for addresses
  starting with 000, such documents will also have to update RFC4291
  to introduce a new exception.  To preserve this sense, this section
  will need additional text like this:

   However, these documents may create an exception to the standard
   64-bit IID length scoped to a specific link-type technology when
   justified.  This justification requires consensus on formally
   updating this document as a new standards track document.

- Section 3

   [...] but on-link prefixes are required to be 64 bits or
   shorter.

  I don't see why this is "required" (disallowing longer than 64
  bits).  I'll discuss this in more detail later.

- Section 3

      A flag set).  If a subnet assignment prefix is advertised, it MUST
      be (128 - N) bits in length and an identical on-link prefix (a PIO
[...]
      Where N = 64, unless the link-type specific document for the link

  This text was quite unreadable to me because "where N=..." is far
  from the point where 'N' first appears.

- Section 3

      the on-link prefix MUST NOT be longer than (128 - N) bits in
      length.

  I don't see why MUST NOT (see above and below).

- Appendix A

   1.  Subnet assignment prefixes with identical on-link prefixes
   2.  Subnet assignment prefixes with shorter covering on-link prefixes
   3.  Only subnet assignment prefixes with no on-link prefixes
   4.  Only on-link prefixes with no subnet assignment prefixes
[...]
   Logically there is another option that could define a subnet, "Subnet
   assignment prefixes with longer covered on-link prefixes," but it
   does not result in an operationally valid subnet.

  I'd first note that option 3 is actually one variant of "Subnet
  assignment prefixes with longer covered on-link prefixes" (prefix
  length is 128).  Also, I don't see why a longer on-link prefix is
  "invalid".  I agree that such a configuration is awkward, but I
  don't necessarily see it result in interoperability problems.  If we
  want to "discourage" such a configuration, that may make sense, but
  declaring it "invalid" and prohibit it with a MUST NOT seem to be an
  overkill.  If we really want to do that, at least this document
  should formally update RFC4861.

- Appendix A

   [...]  Further, the managed address
   configuration (M) flag in IPv6 ND RA messages signals to hosts that
   DHCPv6 should be used for IPv6 address assignment [...]

  A minor point in the context of this document, but this is not
  correct per RFC4861.  The M flag simply means address assignment by
  DHCPv6 "is available"; it doesn't mean DHCPv6 "should be used".

Editorial nits:

- Section 1: this sentence doesn't parse well for me gramatically.
  Perhaps remove "while"?

   Further, unlike IPv4 where there is a single subnet mask parameter
   with the two aspects of a subnet, address assignment and on-link
   determination, tightly coupled together, while in IPv6 they are split
   into two logically separate parameters serving the two aspects
   independently.

- Section 1: this seems to be incomplete as a sentence.

   Reinforcing the ideas that on-link prefixes are logically separate
   and may have any length.

--
JINMEI, Tatuya

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 9 Aug 2018 14:51:18 +1200

Jinmei-san,

These are good comments. I just want to responf briefly on
two points:

>   RFC4291.  

It could only be "Updates", but I think a much better result
would be to agree on a version of RFC4291bis at the same time.

>   Also, if it wants to invalidate on-link prefixes longer

I don't think we need to do that. What is the advantage?

Regards
   Brian

---

From: Ole Troan <[email-masked]>
Date: Thu, 9 Aug 2018 09:42:46 +0200

> standard length are solid.

A single standard length is what we have now.
I am confused. What change do people think is needed?

Ole

---

From: David Farmer <[email-masked]>
Date: Thu, 9 Aug 2018 06:46:04 -0500

> I am confused. What change do people think is needed?

There are two lines of thought that resonate with me. There seems to be a
lot of interest in different options for constrained devices, IoT with
low-power, low-bandwidth, etc...  The other one for me is security and
privacy. Security, especially in public access networks, is driving us
toward prefix per device. However, combine that with a fixed subnet
boundary and the privacy advantages of random IIDs are virtually
eliminated. A variable subnet boundary combined with long random IIDs might
restore some of the privacy advantages of random IIDs with the security
advantages of prefix per device.

Thanks

---

From: 神明達哉 <[email-masked]>
Date: Thu, 9 Aug 2018 08:48:37 -0700

At Thu, 9 Aug 2018 09:42:46 +0200,

> I am confused. What change do people think is needed?

I don't know, but one thing I'm pretty sure is that if we try to
introduce a change from "what we have now" in the context of
draft-farmer-6man-exceptions-64 and moving rfc4291bis forward with it,
then we'll fail.  Not because I believe the change is necessarily a
bad idea for either short or long term, but because that will just
result in a revision of the familiar endless debate.  Hence this

> >>> debate as before.  I don't think draft-farmer now magically solves

So, if making such a change is part of the goal of
draft-farmer-6man-exceptions-64, I oppose to spending WG's time on it
at this point.

--
JINMEI, Tatuya

---

From: David Farmer <[email-masked]>
Date: Thu, 9 Aug 2018 12:45:03 -0500

> draft-farmer-6man-exceptions-64, I oppose to spending WG's time on it

While I probably support both short and long-term changes. That is not my
goal for draft-farmer-6man-exceptions-64. I'm trying to rationalize the
IPv6 Addressing Architecture with how SLAAC and ND are implemented. 64 is
clearly the number, but as the protocols are defined and implemented, it is
required in many circumstances, if not most by quantity of use, but it is
not actually required in all circumstances.

---

From: 神明達哉 <[email-masked]>
Date: Thu, 9 Aug 2018 11:11:26 -0700

At Thu, 9 Aug 2018 14:51:18 +1200,

> would be to agree on a version of RFC4291bis at the same time.

Yeah, after sending the message I also realized "obsolete" wouldn't
apply in this case.

> I don't think we need to do that. What is the advantage?

The advantage of invalidating longer on-link prefix?  Or the advantage
of adding an "update RFC4861" tag?

If the former, I actually don't know, and in fact that is why I made
the comment - I see the advantage of pointing out that that's an
awkward configuration, but I don't see an absolute need for
invalidating it.  (To be clear I have no intent of defending such a
configuration).

If the latter, it's not about "advantage" in the first place to me -
if we want to invalidate something with a MUST NOT that is allowed in
RFC4861, shouldn't we obviously need to add the "update RFC4861" tag?

--
JINMEI, Tatuya

---

From: David Farmer <[email-masked]>
Date: Thu, 9 Aug 2018 14:08:55 -0500

Thank you for the very useful feedback, see inline.

>   and rather focus on the actual "exceptions" and relevant

I'm trying to rationalize the IPv6 Addressing Architecture with how SLAAC
and ND are implemented. 64 is clearly the number, but as the protocols are
defined and implemented, it is required in many circumstances, if not most
by the quantity of use, but it is not actually required in all
circumstances.

So I've come to the conclusion, when an autonomous address-configuration
prefix is configured, an IID length of 64 bits is required and when only an
on-link prefix is configured the IID length is only recommended to be 64
bits in length. You seem to support this idea.

However, it makes more sense to me if there is a coherent operational
recommendation to use SLAAC, and when SLAAC is used 64-bit IIDs are
required. Or, if only an on-link prefix is configured 64-bit IIDs are
recommended, etc... The problem is I don't see where such a recommendation
is made.  So, I have included the operational bits, but I think I will
split them into a separate document.

>   Section 2.4.1 of rfc4291bis.

As you talk about, the only reason IID length is controversial at all is
that also defines the subnet length, they are two sides of the same coin.

Most people I know, find the fact that IPv6 Addressing Architecture focuses
on IID length and not subnet length difficult and confusing, we configure
subnet prefixes, not IIDs at least when you use SLAAC.

But, it is a good suggestion to focus this documnet on IID length, and I'll
focus the split off operational documnet on subnet length.

>   an "Update" tag for RFC4861 (since RFC4861 allows this combination).

I agree with an update to  RFC4291, I also agree with Brian though, but at
least for now I will add that it updates RFC4291. I'll talk about the
RFC4861 issue a bit further down in my response.

>   personally think this should rather belong to a separate section.

Yes, I've been struggling with that myself.  I'll work toward your
suggestion, maybe not the next rev though.

>   another reason why I'd prefer primarily talking about IIDs.

For this document, I'm going to change it to standard IID length and focus
on IID length as you say above and using and focusing on the subnet length
in the split-out operational document.

>   be defined as such.  (Perhaps same for "on-link prefix").

Yes, if it remains it needs to be defined more clearly.  However, is
"autonomous address-configuration prefix" better or worse?  Any other ideas?

- Section 2.2
>    prefix that covers the configured addresses.

That is much better wording, thanks. Do you think examples like you
provided would help too?

>   the address in this case is to be considered an "opaque 128-bit

I add something, and too 2.3 DHVPv6 too.

>   meaning of "standard subnet boundary" (see above).

I've heard some people say that rfc4291 mean that on-link prefixes MUST be
64-bits. Let me think on this.

>    updating this document as a new standards track document.

I get your point, I'll go with this for now.

>   from the point where 'N' first appears
>

I already worked on the "Where N = 64,..." see email thread with Brian.

Help me understand this issue with the first part?

- Section 3
>   I don't see why MUST NOT (see above and below).

I went back and forth a couple times myself, this was to head off what I
thought would be an objection to the whole premise that on-link prefixes
are not required to be 64 bits.  Personally, I would just recommend against
their use.

>   should formally update RFC4861.

Ok, I'll work on this and change to not recommended and problematic.  Do
you have any issue with discouraging the use of this option?  If you don't
think it should be discouraged, help understand a practical use case.

>   DHCPv6 "is available"; it doesn't mean DHCPv6 "should be used".

Ok, thanks

>    into two logically separate parameters serving the two aspects

I'll that a try. But, if anyone has ideas for this I'd be interested.

>    Reinforcing the ideas that on-link prefixes are logically separate

I'll work on it too.

Thank you, thank you, thank you!

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 10 Aug 2018 08:53:09 +1200

> I am confused. What change do people think is needed?

I think we need to leave behind us a clean set of documents,
so that when people come back to this question in 10 or 20
years it is clear what we intended to say. That's all.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 10 Aug 2018 08:56:11 +1200

> invalidating it.  (To be clear I have no intent of defending such a

That's what I mean, and I think we agree about this.

> RFC4861, shouldn't we obviously need to add the "update RFC4861" tag?

Yes, but fortunately that is not what I mean.

    Brian

---

From: Ole Troan <[email-masked]>
Date: Fri, 10 Aug 2018 14:54:09 +0200

> years it is clear what we intended to say. That's all.

And the fact that you are proposing changes to the current architecture I think it is a pretty clear indication that we will struggle to reach consensus on what “clean” entails.

Cheers,
Ole

---

From: 神明達哉 <[email-masked]>
Date: Fri, 10 Aug 2018 11:20:58 -0700

At Thu, 9 Aug 2018 14:08:55 -0500,

> bits in length. You seem to support this idea.

Yes.  It matches the reality of existing implementations (widely
available utilities allow you to manually configure an IPv6 address
with a "prefix length" other than 64) and reconciles this fact and
what's written in RFC4291 pretty well, just if we (WG) can agree that
the case of manually configured addresses can be an exception.  And,
in my understanding this point is one of the few things we (WG) seem
to be able to agree on.

> >   its length". [...]

Or, we might add some small section explaining how the main
description of IID length relates to subnet sizes.  As the draft
currently says it's "subtle but complex", so clarification on this
point would be very useful.

> "autonomous address-configuration prefix" better or worse?  Any other
ideas?

The bottom line is to make it clear that this is a new term and define
it with the meaning.  If the naming can be better, that's a bonus, but
I don't have a specific suggestion that is clearly better.  In my own
expired draft (draft-jinmei-6man-prefix-clarify-00) I used term "SLAAC
subnet prefix", but I don't insist that's clearly better.

> That is much better wording, thanks. Do you think examples like you

Perhaps.  If you think it's good, please feel free to use the
example.  (Some people may not want to have implementation-specific
descriptions in a protocol spec document, though).

> 64-bits. Let me think on this.

This interpretation is quite new to me.  If this is the case RFC4291
and RFC4861 are already contradicting each other.  Some people may not
*like* it, but I don't think the idea of interpreting RFC4291 that way
is supported.

> >   non-64-bit IID.  [...]

Okay.  After seeing a separate thread on "4291bis", I now guess this
might have to be a bit more verbose, such as:

    However, these documents may create an exception to the standard
    64-bit IID length scoped to a specific link-type technology when
    justified.  Note, however, that SLAAC [RFC4862] also assumes that
    the IID length is consistent with the IPv6 addressing
    architecture, which was [RFC4291] at the time [RFC4862] was
    published.  Since [RFC4291] states the IID length is 64 bits
    except those that start with the binary value 000, this
    effectively means a specific link-type document cannot make an
    exception unless either [RFC4291] is revised to allow such an
    exception for any link-type document or the link-type document
    reaches a consensus on formally updating [RFC4291] to make a
    special case exception.  This document does not intend to change
    this situation: for a link-type document to introduce a non-64-bit
    IID for that link, either this document should have been updated
    to allow such exceptions in general or the link-type document
    should reach a consensus on formally updating this document to
    make an exception.

> Help me understand this issue with the first part?

What's the "first part"?

> are not required to be 64 bits.  Personally, I would just recommend
against

We can discuss it, but that will require an update to RFC4861.  At
least I oppose to having that discussion for this document in terms of
helping rfc4291bis move forward.  That would be an unnecessary
distraction.

> >   "invalid".  [...]

I don't have an issue with discouraging it.  But as noted above, I'd
rather separate that discussion from this document.

--
JINMEI, Tatuya

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 11 Aug 2018 08:45:34 +1200

On 11/08/2018 00:54, Ole Troan wrote:
> And the fact that you are proposing changes to the current architecture

I'm really not. I don't believe I have suggested any change at all.
Not one single line of code has been harmed by this discussion.

> I think it is a pretty clear indication that we will struggle to reach consensus on what “clean” entails.

Yes, because it isn't easy. But I'd rather you take up the discussion
from this message:

https://mailarchive.ietf.org/arch/msg/ipv6/7Qk7L9sH4bDGcmwvkBM_Yi-NnJQ

    Brian

---

From: Ole Troan <[email-masked]>
Date: Fri, 10 Aug 2018 23:27:25 +0200

> On 10 Aug 2018, at 22:45, Brian E Carpenter <[email-masked]> wrote:
> 

Then I don’t see the purpose of this thread. 

Shall we take a step back people, and have a good think about what we’re trying to achieve here?

Ole

---

From: 神明達哉 <[email-masked]>
Date: Fri, 10 Aug 2018 15:03:06 -0700

At Fri, 10 Aug 2018 23:27:25 +0200,

> Shall we take a step back people, and have a good think about what we’re
trying to achieve here?

My understanding is that we're trying to help rfc4291bis move forward
to IS.  In that context the role of draft-farmer-6man-exceptions-64 is
to move the blocking part of rfc4291bis (i.e., the IID length) to the
separate document that is still standards track but is not in an IS
status.  The set of draft-farmer and resulting new rfc4291bis
shouldn't change anything, content-wise.

I thought it might succeed and was worth trying because:
- For people who want to keep the current IID length restriction,
  that's exactly what they want (except that the IID length part isn't
  given an "Internet Standard" status).
- For people who don't like the current IID length restriction, the
  result is at least the same as if we do nothing; if we don't do
  anything RFC4291 will still be the latest standard, which imposes
  the same IID length restriction anyway.  These people may not feel
  as happy as the first group of people, but at least they can avoid
  having an IS document with the restriction they hate.

Some other people might think we should rather not publish rfc4291bis
as IS unless either we have the IID length part in it or we reach
consensus on deprecating it and reflect it in rfc4291bis itself.  If
that's the conclusion of the WG, that's also fine for me - in that
case we should clearly declare so, just stop any further effort in
this area, and work on other things.  But or the moment I still have a
hope.

--
JINMEI, Tatuya

---

From: David Farmer <[email-masked]>
Date: Sat, 11 Aug 2018 09:09:07 -0500

> Shall we take a step back people, and have a good think about what we’re

I have a few questions for you,

1. Can a router be configured to advertises only a PIO with the L flag of
2001:db8:1:2::/112, and no A flag?

2. Can two hosts be mannually configured with host1-2001:db8:1:2::1 and
host2-2001:db8:1:2::2 with no prefix length?

3, If #1 and #2 are configured can the two host talk to each other?

4. If #1 and #2 are configured and the router is attached to the Internet
and the router advertises 2001:db8::/32 to the internet, can the hosts talk
to the internet?

5. Are any rules broken by 1 and 2? If so what?

Thanks

---

From: Ole Troan <[email-masked]>
Date: Sat, 11 Aug 2018 20:00:21 +0200

David,

> I have a few questions for you, 

Sure I will bite out of curiosity of what your point is. :-)

> 1. Can a router be configured to advertises only a PIO with the L flag of 2001:db8:1:2::/112, and no A flag?

Yes, at least all implementations I have worked on can. 

> 2. Can two hosts be mannually configured with host1-2001:db8:1:2::1 and host2-2001:db8:1:2::2 with no prefix length?  

Yes, although the one I am typing on cannot. 

> 3, If #1 and #2 are configured can the two host talk to each other?

Yes, they can talk directly to each other.

> 4. If #1 and #2 are configured and the router is attached to the Internet and the router advertises 2001:db8::/32 to the internet, can the hosts talk to the internet? 

Yes. 

> 5. Are any rules broken by 1 and 2? If so what?

No. 

Cheers,
Ole

---

From: David Farmer <[email-masked]>
Date: Sat, 11 Aug 2018 16:29:55 -0500

> 5. Are any rules broken by 1 and 2? If so what?

So, by my understanding those addreses have 16-bit IIDs how does that jive
with the following statment?

   For all unicast addresses, except those that start with the binary
   value 000, Interface IDs are required to be 64 bits long

Furthermore, I see no reason that the two hosts above couldn't be
configured via DHCPv6 or manual configuration.

The statement above clear applies to SLAAC. However, in my mind, it creates
a fundamental contradiction between the IPv6 Addressing Architecture and
IPv6 Neighbor Discovery.

For me it is that simple.

Thanks

---

From: Ole Troan <[email-masked]>
Date: Sat, 11 Aug 2018 23:47:22 +0200

David,

> On 11 Aug 2018, at 23:29, David Farmer <[email-masked]> wrote:
> 
> 
> 
> So, by my understanding those addreses have 16-bit IIDs how does that jive with the following statment?

No, in your example there is nothing said about the interface-id length. 
The only thing the L flag PIO says it that the /112 is used for on-link determination. 
E.g a PIO prefix with L set for ::/0 would make a host believe everything is on-link, but would not affect it’s idea of the iid length, if it had one. 

> Furthermore, I see no reason that the two hosts above couldn't be configured via DHCPv6 or manual configuration.
> 
> The statement above clear applies to SLAAC. However, in my mind, it creates a fundamental contradiction between the IPv6 Addressing Architecture and IPv6 Neighbor Discovery.
> 

Things are rarely that simple. 

Cheers 
Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 12 Aug 2018 11:14:47 +1200

> No, in your example there is nothing said about the interface-id length.

There's a reason for that: the IID length has no particular
meaning or signficance *after* the moment when the address is
configured on an interface. At that moment the IID becomes part
of a 128-bit opaque value. I could even argue that the IID itself
ceases to exist at that moment.

>> The statement above clear applies to SLAAC. However, in my mind, it creates a fundamental contradiction between the IPv6 Addressing Architecture and IPv6 Neighbor Discovery.

ND follows on-link determination, which depends on the address
matching the on-link prefix. At the moment of on-link determination,
what matters is the length of the on-link prefix. Again, at that moment,
the length of the IID is lost in history. So I don't think it's
exactly a contradiction. It's more that the two things are orthogonal.

   Brian

---

From: David Farmer <[email-masked]>
Date: Sat, 11 Aug 2018 18:32:44 -0500

Sent from my iPhone

> On Aug 11, 2018, at 16:47, Ole Troan <[email-masked]> wrote:
> 
> David,
> 

The only way for that to be true is that you are saying the example has no subnet prefix at all and therefore that a PIO with only the L flag is not a subnet prefix.

I’d agree when there is a PIO with an A flag, it is the subnet prefix and the PIO with the L flag is irrelevant. But if there is no PIO with an A flag then the PIO with the L flag has to be the subnet prefix. And therefore the example has an IID of 16-bits.

Can you point me to anything that says a PIO with only an L flag is not a subnet?

> Things are rarely that simple. 

I agree, and saying IIDs are 64 bits is just a little to simplistic too.

---

From: David Farmer <[email-masked]>
Date: Sat, 11 Aug 2018 19:35:28 -0500

Sent from my iPhone

>> On Aug 11, 2018, at 18:14, Brian E Carpenter <[email-masked]> wrote:
>> 

Ok, then it really should not be a problem to clarify that “the interface identifier length implies nothing about the subnet prefixes that are valid for routing or on-link determination.”

Because to many of us the totality of sections 2.5 and 2.5.1 of RFC4291 imply that only 64 bit subnets are valid for routing and on-link determination, as well as SLAAC.

---

From: David Farmer <[email-masked]>
Date: Sat, 11 Aug 2018 21:05:41 -0500

On Sat, Aug 11, 2018 at 7:35 PM, David Farmer <[email-masked]> wrote:

> >>>>> 1. Can a router be configured to advertises only a PIO with the L
> flag of 2001:db8:1:2::/112, and no A flag?
> >>>>
> >>>>> 2. Can two hosts be mannually configured with host1-2001:db8:1:2::1
> and host2-2001:db8:1:2::2 with no prefix length?
> >>>>
> >>>>> 4. If #1 and #2 are configured and the router is attached to the
> Internet and the router advertises 2001:db8::/32 to the internet, can the
> hosts talk to the internet?
> >>>>
> >>>> Yes.
> >>>>
> >> E.g a PIO prefix with L set for ::/0 would make a host believe
> everything is on-link, but would not affect it’s idea of the iid length, if
> it had one.
> >>
> >>>
> >>> The statement above clear applies to SLAAC. However, in my mind, it
> creates a fundamental contradiction between the IPv6 Addressing
> Architecture and IPv6 Neighbor Discovery.
> >
> Ok, then it really should not be a problem to clarify that “the interface
> identifier length implies nothing about the subnet prefixes that are valid
> for routing or on-link determination.”
>
> Because to many of us the totality of sections 2.5 and 2.5.1 of RFC4291
> imply that only 64 bit subnets are valid for routing and on-link
> determination, as well as SLAAC.

Thinking about it a little more, saying it implies nothing probably goes a
little too far, how about;

For all unicast addresses, except those that start with the binary value
000, Interface Identifiers are required to be 64 bits long. The rationale
for using 64-bit Interface Identifiers can be found in [RFC7421]. The
length of Interface Identifiers only implies a recommendation as to subnet
prefixes that are valid for routing or on-link determination."

---

From: Mark Smith <[email-masked]>
Date: Mon, 13 Aug 2018 06:19:08 +1000

> Ok, then it really should not be a problem to clarify that “the interface identifier length implies nothing about the subnet prefixes that are valid for routing or on-link determination.”

The topic of RFC5942 ("IPv6 Subnet Model: The Relationship between
Links and Subnet Prefixes") is that e.g.

"The on-link determination is separate
   from the address assignment.  A host can have IPv6 addresses without

Singh, et al.                Standards Track                    [Page 2]
^L
RFC 5942                    IPv6 Subnet Model                  July 2010

   any related on-link prefixes or can have on-link prefixes that are
   not related to any IPv6 addresses that are assigned to the host.  Any
   assigned address on an interface should initially be considered as
   having no internal structure as shown in [RFC4291]."

It also says configuring/assigning an address on an interface is
specifically not setting any on-link attribute of the the address.
That information comes from a Prefix List, and

"The Prefix List is populated via the following means:

       *  Receipt of a valid Router Advertisement (RA) that specifies a
          prefix with the L-bit set.  Such a prefix is considered
          on-link for a period specified in the Valid Lifetime and is
          added to the Prefix List.  (The link-local prefix is
          effectively considered a permanent entry on the Prefix List.)

       *  Indication of an on-link prefix (which may be a /128) via
          manual configuration, or some other yet-to-be-specified
          configuration mechanism."

It is a subtle and yet quite significant difference between IPv4 and IPv6.

---

From: David Farmer <[email-masked]>
Date: Sun, 12 Aug 2018 16:07:25 -0500

On Sun, Aug 12, 2018 at 3:19 PM, Mark Smith <[email-masked]> wrote:

> > >> On Aug 11, 2018, at 18:14, Brian E Carpenter <
> [email-masked]> wrote
>
...

> > Ok, then it really should not be a problem to clarify that “the
> interface identifier length implies nothing about the subnet prefixes that
> are valid for routing or on-link determination.”
> >
>

I agree, and this is a significant part of the argument in
draft-farmer-6man-exceptions-64.

> determination, as well as SLAAC.

However, in RFC4291;

   A slightly sophisticated host (but still rather simple) may
   additionally be aware of subnet prefix(es) for the link(s) it is
   attached to, where different addresses may have different values for
   n:

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

   Though a very simple router may have no knowledge of the internal
   structure of IPv6 unicast addresses, routers will more generally have
   knowledge of one or more of the hierarchical boundaries for the
   operation of routing protocols.  The known boundaries will differ
   from router to router, depending on what positions the router holds
   in the routing hierarchy.

Combined with;

This text clearly implies subnet prefixes are 64-bit in length, and it does
not clearly exempt routing and on-link determination from that implication.
Further, since the paragraph following the diagram above immediately goes
on to talk about routing, it seems quite logical that it is meant to imply
that at least the subnet prefixes used in routing are implied to be 64-bit
in length.

So, Mark do you support some kind of clarification on that the IID length
does not imply that the subnet prefixes for routing and on-link
determination are required to be 64 bit in length?

Thanks.

---

From: 神明達哉 <[email-masked]>
Date: Mon, 13 Aug 2018 11:18:26 -0700

At Sun, 12 Aug 2018 16:07:25 -0500,
>    attached to, where different addresses may have different values for

You are right.  And, at least rfc4291bis-09 tries to clarify that a
little bit:

   IPv6 unicast routing is based on prefixes of any valid length up to
   128 [BCP198].

> that at least the subnet prefixes used in routing are implied to be 64-bit

That's an understandable concern.  The "Though a very simple
router..." paragraph should probably be more clarified to avoid
confusion.

> determination are required to be 64 bit in length?

I can't speak for others, but I think that kind of clarification is
very helpful.  It's also related to why I asked this question for

[...]
>  the address in this case is to be considered an "opaque 128-bit

Either way, the fact that 2001:db8:1:2::/80 is an on-link prefix in
this case does not contradict the addressing architecture (and it
would make sense to clarify/emphasize that point explicitly in
draft-farmer-6man-exceptions-64).  And, regarding the IID, I believe
we could adopt either explanation:

A: the IID length is 48 bits in this case.  This will have to be
   considered an exception to Section 2.5.1 of RFC4291.
B: the IID is empty (or does not exist) in this case.  An address
   configured this way should be considered to have no internal
   structure (as shown in the first diagram of Section 2.5 of
   RFC4291).  In that sense it could still be considered compliant to
   RFC4291, but it's probably helpful if we also clarify that this is
   a "kind of exception" in that only the "minimum" form of
   architecture applies and Section 2.5.1 of RFC4291 is simply "not
   applicable".

According to the recent messages of this thread, option #B seems to be
preferred (and I personally also prefer that option).  I'd also note
that an "exception" of RFC6164 can be explained as an instance of this
option in practice, since the addresses assigned on inter-router p2p
links are most likely to be configured manually.

--
JINMEI, Tatuya

---

From: Ole Troan <[email-masked]>
Date: Mon, 13 Aug 2018 20:56:52 +0200

> On 13 Aug 2018, at 20:18, 神明達哉 <[email-masked]> wrote:
> 
> [....]

C: 64-bit IID with /80 on-link prefix. For SLAAC that’s a /64 PIO with A=1 and L=0 and a PIO with /80 L=1.  Meaning there is nothing said about the on-link properties of the rest of the /64.
I don’t think this is an exception. 

Cheers,
Ole

---

From: David Farmer <[email-masked]>
Date: Mon, 13 Aug 2018 14:28:20 -0500

On Mon, Aug 13, 2018 at 1:56 PM, Ole Troan <[email-masked]> wrote:

> C: 64-bit IID with /80 on-link prefix. For SLAAC that’s a /64 PIO with A=1
> and L=0 and a PIO with /80 L=1.  Meaning there is nothing said about the
> on-link properties of the rest of the /64.

Yes, if and only if there is a PIO with A=1, are you saying there MUST
always be a /64 PIO with A=1?

However, I believe C does say one thing about the rest of the /64, it can't
somehow be on-link or otherwise associated with a different link network
either.

---

From: Ole Troan <[email-masked]>
Date: Mon, 13 Aug 2018 21:41:00 +0200

> On 13 Aug 2018, at 21:28, David Farmer <[email-masked]> wrote:
> 
> 
> Yes, if and only if there is a PIO with A=1, are you saying there MUST always be a /64 PIO with A=1? 

No, I would imagine manual configuration would be more common for this scenario. 

> However, I believe C does say one thing about the rest of the /64, it can't somehow be on-link or otherwise associated with a different link network either.

It can. The fact that L=1 means just that.
If you generated a set of addresses out of a /64, then advertised /80s (from the /64) on a set of links and place hosts with corresponding addresses on the links, you would be perfectly within the letter of rfc4291.

DAD wouldn’t work well though. 

Cheers 
Ole

---

From: David Farmer <[email-masked]>
Date: Mon, 13 Aug 2018 14:49:02 -0500

The last of RFC4291 section 2.1 says;

   Currently, IPv6 continues the IPv4 model in that a subnet prefix is
   associated with one link.  Multiple subnet prefixes may be assigned
   to the same link.

On Mon, Aug 13, 2018 at 2:41 PM, Ole Troan <[email-masked]> wrote:

>> C: 64-bit IID with /80 on-link prefix. For SLAAC that’s a /64 PIO with
>> A=1 and L=0 and a PIO with /80 L=1.  Meaning there is nothing said about
>> the on-link properties of the rest of the /64.
> However, I believe C does say one thing about the rest of the /64, it
> can't somehow be on-link or otherwise associated with a different link
> network either.
>
>
> If you generated a set of addresses out of a /64, then advertised /80s
> (from the /64) on a set of links and place hosts with corresponding
> addresses on the links, you would be perfectly within the letter of rfc4291.
>

The last of RFC4291 section 2.1 says;

   Currently, IPv6 continues the IPv4 model in that a subnet prefix is
   associated with one link.  Multiple subnet prefixes may be assigned
   to the same link.

I my mind assing any part of the /64 to any other link network would
violate that rule. Or is a PIO with A=1 not a subnet prefix either?

> 2218 University Ave SE
> <https://maps.google.com/?q=2218+University+Ave+SE&entry=gmail&source=g>
>       Phone: 612-626-0815

---

From: 神明達哉 <[email-masked]>
Date: Mon, 13 Aug 2018 13:42:44 -0700

At Mon, 13 Aug 2018 20:56:52 +0200,

Ah, right.  If we want to list complete options, I see this is one of
them.  In fact, that's quite close to my own suggested interpretation
about a year ago:
https://www.ietf.org/mail-archive/web/ipv6/current/msg27681.html

> I don’t think this is an exception.

Right.  One advantage of this option is that we can at least explain
what's happening with currently deployed implementations without
making a formal exception to RFC4291.  But I have to admit that it
looks very awkward and it's more difficult to make it understandable
for many people.  I prefer option B because it would be a more
straightforward explanation that is easier to understand, at the cost
of admitting it as a kind of exception to RFC4291.

--
JINMEI, Tatuya

---

From: 神明達哉 <[email-masked]>
Date: Tue, 14 Aug 2018 12:47:41 -0700

At Mon, 13 Aug 2018 14:49:02 -0500,

> violate that rule. Or is a PIO with A=1 not a subnet prefix either?

To be pedantic, this text doesn't say a subnet prefix is associated
with one *and only one* link.  But I tend to agree that it's
reasonable to interpret this text with "and only one".  And I also
agree that if we adopt option C above, then it means we cannot assign
addresses from the /64 (with A=1) in different links corresponding to
different /80 (with L=1), unless we change the sense of RFC4291.  (It
also makes me recall the concept of "multi-link subnet", but AFAIR it
has never been officially standardized anyway).

If we can agree on the interpretation so far, then the difference
between option A/B and option C is actually quite significant.  Using
the previous example of manual address configuration of
"ifconfig en0 2001:db8:1:2::bad prefixlen 80",

a. If we adopt option A or B, we can use 2001:db8:1:2:3::bad in some
  other link than the link where 2001:db8:1:2::bad(/80) is configured.
b. If we adopt option C, it's not possible without violating the sense
  of RFC4291.

And now I'm starting to worry about whether we can reach a consensus
on this.  Those who don't like the /64 constant would probably hate
the restriction #b, too.  On the other hand, those who love the
constant might worry that if we allow the flexibility of #a then an
anachronistic ISP forces their customers to use DHCPv6 to configure
addresses with splitting a /64 for multiple different customers "to
save the address space".  One hope is that we might be able to agree
on the flexibility #a unless hosts' addresses are configured via
SLAAC, but I'm not sure if I can be that optimistic.

--
JINMEI, Tatuya

---

From: [email-masked]
Date: Tue, 14 Aug 2018 22:01:12 +0200 (CEST)

> b. If we adopt option C, it's not possible without violating the sense

For manual configuration, I take it for granted that I can configure
these on different links. So definitely alternative a.

Steinar Haug, AS2116

---

From: David Farmer <[email-masked]>
Date: Tue, 21 Aug 2018 10:39:52 -0500

> Shall we take a step back people, and have a good think about what we’re

Ole,

I think we did as you suggest here.

And to summarize, I think we are looking to clarify that RFC4291 does not
intend to imply that on-link or routing prefixes are required to be 64 bits
in length.

And here is some proposed text;

Note that the subnet prefix length derived from the Interface Identifier
length is independent of the prefix lengths that are used in routing or
on-link determination, even if identical length prefixes are often used in
practice.

So, where do we go from here?  Should I continue to working
on draft-farmer-6man-exceptions-64? Or, could something like the proposed
text be added to RFC4291bis?

Thanks

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 22 Aug 2018 11:43:44 +1200

> text be added to RFC4291bis?

fwiw, I think this draft is useful and should advance. I would also like to see a change of that sort in the 4291bis text, but getting a stable near-consensus version of 6man-exceptions seems like a pre-condition for agreeing on specific wording in 4291bis.

   Brian