Subject: Re: Review of draft-ietf-6man-rfc4291bis-03

From: Bob Hinden <[email-masked]>
Date: Wed, 7 Sep 2016 13:50:57 -0700

Hi Tim,

Thanks for the review.  Comments below.

Bob

> On Jul 18, 2016, at 9:23 AM, Tim Chown <[email-masked]> wrote:
> 
> Hi again,
> 
> Ole asked me to review draft-ietf-6man-rfc4291bis-03 as well.
> 
> This document also appears to be close to being ready. It seems to meet the criteria of RFC6410 as a candidate for advancement to IS.
> 
> A general question exists as per the other two -bis documents as to whether new material that’s incorporated should include references for the RFCs the updates draw from. Again, that seems a little inconsistent in this document. Two other general questions are whether ULAs should be explicitly called out here (as a replacement for site-locals), and whether we should add IANA registry pointers in the IANA section (no action for IANA, but a reader will then know which registries are in use).  There is no mention of ULAs in the change log, so it’s not clear if it’s been discussed and rejected, or not.

See specific answers to these topics below.

> General comments:
> 
> Section 2:
> 
> p. 7 it looks like the new Section 2.2.3 takes text/content from RFC5952, but does not cite it. Should it?

It does as noted in Appendix B.  It incorporates the update, I don’t think it needs to be cited in the text.

> 
> p.9 and p.10 - is there a requirement to add a reference to RFC4193 for ULAs here? They are defined at Global scope, but have a specific binary prefix that could be added to the table on p.9. While treated in principle by applications as Global scope addresses, their handling/use can differ, e.g. through RFC6724-based address selection.  That said, I note that RFC4193 does not say it formally updates RFC4192.

No, I don’t think there is a requirement.  Much earlier version of this document (e.g., RFC2373) had specific entries in this table, but the working group decided to remove them.  The authoritative place to see all defined prefixes is to look is the IANA registry, not this document.  This section points to the IANA registries where specific prefix types are defined.  There are, of course, other formats in the IANA registries that are not in RFC2460 or the bis document either.

Also, ULAs are defined in RFC4193 as having global scope (that is, not “treated" as global scope).

> 
> p.11 pragmatically, should there be a mention of RFC7421 (Why /64?) at the end of Section 2.4?  Because assumptions *are* now made about the 64-bit boundary 10 years on from the original publication of 4291.

RFC7421 is informational, and while very useful, I don’t think it needs to be cited here.  Nor does it update RFC4291.

> 
> p.11 this section on IIDs adds references to RFC7721 (security & privacy considerations) and RFC7217 (stable privacy IIDs), but doesn’t differentiate between “temporary" addresses (as per RFC4941) and regular addresses. Should it?

This topic is discussed in RFC7721.  See Section 4.6.

> 
> p.11 there is no reason given here for the IEEE MAC derived IIDs being no longer recommended. This could be written to be more clearly integrated with the reference to RFC7721 above.

I could add another reference to RFC7721, but not sure it would add very much value.

> 
> p.14 again, should the site-local section be replaced with ULAs?

Not replaced given how we deprecated site-local, but I think adding few sentences pointing to the ULA spec would make sense.  This would be an informational reference.

> 
> p.16 there is no reference to RFC7371 (multicast address architecture update) or RFC7346 (multicast scopes); should these be added?

For RFC73712, see the answer to next issue.

For RFC7346, the changes were incorporated (and noted in Appendix B).  RFC7346 was very clear on the change it wanted in RFC4291bis.  RFC7346 also updates RFC4007, that is included as a reference.    I don’t see any harm adding a reference, but not much value either.

> 
> p.16 it seems that RFC7371 changes were backed out in the -02 version of this bis document, on the grounds that implementations hadn’t changed to reflect this.  This surprised me, but I assume this was discussed and there is WG consensus to do this?

Correct, there was not any evidence of consistent implementations (and evidence of inconsistent implementations).  One of the authors said there were other problems and didn’t recommend including this in RFC4291bis, and it would be better to work on on 3306bis and 3956bis at some point in the future.

It was discussed on the list and at the Buenos Aires and Berlin meetings.

> 
> p.17 a good chunk of this page is copied from RFC7346, without citing it.
> 
> Section 3 (IANA):

The purpose of “IANA Considerations” is to tell the IANA to do something.  Since we aren’t asking IANA to do anything, we don’t need to tell them to do something.  I don’t think we need to describe the current state of the IANA registries as they will change over time.

> 
> p.21 there is no mention of RFC5453, which created the IANA registry for reserved IPv6 interface identifiers. Should there be?
> 
> p.21  there is no mention of the IANA IPv6 Special-Purpose Address Registry, as per RFC6890. Should there be?
> 
> p.21 should Section 6 of RFC7346 be captured here?

I went back and looked at the current IANA considerations in the draft, and it is left over from RFC4291.  It should be removed for the reasons I cite above.

> 
> Appendix A
> 
> p.24 RFC7136 talks about the (lack of) meaning in IID bits, esp. related to the u,g bits. Do we need to refer to this in Appendix A, where IEEE MAC-based IIDs are discussed? Or is this not important given we’re not recommending this form of IID generation any more?

Right it isn’t important, as it says in Section 2.4.1

   Earlier versions of this document described a method of forming
   interface identifiers derived from IEEE MAC-layer addresses call
   Modified EUI-64 format.  These are described in Appendix A and are no
   longer recommended.

> 
> Other comments:
> 
> RFC6052 on IPv6 Addressing of IPv4/IPv6 Translators states it formally updates RFC4291.  It reserves 64:ff9b::/96 as a well-known prefix. Though it then also says in the text that no updates to RFC4291 are required. Do we need to change anything in 4291bis on account of RFC6052 or not?

I agree it’s an odd mix of updates and probably shouldn't say it updates RFC2460 and then say in the text it doesn’t.

I don’t see anything to change.

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

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 8 Sep 2016 11:25:33 +1200

>> On Jul 18, 2016, at 9:23 AM, Tim Chown <[email-masked]> wrote:
...
> Also, ULAs are defined in RFC4193 as having global scope (that is, not “treated" as global scope).

And just to be clear, that is not the same thing as "Globally Reachable", the
phrase introduced by draft-bchv-rfc6890bis that will be used in the update of
http://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml

At the moment, the registry shows ULAs with Global = False, which is false.
In future they will be shown as Globally Reachable = False.

I think that publishing 6890bis and updating the registry will be enough,
without mentioning this in 4291bis.

   Brian

---

From: Bob Hinden <[email-masked]>
Date: Thu, 8 Sep 2016 09:53:09 -0700

Brian,

> On Sep 7, 2016, at 4:25 PM, Brian E Carpenter <[email-masked]> wrote:
> 

I agree that is correct.

> without mentioning this in 4291bis.

I agree.

Thanks,
Bob

---

From: Tim Chown <[email-masked]>
Date: Fri, 16 Sep 2016 13:24:49 +0000

Hi Bob,

Many thanks. Just a few responses in-line. Other items pruned for brevity.

> On 7 Sep 2016, at 21:50, Bob Hinden <[email-masked]> wrote:
> 
> Hi Tim,
> 

It was also inconsistent in 2460-bis as to whether something was cited in the main body, or just referred to in note form in the Appendix. And there’s quite a few RFCs mentioned in Appendix B of 4291-bis not cited in the main body, but also quite a few that are. We didn’t resolve this consistency issue in the Berlin discussion, but it was noted.
> Also, ULAs are defined in RFC4193 as having global scope (that is, not “treated" as global scope).

I agree with Brian’s follow-up on this. There were two questions in Berlin - one was removal of mention of site-local (which was agreed), the other was whether to specifically add reference to ULAs (for which I think Ole added an issue tracker entry).

> RFC7421 is informational, and while very useful, I don’t think it needs to be cited here.  Nor does it update RFC4291.

Though I’d argue in practice the 64-bit boundary for host subnets is a significant element of the v6 addressing architecture

> Not replaced given how we deprecated site-local, but I think adding few sentences pointing to the ULA spec would make sense.  This would be an informational reference.

Maybe Ole needs to nudge the issue tracker entry here to get WG consensus.

> For RFC7346, the changes were incorporated (and noted in Appendix B).  RFC7346 was very clear on the change it wanted in RFC4291bis.  RFC7346 also updates RFC4007, that is included as a reference.…

As above, it’s not just a matter of relative importance, but I feel t’s good to be consistent. Some readers may not note Appendix B and expect to read the main body standalone, and the citation would help them.

> I went back and looked at the current IANA considerations in the draft, and it is left over from RFC4291.  It should be removed for the reasons I cite above.

I think your email of yesterday on  helps clear this up, or will at least get us to a good resolution.

Best wishes,
Tim

---

From: Bob Hinden <[email-masked]>
Date: Mon, 19 Sep 2016 16:11:59 +0300

Hi Tim,

> On Sep 16, 2016, at 6:24 AM, Tim Chown <[email-masked]> wrote:
> 
> Hi Bob,
> 

Thanks!

> It was also inconsistent in 2460-bis as to whether something was cited in the main body, or just referred to in note form in the Appendix. And there’s quite a few RFCs mentioned in Appendix B of 42…

I used my editorial judgement as to which ones were cited in the text or in the appendix.  In general I didn’t cite in the text it if the change was fully incorporated, and did cite it if there were more considerations.  The history of how we got to rfc4291bis is best left for the Appendix.

I am starting to think when the bis documents (rfc2460bis, rfc4291bis, rfc1981bis) are further along in the process, these sections might be better rewritten as just a summary of the changes instead of the per draft changes.  A thought for later.

> I agree with Brian’s follow-up on this. There were two questions in Berlin - one was removal of mention of site-local (which was agreed), the other was whether to specifically add reference to ULAs…

Looking back at the deprecating document RFC3879, it says:

   The references to site local addresses should be removed as soon as
   practical from the revision of the Default Address Selection for
   Internet Protocol version 6 [RFC3484], the revision of the Basic
   Socket Interface Extensions for IPv6 [RFC3493], and from the revision
   of the Internet Protocol Version 6 (IPv6) Addressing Architecture
   [RFC3513].

I think that would justify removing it from rfc4291bis.  I am thinking of leaving the section, have it say it is deprecated (combine first and third paragraph), remove the format diagram, and keep the new ULA paragraph (from -04).

> Though I’d argue in practice the 64-bit boundary for host subnets is a significant element of the v6 addressing architecture

OK, I could add a sentence to the end of the forth paragraph in Section 2.4.1

> Maybe Ole needs to nudge the issue tracker entry here to get WG consensus.

See above.

> As above, it’s not just a matter of relative importance, but I feel t’s good to be consistent. Some readers may not note Appendix B and expect to read the main body standalone, and the citation wou…

Seem to me that an implementor who wants to implement multicast, will need to read all of the multicast specifications, but as I said I don’t see any harm adding another reference here, so I will do that.

> I think your email of yesterday on  helps clear this up, or will at least get us to a good resolution.

Good.  It will be in the next version.

Thanks,
Bob

---

From: Tim Chown <[email-masked]>
Date: Mon, 19 Sep 2016 14:44:42 +0000

Hi Bob,

> On 19 Sep 2016, at 14:11, Bob Hinden <[email-masked]> wrote:
> 
> Hi Tim,
> 

Well, it’s not so much a history, just ensuring we give the reader pointers to references for further reading. If there is nothing further to read, then I agree with you. Whatever we do, having the Appendix as a change log is valuable.

> I am starting to think when the bis documents (rfc2460bis, rfc4291bis, rfc1981bis) are further along in the process, these sections might be better rewritten as just a summary of the changes instea…

Something to consider when all documents are otherwise ready, perhaps. But I think I agree.

> I think that would justify removing it from rfc4291bis.  I am thinking of leaving the section, have it say it is deprecated (combine first and third paragraph), remove the format diagram, and keep…

I would suggest complete removal. The prior inclusion of site-locals should be mentioned in the Appendix change log. There was, from memory, no strong consensus either way on inclusion of ULAs when this was raised in Berlin. I can see arguments either way, but I would generally agree with Brian Carpenter’s view.

> Good.  It will be in the next version.

Great.

Thanks,
Tim

---

From: Bob Hinden <[email-masked]>
Date: Tue, 20 Sep 2016 15:35:08 +0300

Tim,

Removing some of the email replies.

> On Sep 19, 2016, at 5:44 PM, Tim Chown <[email-masked]> wrote:
> 
> Hi Bob,
> 
…..

> Something to consider when all documents are otherwise ready, perhaps. But I think I agree.

Good.

> I would suggest complete removal. The prior inclusion of site-locals should be mentioned in the Appendix change log. There was, from memory, no strong consensus either way on inclusion of ULAs when…

I would like to hear some other views on this.  The text I have in my local -05 version is:

2.4.7.  Site-Local IPv6 Unicast Addresses

   Site-Local addresses were originally designed to be used for
   addressing inside of a site without the need for a global prefix.
   Site-local addresses are now deprecated as defined in [RFC3879].

   The special behavior of this prefix defined in [RFC3513] must no
   longer be supported in new implementations (i.e., new implementations
   must treat this prefix as Global Unicast).  Existing implementations
   and deployments may continue to use this prefix.

   A new type of address has been defined that can be generated locally
   and is intended to be used as an alternative to Site-Local addresses.
   These are called Unique Local Addresses (ULA) [RFC4193].

Thanks,
Bob

---

From: David Farmer <[email-masked]>
Date: Tue, 20 Sep 2016 09:39:23 -0500

Focusing on Local IPv6 Addressing

On Tue, Sep 20, 2016 at 7:35 AM, Bob Hinden <[email-masked]> wrote:

> >> I think that would justify removing it from rfc4291bis.  I am thinking
> of leaving the section, have it say it is deprecated (combine first and
> third paragraph), remove the format diagram, and keep the new ULA paragraph
> (from -04).
> >
> > I would suggest complete removal. The prior inclusion of site-locals
> should be mentioned in the Appendix change log. There was, from memory, no
> strong consensus either way on inclusion of ULAs when this was raised in
> Berlin. I can see arguments either way, but I would generally agree with
> Brian Carpenter’s view.
>

Since [RFC3879] references ULA [RFC4193] in its draft form it seems obvious
to me that ULA is intended to replace Site-Local addresses, and even though
[RFC4193] didn't formally update [RFC4291] at least a references to
[RFC4193] belongs in 4921-bis.

Further, I suggest retitling the sub-section as "Other Local IPv6
Addresses" to move the primary focus of sub-section away from Site-Local
which is deprecated, to be more generically about Local IPv6 Addresses
other than Link-Local.  Then I'd like to see the discussion start with ULA
as the current form of Local IPv6 Addresses and then talk about Site-Local.

Coming together as something like the following.

2.4.7.  Other Local IPv6 Addresses

   Unique Local Addresses (ULA) [RFC4193], the current form of
   Local IPv6 Addresses, are intended to be used for local
   communications, are globally unique, and are not expected to be
   routable on the global Internet.

   Site-Local addresses, deprecated by [RFC3879], the previous form
   of Local IPv6 Addresses, were originally designed to be used for
   addressing inside of a site without the need for a global prefix.

   The special behavior of the Site-Local prefix defined in [RFC3513]
   must no longer be supported in new implementations (i.e., new
   implementations must treat this prefix as Global Unicast).  Existing
   implementations and deployments may continue to use this prefix.

In my opinions this true to the intent of [RFC3879] to remove Site-Local.

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: David Farmer <[email-masked]>
Date: Tue, 20 Sep 2016 09:53:06 -0500

On Tue, Sep 20, 2016 at 9:39 AM, David Farmer <[email-masked]> wrote:

> Since [RFC3879] references ULA [RFC4193] in its draft form it seems
> obvious to me that ULA is intended to replace Site-Local addresses, and
> even though [RFC4193] didn't formally update [RFC4291] at least a
> references to [RFC4193] belongs in 4921-bis.
>

Whops, obviously [RFC4193] couldn't formally update [RFC4291] it came
before it.  So, let me re-phrase that, it seems to me that the original
intent of [RFC3879] was that ULA would replace Site-Local in what became
[RFC4291] and therefore at least a references to [RFC4193] belongs in
4921-bis.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 21 Sep 2016 10:24:22 +1200

Tim wrote:
...
> I would suggest complete removal. The prior inclusion of site-locals should be mentioned in the Appendix change log. There was, from memory, no strong consensus either way on inclusion of ULAs when…

Not quite sure what my view was anymore, but:

On 21/09/2016 02:39, David Farmer wrote:
...
>    implementations and deployments may continue to use this prefix.

I like this approach, except for one phrase that will ring many bells
unless fixed. I strongly recommend:

s/are globally unique/have global unicast scope/

Otherwise you will receive many angry messages pointing out that ULA
prefixes as currently defined have a finite probability of clashing.

    Brian

---

From: David Farmer <[email-masked]>
Date: Wed, 21 Sep 2016 01:18:45 -0500

> prefixes as currently defined have a finite probability of clashing.

I'm fine with that.  I mostly just wanted to propose the approach. I picked
what I thought were a few of the most important aspects from the fist
paragraph of section 1 of RFC4193 itself, but I'm happy to defer to your
opinion on that matter.

---

From: Bob Hinden <[email-masked]>
Date: Wed, 21 Sep 2016 10:37:59 +0300

David, Brian,

I am OK with this approach and will proceed to incorporate it.

Bob

> On Sep 21, 2016, at 9:18 AM, David Farmer <[email-masked]> wrote:
> 
> 
> 
> On Tue, Sep 20, 2016 at 5:24 PM, Brian E Carpenter <[email-masked]> wrote:
> 
> I'm fine with that.  I mostly just wanted to propose the approach. I picked what I thought were a few of the most important aspects from the fist paragraph of section 1 of RFC4193 itself, but I'm happy to defer to your opinion on that matter.
> 
> --

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 21 Sep 2016 10:00:44 +0200

What about probabilistically unique, which is more precise?

Regards,
Jordi

-----Mensaje original-----
De: ipv6 <[email-masked]> en nombre de Bob Hinden <[email-masked]>
Responder a: <[email-masked]>
Fecha: miércoles, 21 de septiembre de 2016, 9:37
Para: David Farmer <[email-masked]>, Brian Carpenter <[email-masked]>
CC: "[email-masked]" <[email-masked]>, Bob Hinden <[email-masked]>
Asunto: Re: ULA text [was: Review of draft-ietf-6man-rfc4291bis-03]

    David, Brian,

    Bob

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 22 Sep 2016 08:12:42 +1200

> What about probabilistically unique, which is more precise?

It's true, but every time we mention it somebody starts a discussion of ULA-C.
I think that is a distraction for 4291bis. Also, the distinction between global
unicast scope and globally routable is clarified in draft-bchv-rfc6890bis,
but it's 4291bis itself that defines "global unicast scope".

Rgds
   Brian

> **********************************************
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.consulintel.es
> The IPv6 Company
> 
> This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
> 
> 
> 
>

---

From: Bob Hinden <[email-masked]>
Date: Thu, 22 Sep 2016 10:26:13 +0300

Brain,

> On Sep 21, 2016, at 11:12 PM, Brian E Carpenter <[email-masked]> wrote:
> 
> but it's 4291bis itself that defines "global unicast scope”.

I agree.

Bob

---

From: Tim Chown <[email-masked]>
Date: Thu, 22 Sep 2016 08:13:51 +0000

> On 22 Sep 2016, at 08:26, Bob Hinden <[email-masked]> wrote:
> 
> Brain,
> 

And I think Brian’s suggested rewording (s/are globally unique/have global unicast scope/) removes the explicit use of the word unique from the text anyway.

Raking up ULA-C would be a distraction.

Tim