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

From: Bob Hinden <[email-masked]>
Date: Wed, 16 Dec 2015 16:15:46 +0200

Hi,

I published the first 6man w.g. version (-00) version of the RFC4291bis draft.  See links below.

The changes in this version to make it a w.g. draft and editorial.

You can see the diff from the -06 individual version at:

https://tools.ietf.org//rfcdiff?url1=draft-hinden-6man-rfc4291bis-06.txt&url2=draft-ietf-6man-rfc4291bis-00.txt

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

Thanks,
Bob

Begin forwarded message:

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

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 17 Dec 2015 08:23:15 +1300

Hi Bob,

This is looking good. However, I'm wondering what we should do about
the positioning of Modified EUI-64 format. We have rather demoted this
via RFC 7136. You have already made the corresponding normative change
in rfc4291bis, but I wonder whether all the detailed text (starting
with "Modified EUI-64 format-based interface identifiers may have universal
scope") should be moved out to Appendix A.

Also this sentence could perhaps do with modernisation:

   The details of forming interface identifiers are defined in the
   appropriate "IPv6 over <link>" specification, such as "IPv6 over
   Ethernet" [RFC2464], and "IPv6 over FDDI" [RFC2467].

Regards
   Brian

On 17/12/2015 03:15, Bob Hinden wrote:
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [email-masked]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------

---

From: Bob Hinden <[email-masked]>
Date: Thu, 17 Dec 2015 13:14:45 +0200

Brian,

> On Dec 16, 2015, at 9:23 PM, Brian E Carpenter <[email-masked]> wrote:
> 
> Hi Bob,
> 

I think that makes sense, I will look into doing that.  I agree it is consistent with the intent of RFC7136.
>   Ethernet" [RFC2464], and "IPv6 over FDDI" [RFC2467].

Suggestions?  It could be a long list.

Bob

---

From: Fernando Gont <[email-masked]>
Date: Thu, 17 Dec 2015 14:02:17 -0300

On 12/16/2015 04:23 PM, Brian E Carpenter wrote:
> the positioning of Modified EUI-64 format. 

Remove it, and make RFC4291bis point to default-iids.

> We have rather demoted this

I'd say removed.

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

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 18 Dec 2015 07:55:44 +1300

Hi Fernando,

>> scope") should be moved out to Appendix A.

I actually think that would be a mistake. The text says that *if* an IID
is formed from a MAC address, this is how to do it, and we probably don't
want to delete that because it would simply leave a hole.

Possibly we should say that "an earlier recommendation was to form
IIDs from a MAC address as described in Appenidix A" and then refer
to default-iids. The sooner we get draft-ietf-6man-default-iids to
Proposed Standard, the better.

Regards,
   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 18 Dec 2015 08:06:53 +1300

On 18/12/2015 00:14, Bob Hinden wrote:

...
>>   Ethernet" [RFC2464], and "IPv6 over FDDI" [RFC2467].

Maybe just replace 2467 with "Transmission of IPv6 Packets over ITU-T
G.9959 Networks" [RFC 7428] which is the most recent one.

BTW, RFC 7428 possibly needs to be mentioned in draft-ietf-6man-default-iids.

   Brian

---

From: Fernando Gont <[email-masked]>
Date: Thu, 17 Dec 2015 17:31:24 -0300

Hi, Brian,

> want to delete that because it would simply leave a hole.

Having tha tin RFC4291bis and then saying what the default should be
elsewhere (default-iids), would be misleading.

If anything, let's mention this in default-ids   -- a two liner would do.

Thanks.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 18 Dec 2015 13:20:17 +1300

Hi Fernando,

> elsewhere (default-iids), would be misleading.

Yes, but saying nothing will confuse people, plus we have to be careful
about what is possible while promoting a document to Standard. Deleting
things is OK, but adding normative things isn't.
> If anything, let's mention this in default-ids   -- a two liner would do.

Well, I decided to see what it would look like if we delete it from 4291bis
(attached, and the Appendix A would also be deleted). Comments?

    Brian

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Fri, 18 Dec 2015 00:53:25 +0000

Brian,

I propose this modification. The first paragraph becomes two, and I think it becomes clearer when/why uniqueness of IID is not mandatory. As opposed to the reader having to do a double-take (although maybe that was just me).

________________________
Albert Manfredi
Principal Engineer
The Boeing Company
[email-masked]
+1 703-872-4218

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Brian E Carpenter
Sent: Thursday, December 17, 2015 19:20
To: Fernando Gont; Bob Hinden; IPv6 List
Subject: Re: <draft-ietf-6man-rfc4291bis-00.txt>

Hi Fernando,

    Brian

---

From: Bob Hinden <[email-masked]>
Date: Fri, 18 Dec 2015 08:10:58 +0200

Brian,

> On Dec 18, 2015, at 2:20 AM, Brian E Carpenter <[email-masked]> wrote:
> 
> Hi Fernando,
> 
> things is OK, but adding normative things isn’t.

I am not comfortable making a major change here, I think your suggestion to move the Modified EUI text to Appendix A is OK.  I think we should be cautions making changes for docs.  Pointers to other docs should be OK as long as we are careful with the language.

> (attached, and the Appendix A would also be deleted). Comments?

I will take a look.

Bob

> <iid-text.txt>

---

From: Philip Homburg <[email-masked]>
Date: Fri, 18 Dec 2015 13:24:39 +0100

>(attached, and the Appendix A would also be deleted). Comments?

"  The details of forming interface identifiers are defined in other
"  specifications, such as "Privacy Extensions for Stateless Address
"  Autoconfiguration in IPv6" [RFC4941] and "Recommendation on Stable
"  IPv6 Interface Identifiers" [I-D.ietf-6man-default-iids].  Specific
"  cases are described in appropriate "IPv6 over <link>" specifications,
"  such as "IPv6 over Ethernet" [RFC2464] and "Transmission of IPv6
"  Packets over ITU-T G.9959 Networks" [RFC7428].

"  Earlier versions of this document described a method of forming
"  interface identifiers in Modified EUI-64 format, which is no longer
"  recommended. 

This looks weird to me. Ignoring 'ITU-T G.9959 Networks', RFC2464 doesn't
seem to actually define anything, it refers to RFC2373, which is what we
are updating. Obviously RFC4941 doesn't provide stable addresses. So
we are left with an indirect reference to RFC7217 which at this moment
is not in wide spread use.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 19 Dec 2015 08:01:04 +1300

> is not in wide spread use.

They are all carefully written as non-normative references, but if we are
in the business of deleting text which is strictly unnecessary, we could
simplify even further:

 The details of forming interface identifiers are defined in other
 specifications. Earlier versions of this document described a method
 of forming interface identifiers in Modified EUI-64 format, which is
 no longer recommended.

   Brian

---

From: Fernando Gont <[email-masked]>
Date: Fri, 18 Dec 2015 15:29:27 -0500

Hi, Brian,

>  of forming interface identifiers in Modified EUI-64 format, which is

How does default-iids fit in there?

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 19 Dec 2015 11:08:51 +1300

> How does default-iids fit in there?

Nowhere. This simplified version would just set the constraints on IIDs
but say nothing at all about any specific way of generating them.

The more I think about, the better that seems to me for the addressing
*architecture* document. The fact that it want into details by
specifying a method for IID generation has caused us a lot of trouble
over the years.

(Philosophical comment: "When in doubt, cut it out" seems like a very
good motto for standards in general.)

   Brian

---

From: Philip Homburg <[email-masked]>
Date: Sat, 19 Dec 2015 14:38:44 +0100

> of forming interface identifiers in Modified EUI-64 format, which is

That doesn't look like an improvement to me.

I think it clear that we need stable IIDs for SLAAC
There is one mechanism in wide-spread use, which is defined in RFC4291.
There are other mechanisms that might be better but are hardly used at 
this time.

So I don't see how we can remove EUI-64 based IIDs at this time. Making
them deprecated would essentially be a downref without any operational
experience.

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 20 Dec 2015 07:58:00 +1300

On 20/12/2015 02:38, Philip Homburg wrote:

...
> them deprecated would essentially be a downref without any operational

Really? I haven't seen a MAC-address based IID on my off-the-shelf Windows
box for years now. I see many servers with IIDs like ::53 or
::face:b00c:0:25.

There's published work showing the variety of IIDs in practical use, such as
http://dl.acm.org/citation.cfm?id=2680822 and http://dl.acm.org/citation.cfm?id=2815678

(Complaints about the ACM paywall should be addressed to the ACM, not me ;-)

I think we have a lot of running code experience that the format of the IID
absolutely doesn't matter for connectivity purposes. Privacy is a different
issue, of course.

But basically I've come to agree with Fernando. Details of IID generation
don't belong in the architecture document.

    Brian

---

From: Philip Homburg <[email-masked]>
Date: Sat, 19 Dec 2015 23:38:55 +0100

>box for years now. I see many servers with IIDs like ::53 or

I don't know much about Windows. It seems that Windows defaults to 
privacy extensions and can be switched to EUI-64. Maybe I missed something?

>(Complaints about the ACM paywall should be addressed to the ACM, not me ;-)

So basically you want to deprecate any stable IID?

That's what I get from the first paper. Nobody uses SLAAC with stable
IIDs.

If that's case, why not just deprecate that?

My problem is not that we can't handle a varity of IIDs, of couse we can.

My problem is the operational issues that may be caused by replacing EUI-64
with RFC7217. And we just don't know.

>don't belong in the architecture document.

If you say that only temporary (privacy) addresses are really in use. 
Then you may have a point.

Otherwise, because my point still stands. For stable IIDs we don't have
any experience with anything other than EUI-64.

Reading the IPv6 RFCs together as a standard that describes how to run
IPv6 over ethernet, if you remove EUI-64 from the architecture document,
you have just created a hole in the standard.

(I guess this is the last mail I'll write about this subject, affected
network admins will complain outside the IETF)

---

From: Mark Smith <[email-masked]>
Date: Sun, 20 Dec 2015 14:26:33 +1100

On 20 December 2015 at 09:38, Philip Homburg <[email-masked]>
wrote:
>>http://dl.acm.org/citation.cfm?id=2680822 and
http://dl.acm.org/citation.cfm?i
>>d=2815678

I think we do, statically configured addresses are stable IIDs.

We'd have trouble changing from stable EUI-64s to stable something else if
EUI-64s were used instead of a neighbor discovery process (i.e., the IPv6
IID field is or is a version of the link-layer address, and therefore to
send at layer 2 the IID is copied into the link-layer destination address,
per what XNS/IPX did). However, since there is ND, deriving IPv6 IIDs from
EUI-64s was an operational convenience, not a necessity.

Are you really objecting because you've got operational scripts/procedures
that rely on the format and meaning of IID EUI-64 bits?

> you have just created a hole in the standard.

I don't think so, the IPv6 over Ethernet RFC also provides those details.

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Sun, 20 Dec 2015 23:31:50 +0000

> don't belong in the architecture document.

A general statement about uniqueness in the subnet prefix, and opaqueness of the IID wrt the rest of the IPv6 address, would add clarity without being overly detailed and repetitious, IMO. With the changes over the past few years, this IID has become more similar to what a host ID has to look like in IPv4 (even though with the vastly increased number of bits), than it is to the previous idea that IIDs would often/likely be globally unique. We got away from the implied IPX-like structure, in other words. Nothing wrong with making that clear.

Bert