RFC2460bis

Post by Bob Hinden
https://tools.ietf.org/rfcdiff?url2=draft-hinden-6man-rfc2460bis-00.txt
The plan is to do a series of new versions, each addressing a single
update to allow the changes to be tracked very carefully. Please
review this draft to verify there are no content changes.

Do you have a list of RFCs that "update" 2460 that you plan to merge, and
do you know what order you might do them in?

Post by Bob Hinden
This is part of the project to move the core IPv6 specifications to Internet Standard.

Awesome!

--
Michael Richardson <mcr+***@sandelman.ca>, Sandelman Software Works
-= IPv6 IoT consulting =-

Bob Hinden

2015-08-05 20:10:48 UTC

Michael,

Post by Michael Richardson

Do you have a list of RFCs that "update" 2460 that you plan to merge, and
do you know what order you might do them in?

See: https://tools.ietf.org/html/rfc2460

No planned order. May start with the RFC6437 (Flow Label Specification) as it should be very straight forward, that is, remove the appendix and point to RFC6437, and it appears we have implementation experience based on the recent thread on the IPv6 list.

Post by Michael Richardson

Post by Bob Hinden
This is part of the project to move the core IPv6 specifications to Internet Standard.

Awesome!

Thanks,
Bob

Bob Hinden

2015-09-01 07:34:24 UTC

Hi,

I published a -00 version of an RFC4291bis draft. See links below.

The purpose of this version is to establish a baseline from RFC4291. The only changes are formatting (XML is slightly different from .nroff), differences between an RFC and Internet Draft, fixing a few ID Nits, and updates to the authors information. There should not be any content changes to the specification. You can see the diff from RFC4291 at:

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

The plan is to do a series of new versions, each addressing a single update to allow the changes to be tracked very carefully. Please review this draft to verify there are no content changes.

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

Thanks,
Bob

Subject: New Version Notification for draft-hinden-6man-rfc4291bis-00.txt
Date: September 1, 2015 at 10:19:18 AM GMT+3
A new version of I-D, draft-hinden-6man-rfc4291bis-00.txt
has been successfully submitted by Robert M. Hinden and posted to the
IETF repository.
Name: draft-hinden-6man-rfc4291bis
Revision: 00
Title: IP Version 6 Addressing Architecture
Document date: 2015-09-01
Group: Individual Submission
Pages: 25
URL: https://www.ietf.org/internet-drafts/draft-hinden-6man-rfc4291bis-00.txt
Status: https://datatracker.ietf.org/doc/draft-hinden-6man-rfc4291bis/
Htmlized: https://tools.ietf.org/html/draft-hinden-6man-rfc4291bis-00

Alexandru Petrescu

2015-09-01 12:17:10 UTC

I reviewed and there is no content change.

Alex

Post by Bob Hinden
Hi,
I published a -00 version of an RFC4291bis draft. See links below.
The purpose of this version is to establish a baseline from RFC4291.
The only changes are formatting (XML is slightly different from
.nroff), differences between an RFC and Internet Draft, fixing a few
ID Nits, and updates to the authors information. There should not be
any content changes to the specification. You can see the diff from
https://tools.ietf.org/rfcdiff?url2=draft-hinden-6man-rfc4291bis-00.txt
The plan is to do a series of new versions, each addressing a single
update to allow the changes to be tracked very carefully. Please
review this draft to verify there are no content changes.
This is part of the project to move the core IPv6 specifications to Internet Standard.
Thanks, Bob

for draft-hinden-6man-rfc4291bis-00.txt Date: September 1, 2015 at
A new version of I-D, draft-hinden-6man-rfc4291bis-00.txt has been
successfully submitted by Robert M. Hinden and posted to the IETF
repository.
Name: draft-hinden-6man-rfc4291bis Revision: 00 Title: IP Version
https://www.ietf.org/internet-drafts/draft-hinden-6man-rfc4291bis-00.txt

Status:
https://datatracker.ietf.org/doc/draft-hinden-6man-rfc4291bis/

Post by Bob Hinden

https://tools.ietf.org/html/draft-hinden-6man-rfc4291bis-00

--------------------------------------------------------------------
Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Bob Hinden

2015-10-08 23:06:16 UTC

Hi,

I published a -01 version of the RFC4291bis "IP Version 6 Addressing Architectureâ draft. See links below.

The main purpose of this draft is as follows was to incorporate the updates made by RFC5952 regarding the text format when outputting IPv6 addresses. A new section was added for this and all of the addresses in this document were changed to lower case.

Other changes were to revise the update section to document the changes from RFC4291 and a few editorial changes.

You can see the diff from RFC4291 at:

https://tools.ietf.org/rfcdiff?url2=draft-hinden-6man-rfc4291bis-01.txt

Please review this draft to verify that the changes are appropriate.

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

Thanks,
Bob

A new version of I-D, draft-hinden-6man-rfc4291bis-01.txt
has been successfully submitted by Robert M. Hinden and posted to the
IETF repository.
Name: draft-hinden-6man-rfc4291bis
Revision: 01
Title: IP Version 6 Addressing Architecture
Document date: 2015-10-08
Group: Individual Submission
Pages: 27
URL: https://www.ietf.org/internet-drafts/draft-hinden-6man-rfc4291bis-01.txt
Status: https://datatracker.ietf.org/doc/draft-hinden-6man-rfc4291bis/
Htmlized: https://tools.ietf.org/html/draft-hinden-6man-rfc4291bis-01
Diff: https://www.ietf.org/rfcdiff?url2=draft-hinden-6man-rfc4291bis-01
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".

Bob Hinden

2015-10-10 01:30:41 UTC

Hi,

I published a -02 version of the RFC4291bis "IP Version 6 Addressing Architectureâ draft. See links below.

The purpose of this draft is to resolve the open Errata on RFC4291, this includes:

Errata ID: 3480: Corrects the definition of Interface-Local multicast scope include that packets with
interface-local scope received from another node must be discarded
Errata ID: 1627: Remove extraneous "of" in Section 2.7.
Errata ID: 2702: This errata is marked rejected. No change is required.
Errata ID: 2735: This errata is marked rejected. No change is required.
Errata ID: 4406: This errata is marked rejected. No change is required.
Errata ID: 2406: This errata is marked rejected. No change is required.
Errata ID: 863: This errata is marked rejected. No change is required.
Errata ID: 864: This errata is marked rejected. No change is required.
Errata ID: 866: This errata is marked rejected. No change is required.

Other changes were to update the references to current versions of referenced RFCs and a few editorial changes.

You can see the diff from RFC4291 at:

https://tools.ietf.org/rfcdiff?url2=draft-hinden-6man-rfc4291bis-02.txt

Please review this draft to verify that the changes are appropriate.

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

Thanks,
Bob

A new version of I-D, draft-hinden-6man-rfc4291bis-02.txt
has been successfully submitted by Robert M. Hinden and posted to the
IETF repository.
Name: draft-hinden-6man-rfc4291bis
Revision: 02
Title: IP Version 6 Addressing Architecture
Document date: 2015-10-09
Group: Individual Submission
Pages: 28
URL: https://www.ietf.org/internet-drafts/draft-hinden-6man-rfc4291bis-02.txt
Status: https://datatracker.ietf.org/doc/draft-hinden-6man-rfc4291bis/
Htmlized: https://tools.ietf.org/html/draft-hinden-6man-rfc4291bis-02
Diff: https://www.ietf.org/rfcdiff?url2=draft-hinden-6man-rfc4291bis-02
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â.

Bob Hinden

2015-10-15 20:43:42 UTC

Hi,

I published a -03 version of the RFC4291bis "IP Version 6 Addressing Architectureâ draft. See links below.

The main change was to incorporate the updates made by RFC7136 to deprecate the U and G bits in Modified EUI-64 format Internet IDs,

Other changes were to add a note to the reference section acknowledging the authors of the updating documents and a few editorial changes.

You can see the diff from RFC4291 at:

https://tools.ietf.org/rfcdiff?url2=draft-hinden-6man-rfc4291bis-03.txt

Please review this draft to verify that the changes are appropriate.

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

Thanks,
Bob

A new version of I-D, draft-hinden-6man-rfc4291bis-03.txt
has been successfully submitted by Robert M. Hinden and posted to the
IETF repository.
Name: draft-hinden-6man-rfc4291bis
Revision: 03
Title: IP Version 6 Addressing Architecture
Document date: 2015-10-15
Group: Individual Submission
Pages: 28
URL: https://www.ietf.org/internet-drafts/draft-hinden-6man-rfc4291bis-03.txt
Status: https://datatracker.ietf.org/doc/draft-hinden-6man-rfc4291bis/
Htmlized: https://tools.ietf.org/html/draft-hinden-6man-rfc4291bis-03
Diff: https://www.ietf.org/rfcdiff?url2=draft-hinden-6man-rfc4291bis-03
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".

Bob Hinden

2015-10-15 21:52:10 UTC

Hi,

I published a -04 version of the RFC4291bis "IP Version 6 Addressing Architectureâ draft. See links below.

The change in this version was to incorporate the updates made by RFC6052. The change was to add a text in Section 2.3 that points to the IANA registries that records the prefix defined in RFC6052 and a number of other special use prefixes.

You can see the diff from RFC4291 at:

https://tools.ietf.org/rfcdiff?url2=draft-hinden-6man-rfc4291bis-04.txt

Please review this draft to verify that the changes are appropriate.

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

Thanks,
Bob

A new version of I-D, draft-hinden-6man-rfc4291bis-04.txt
has been successfully submitted by Robert M. Hinden and posted to the
IETF repository.
Name: draft-hinden-6man-rfc4291bis
Revision: 04
Title: IP Version 6 Addressing Architecture
Document date: 2015-10-15
Group: Individual Submission
Pages: 28
URL: https://www.ietf.org/internet-drafts/draft-hinden-6man-rfc4291bis-04.txt
Status: https://datatracker.ietf.org/doc/draft-hinden-6man-rfc4291bis/
Htmlized: https://tools.ietf.org/html/draft-hinden-6man-rfc4291bis-04
Diff: https://www.ietf.org/rfcdiff?url2=draft-hinden-6man-rfc4291bis-04
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".

Bob Hinden

2015-10-16 21:12:06 UTC

Hi,

I published the -05 version of the RFC4291bis "IP Version 6 Addressing Architectureâ draft. See links below.

This version is to incorporate the updates made by RFC7346. The change was to add Realm-Local scope to the multicast scope table in Section 2.6, and add the updating text to the same section.

You can see the diff from the previous rfc4291bis draft at:

https://tools.ietf.org/rfcdiff?url2=draft-hinden-6man-rfc4291bis-05.txt

Please review this draft to verify that the changes are appropriate.

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

Thanks,

Bob

A new version of I-D, draft-hinden-6man-rfc4291bis-05.txt
has been successfully submitted by Robert M. Hinden and posted to the
IETF repository.
Name: draft-hinden-6man-rfc4291bis
Revision: 05
Title: IP Version 6 Addressing Architecture
Document date: 2015-10-16
Group: Individual Submission
Pages: 29
URL: https://www.ietf.org/internet-drafts/draft-hinden-6man-rfc4291bis-05.txt
Status: https://datatracker.ietf.org/doc/draft-hinden-6man-rfc4291bis/
Htmlized: https://tools.ietf.org/html/draft-hinden-6man-rfc4291bis-05
Diff: https://www.ietf.org/rfcdiff?url2=draft-hinden-6man-rfc4291bis-05
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".

Ralph Droms

2015-10-16 21:24:29 UTC

Bob - the updates look fine to me.

- Ralph (author of RFC 7346)

Post by Bob Hinden
Hi,
I published the -05 version of the RFC4291bis "IP Version 6 Addressing Architectureâ draft. See links below.
This version is to incorporate the updates made by RFC7346. The change was to add Realm-Local scope to the multicast scope table in Section 2.6, and add the updating text to the same section.
https://tools.ietf.org/rfcdiff?url2=draft-hinden-6man-rfc4291bis-05.txt
Please review this draft to verify that the changes are appropriate.
This is part of the project to move the core IPv6 specifications to Internet Standard.
Thanks,
Bob

--------------------------------------------------------------------
IETF IPv6 working group mailing list
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Bob Hinden

2015-10-16 21:40:03 UTC

Ralph,

Thanks!

Bob

Post by Ralph Droms
Bob - the updates look fine to me.
- Ralph (author of RFC 7346)

Bob Hinden

2015-10-19 18:23:10 UTC

Hi,

I published the -06 version of the RFC4291bis "IP Version 6 Addressing Architectureâ draft. See links below.

This version is to incorporate the updates made by RFC7371. The changes were to the flag bits and their definitions in Section 2.6.

You can see the diff from the previous rfc4291bis draft at:

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

Please review this draft to verify that the changes are appropriate. RFC7371 is relatively new and there may not be any implementations. We will discuss this in Yokohama.

With this draft, all of the updating RFC have been incorporated. This rfc4291bis work will be discussed in Yokohama.

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

Thanks,

Bob

A new version of I-D, draft-hinden-6man-rfc4291bis-06.txt
has been successfully submitted by Robert M. Hinden and posted to the
IETF repository.
Name: draft-hinden-6man-rfc4291bis
Revision: 06
Title: IP Version 6 Addressing Architecture
Document date: 2015-10-19
Group: Individual Submission
Pages: 29
URL: https://www.ietf.org/internet-drafts/draft-hinden-6man-rfc4291bis-06.txt
Status: https://datatracker.ietf.org/doc/draft-hinden-6man-rfc4291bis/
Htmlized: https://tools.ietf.org/html/draft-hinden-6man-rfc4291bis-06
Diff: https://www.ietf.org/rfcdiff?url2=draft-hinden-6man-rfc4291bis-06
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".

Bob Hinden

2015-12-16 14:15:46 UTC

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

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
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".

Brian E Carpenter

2015-12-16 19:23:15 UTC

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

Post by Bob Hinden
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.
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

Bob Hinden

2015-12-17 11:14:45 UTC

Brian,

Post by Brian E Carpenter
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.

I think that makes sense, I will look into doing that. I agree it is consistent with the intent of RFC7136.

Post by Brian E Carpenter
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].

Suggestions? It could be a long list.

Bob

Post by Brian E Carpenter
Regards
Brian

Brian E Carpenter

2015-12-17 19:06:53 UTC

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

...

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

Fernando Gont

2015-12-17 17:02:17 UTC

Post by Brian E Carpenter
Hi Bob,
This is looking good. However, I'm wondering what we should do about
the positioning of Modified EUI-64 format.

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

Post by Brian E Carpenter
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.

I'd say removed.

Thanks,

--
Fernando Gont
SI6 Networks
e-mail: ***@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

Brian E Carpenter

2015-12-17 18:55:44 UTC

Hi Fernando,

Post by Brian E Carpenter
Hi Bob,
This is looking good. However, I'm wondering what we should do about
the positioning of Modified EUI-64 format.

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

I'd say removed.

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

Fernando Gont

2015-12-17 20:31:24 UTC

Hi, Brian,

I'd say removed.

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.

--
Fernando Gont
SI6 Networks
e-mail: ***@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

Brian E Carpenter

2015-12-18 00:20:17 UTC

Hi Fernando,

Post by Fernando Gont
Hi, Brian,

I'd say removed.

Having tha tin RFC4291bis and then saying what the default should be
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.

Post by Fernando Gont
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

Manfredi, Albert E

2015-12-18 00:53:25 UTC

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
***@boeing.com
+1 703-872-4218

-----Original Message-----
From: ipv6 [mailto:ipv6-***@ietf.org] 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,

Post by Fernando Gont
Hi, Brian,

I'd say removed.

Having tha tin RFC4291bis and then saying what the default should be
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.

Post by Fernando Gont
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

Bob Hinden

2015-12-18 06:10:58 UTC

Brian,

Post by Brian E Carpenter
Hi Fernando,

Post by Fernando Gont
Hi, Brian,

I'd say removed.

Having tha tin RFC4291bis and then saying what the default should be
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.

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.

Post by Fernando Gont
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?

I will take a look.

Bob

Post by Brian E Carpenter
Brian
<iid-text.txt>

Brian E Carpenter

2015-12-18 19:01:04 UTC

Post by Brian E Carpenter
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?

" 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.

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

Fernando Gont

2015-12-18 20:29:27 UTC

Hi, Brian,

Post by Brian E Carpenter
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?

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
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.

How does default-iids fit in there?

--
Fernando Gont
SI6 Networks
e-mail: ***@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

Brian E Carpenter

2015-12-18 22:08:51 UTC

Post by Fernando Gont
Hi, Brian,

Post by Brian E Carpenter
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?

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

Brian E Carpenter

2015-12-19 18:58:00 UTC

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

...

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.

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

Mark Smith

2015-12-20 03:26:33 UTC

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.

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.

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?

Post by Brian E Carpenter
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?i

Post by Brian E Carpenter
d=2815678
(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.

Post by Brian E Carpenter
But basically I've come to agree with Fernando. Details of IID generation
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.

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?

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 don't think so, the IPv6 over Ethernet RFC also provides those details.

(I guess this is the last mail I'll write about this subject, affected
network admins will complain outside the IETF)
--------------------------------------------------------------------
IETF IPv6 working group mailing list
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Manfredi, Albert E

2015-12-20 23:31:50 UTC

Post by Manfredi, Albert E
-----Original Message-----
But basically I've come to agree with Fernando. Details of IID generation
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

Bob Hinden

2016-01-16 00:11:17 UTC

I have reviewed this email thread regarding the IID text. I generally agree that we can do better than the current text regarding how IIDs are created. Thanks for the suggestions. I will work on an update along the lines as has been suggested.

However, I am not comfortable removing the "Modified EUI-64â text altogether as part of advancing this spec to Internet Standard, I think it better move it to an appendix. This document will obsolete RFC4291 and we do have running code that uses the âModified EUI-64â IIDs.

I hope to have some new text for review early next week.

Thanks,
Bob

Fernando Gont

2016-01-16 09:57:39 UTC

Hi, Bob,

Post by Bob Hinden
I have reviewed this email thread regarding the IID text. I
generally agree that we can do better than the current text regarding
how IIDs are created. Thanks for the suggestions. I will work on an
update along the lines as has been suggested.
However, I am not comfortable removing the "Modified EUI-64” text
altogether as part of advancing this spec to Internet Standard, I
think it better move it to an appendix. This document will obsolete
RFC4291 and we do have running code that uses the “Modified EUI-64”
IIDs.

I think that it's acceptable to leave text regarding Modified EUI-64 in
an appendix. However, the main body should refer to default-iids
regarding the details of how IIDs are generated.

Thanks!

Cheers,

--
Fernando Gont
SI6 Networks
e-mail: ***@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

Bob Hinden

2016-01-22 05:17:03 UTC

Hi,

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

This is based on the discussion on the mailing list. The changes in this version to revise Section 2.4.1 on Interface Identifiers to reflect current approach, this included saying Modified EUI-64 identifiers are not recommended and moved the text describing the format to Appendix A. There were a few editorial changes as well.

A diff from the previous version is available at:

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

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

Thanks,
Bob

A new version of I-D, draft-ietf-6man-rfc4291bis-01.txt
has been successfully submitted by Robert M. Hinden and posted to the
IETF repository.
Name: draft-ietf-6man-rfc4291bis
Revision: 01
Title: IP Version 6 Addressing Architecture
Document date: 2016-01-21
Group: 6man
Pages: 30
URL: https://www.ietf.org/internet-drafts/draft-ietf-6man-rfc4291bis-01.txt
Status: https://datatracker.ietf.org/doc/draft-ietf-6man-rfc4291bis/
Htmlized: https://tools.ietf.org/html/draft-ietf-6man-rfc4291bis-01
Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-rfc4291bis-01
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".

Bob Hinden

2016-04-27 19:16:20 UTC

Hi,

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

The change in this version is:

Remove changes made by RFC7371 because there isn't any known
implementation experience.

A diff from the previous version is available at:

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

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

Thanks,
Bob

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 Maintenance of the IETF.
Title : IP Version 6 Addressing Architecture
Authors : Robert M. Hinden
Stephen E. Deering
Filename : draft-ietf-6man-rfc4291bis-02.txt
Pages : 30
Date : 2016-04-27
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".
https://datatracker.ietf.org/doc/draft-ietf-6man-rfc4291bis/
https://tools.ietf.org/html/draft-ietf-6man-rfc4291bis-02
https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-rfc4291bis-02

Brian E Carpenter

2016-04-27 20:03:12 UTC

Post by Bob Hinden
Hi,
I published the third 6man w.g. version (-02) of the RFC4291bis draft. See links below.
Remove changes made by RFC7371 because there isn't any known
implementation experience.

That seems to be correct, but it will leave Proposed Standard RFC7371 in
a rather strange state after 4291bis is published. It (RFC7371) will be listed
as updating an RFC which is itself obsoleted by an RFC that effectively
overrides RFC7371 without saying so.

I have no opinion about the value of RFC7371, but this situation makes
my head hurt slightly.

7371--updates-->4291
^ ^
| |
overrides obsoletes
\ /
\--4291bis--/

Brian

Bob Hinden

2016-04-27 21:19:08 UTC

Brian,

There is the note in the Appendix change log. I suppose as part of the advancement package we would make RFC7371 historic.

Bob

Post by Brian E Carpenter
I have no opinion about the value of RFC7371, but this situation makes
my head hurt slightly.
7371--updates-->4291
^ ^
| |
overrides obsoletes
\ /
\--4291bis--/
Brian

Bob Hinden

2016-06-28 22:20:50 UTC

Hi,

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

The change in this version is:

Changes the references in Section 2.4.1 that describes the
details of forming IIDs to RFC7217 and RFC7721.

A diff from the previous version is available at:

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

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

Thanks,
Bob

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 Maintenance of the IETF.
Title : IP Version 6 Addressing Architecture
Authors : Robert M. Hinden
Stephen E. Deering
Filename : draft-ietf-6man-rfc4291bis-03.txt
Pages : 30
Date : 2016-06-28
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".
https://datatracker.ietf.org/doc/draft-ietf-6man-rfc4291bis/
https://tools.ietf.org/html/draft-ietf-6man-rfc4291bis-03
https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-rfc4291bis-03
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.
ftp://ftp.ietf.org/internet-drafts/

Bob Hinden

2016-09-13 22:41:05 UTC

Hi,

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

The changes are based on the review by Tim Chown. The changes in this draft are:

Added text and a pointer to the ULA specification in
Section 2.4.7

Removed old IANA Considerations text, this was left from the
baseline text from RFC4291 and should have been removed
earlier.

Editorial changes.

A diff from the previous version is available at:

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

Please review the changes.

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

Thanks,
Bob

A new version of I-D, draft-ietf-6man-rfc4291bis-04.txt
has been successfully submitted by Robert M. Hinden and posted to the
IETF repository.
Name: draft-ietf-6man-rfc4291bis
Revision: 04
Title: IP Version 6 Addressing Architecture
Document date: 2016-09-13
Group: 6man
Pages: 30
URL: https://www.ietf.org/internet-drafts/draft-ietf-6man-rfc4291bis-04.txt
Status: https://datatracker.ietf.org/doc/draft-ietf-6man-rfc4291bis/
Htmlized: https://tools.ietf.org/html/draft-ietf-6man-rfc4291bis-04
Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-rfc4291bis-04
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".
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

Bob Hinden

2016-10-04 23:42:47 UTC

Hi,

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

The changes are based on issues raised on the mailing list. The changes in this draft are:

Expanded Security Considerations Section to discuss privacy
issues related to using stable interface identifiers to
create IPv6 addresses, and reference solutions that mitigate
these issues such as RFC7721, RFC4941, RFC7271.

Added instructions in IANA Considerations to update
references in the IANA registries that currently point to
RFC4291 to point to this document.

Rename Section 2.4.7 to "Other Local Unicast Addresses" and
rewrote the text to point to ULAs and say that Site-Local
addresses were deprecated by RFC3879. The format of Site-
Local was removed.

Added to Section 2.4.1 a reference to RFC7421 regarding the
background on the 64 bit boundary in Interface Identifiers.

Editorial changes.

A diff from the previous version is available at:

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

Please review the changes.

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

Thanks,
Bob

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 Maintenance of the IETF.
Title : IP Version 6 Addressing Architecture
Authors : Robert M. Hinden
Stephen E. Deering
Filename : draft-ietf-6man-rfc4291bis-05.txt
Pages : 32
Date : 2016-10-04
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".
https://datatracker.ietf.org/doc/draft-ietf-6man-rfc4291bis/
https://tools.ietf.org/html/draft-ietf-6man-rfc4291bis-05
https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-rfc4291bis-05

Bob Hinden

2016-11-15 07:02:12 UTC

Hi,

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

The changes changes from the previous version were editorial.

A diff from the previous version is available at:

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

Please review the changes.

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

Thanks,
Bob

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 Maintenance of the IETF.
Title : IP Version 6 Addressing Architecture
Authors : Robert M. Hinden
Stephen E. Deering <>
Filename : draft-ietf-6man-rfc4291bis-06.txt
Pages : 32
Date : 2016-11-14
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".
https://datatracker.ietf.org/doc/draft-ietf-6man-rfc4291bis/
https://tools.ietf.org/html/draft-ietf-6man-rfc4291bis-06
https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-rfc4291bis-06

Bob Hinden

2017-01-31 19:32:15 UTC

Hi,

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

The summary of the changes are:

Added text to Section 2.4 summarizing IPv6 unicast routing and
referencing BCP198, citing RFC6164 as an example of
longer prefixes, and that IIDs are required to be 64 bits
long as described in RFC7421.

Based on review by Brian Haberman added reference to RFC5952
in Section 2.2.3, corrected case errors in Section 2.6.1, and
added a reference to the IANA Multicast address registry in
Section 2.6.1.

Corrected errors in Section 2.2.3 where the examples in 7.
and 8. were reversed.

A diff from the previous version is available at:

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

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

Thanks,
Bob

A new version of I-D, draft-ietf-6man-rfc4291bis-07.txt
has been successfully submitted by Robert M. Hinden and posted to the
IETF repository.
Name: draft-ietf-6man-rfc4291bis
Revision: 07
Title: IP Version 6 Addressing Architecture
Document date: 2017-01-31
Group: 6man
Pages: 33
URL: https://www.ietf.org/internet-drafts/draft-ietf-6man-rfc4291bis-07.txt
Status: https://datatracker.ietf.org/doc/draft-ietf-6man-rfc4291bis/
Htmlized: https://tools.ietf.org/html/draft-ietf-6man-rfc4291bis-07
Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-rfc4291bis-07
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".

Brian E Carpenter

2017-01-31 21:17:51 UTC

Since I was a bit noisy about the previous draft, let me say
that I am quite OK with this one.

Regards
Brian Carpenter

Post by Bob Hinden
Hi,
I published a new 6man w.g. version (-07) of the RFC4291bis draft. See links below.
Added text to Section 2.4 summarizing IPv6 unicast routing and
referencing BCP198, citing RFC6164 as an example of
longer prefixes, and that IIDs are required to be 64 bits
long as described in RFC7421.
Based on review by Brian Haberman added reference to RFC5952
in Section 2.2.3, corrected case errors in Section 2.6.1, and
added a reference to the IANA Multicast address registry in
Section 2.6.1.
Corrected errors in Section 2.2.3 where the examples in 7.
and 8. were reversed.
https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-rfc4291bis-07
This is part of the project to move the core IPv6 specifications to Internet Standard.
Thanks,
Bob

Bob Hinden

2017-06-20 12:14:18 UTC

Hi,

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

The summary of the changes are:

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

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

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

o Editorial changes.

A diff from the previous version is available at:

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

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

Thanks,
Bob

A new version of I-D, draft-ietf-6man-rfc4291bis-08.txt
has been successfully submitted by Robert M. Hinden and posted to the
IETF repository.
Name: draft-ietf-6man-rfc4291bis
Revision: 08
Title: IP Version 6 Addressing Architecture
Document date: 2017-06-20
Group: 6man
Pages: 33
URL: https://www.ietf.org/internet-drafts/draft-ietf-6man-rfc4291bis-08.txt
Status: https://datatracker.ietf.org/doc/draft-ietf-6man-rfc4291bis/
Htmlized: https://tools.ietf.org/html/draft-ietf-6man-rfc4291bis-08
Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-6man-rfc4291bis-08
Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-rfc4291bis-08
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".

David Farmer

2017-06-20 21:34:13 UTC

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

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

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

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

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

When generating an address, Interface Identifiers are required to be

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

when addresses are manually configured, or by exceptions defined in

standards track documents. The rationale for using 64 bit Interface

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

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

inter-router point-to-point links.

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

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

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

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

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

Thanks

David Farmer

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

Post by Bob Hinden
Hi,
I published a new 6man w.g. version (-08) of the RFC4291bis draft. See links below.
o Added Note: to Section 2 that the term "prefix" is used in
different contexts in IPv6: a prefix used by a routing
protocol, a prefix used by a node to determine if another
node is connected to the same link, and a prefix used to
construct the complete address of a node.
o Based on results of IETF last call and extensive w.g. list
discussion, revised text to clarify that 64 bit Interface IDs
are used except when the first three bits of the address are
000, or addresses are manually configured, or when defined by
a standard track document. This text was moved from
Section 2.4 and is now consolidated in Section 2.4.1. Also
removed text in Section 2.4.4 relating to 64 bit Interface
IDs.
o Removed instruction to IANA fix error in Port Number
assignment. IANA fixed the error on 4 March 2017.
o Editorial changes.
https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-rfc4291bis-08
This is part of the project to move the core IPv6 specifications to Internet Standard.
Thanks,
Bob

--
===============================================
David Farmer Email:***@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815>
Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952>
===============================================

Brian E Carpenter

2017-06-21 21:38:04 UTC

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

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

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

Brian

Post by David Farmer
Subnetting (for IPv4) is discussed in a series of RFCs[1], culminating in
the Internet Standard Subnetting Procedure [RFC950]. The closest thing to
a definition for the term subnet comes in the overview for RFC950. Subnets
"are logically visible sub-sections of a single Internet network." However,
it seems clear that the term is equally important to two of the aspects we
are talking about, it is about both address generation and on-link
determination.
If RFC4291bis is going to use the term subnet, it's use should either be
consistent with the meaning in RFC950, or it should be abundantly clear how
the use of the term differs from it's use in RFC950. There should be no
ambiguity, unless clearly stated otherwise, the term subnet means what it
means in RFC950. In fact let's be clear, the reason the term is being used
here is because of the comfort level that comes from the decades of use of
the term as derived from it's RFC950 meaning.
Because the current use of the term "subnet" in RFC4291bis-08 doesn't seem
to distinguish between address generation and on-link determination, there
still seems to be an implication that a subnet must be /64, or 64 bits, for
both address generation and on-link determination.
One possible way to break this improper implication, would be to qualify
the statement that Interface Identifiers are 64 bits long to address
generation and add to the note that for on-link determination prefixes and
IIDs can be any length. How about something like this;
When generating an address, Interface Identifiers are required to be
64 bits long except if the first three bits of the address are 000,
when addresses are manually configured, or by exceptions defined in
standards track documents. The rationale for using 64 bit Interface
Identifiers can be found in [RFC7421
<https://tools.ietf.org/html/rfc7421>]. An example of a standards
track exception is [RFC6164 <https://tools.ietf.org/html/rfc6164>]
that standardizes 127 bit prefixes on
inter-router point-to-point links.
Note: In the case of on-link determination and as a result when
a prefix length is provide with a manually configured address, the
Prefix and Interface Identifier can be any length as long as they
add up to 128, but are recommended to be 64 bits.
Also, based on the definition of subnet, in section 2.4.4 it seems critical
that m>=1. If it is not and m=0, then we can't be talking about /64
subnets, we are talking about a /64 network. Therefore, "m" must be
greater than or equal to 1, for you to even be properly talking about the
term subnet in IPv6 addressing. Besides adding that point to this section,
a reference to RFC6177 seems appropriate too.
Thanks
David Farmer
[1] RFC917, RFC925, RFC932, RFC936, RFC940
https://tools.ietf.org/html/rfc917
https://tools.ietf.org/html/rfc925
https://tools.ietf.org/html/rfc932
https://tools.ietf.org/html/rfc936
https://tools.ietf.org/html/rfc940
https://tools.ietf.org/html/rfc950

神明達哉

2017-06-27 21:39:24 UTC

At Thu, 22 Jun 2017 09:38:04 +1200,

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

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

--
JINMEI, Tatuya

Brian E Carpenter

2017-06-28 01:02:48 UTC

Post by ç¥æéå
At Thu, 22 Jun 2017 09:38:04 +1200,

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

What do you mean by this? Do you mean "SLAAC has always assumed the
prefix length for address generation and the prefix length for on-link
determination are equal"?

Yes.

Post by ç¥æéå
Specifically which text of RFC4862 says
that (or are you referring to other RFCs for SLAAC)?

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

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

Brian

David Farmer

2017-06-28 16:41:44 UTC

On Tue, Jun 27, 2017 at 8:02 PM, Brian E Carpenter <

Post by ç¥æéå
At Thu, 22 Jun 2017 09:38:04 +1200,

Post by David Farmer
I think this is getting really close. However, there still seems to

be an

Post by ç¥æéå

Post by David Farmer
implication that a subnet must be /64 or 64 bits for both address
generation and on-link determination.

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

What do you mean by this? Do you mean "SLAAC has always assumed the
prefix length for address generation and the prefix length for on-link
determination are equal"?

Yes.

Post by ç¥æéå
Specifically which text of RFC4862 says
that (or are you referring to other RFCs for SLAAC)?

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

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

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

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

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

Post by Brian E Carpenter
...

Post by ç¥æéå
Iâm still further confused now. Are you now saying that LwIP is

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

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

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

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

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

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

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

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

Thanks.

james woodyatt

2017-06-28 17:52:25 UTC

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

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

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

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

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

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

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

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

And just to drive the point home:

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

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

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

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

--james woodyatt <***@google.com>

Manfredi, Albert E

2017-06-28 19:41:15 UTC

-----Original Message-----
From: ipv6 [mailto:ipv6-***@ietf.org] On Behalf Of james woodyatt
Sent: Wednesday, June 28, 2017 13:52

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

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

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

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

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

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

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

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

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

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

Post by james woodyatt
that it tries to admit more variability in the length of interface
identifiers without clarifying how the uniqueness properties of
respected on links where varying interface identifier lengths are in
use.

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

Bert

james woodyatt

2017-06-28 21:04:16 UTC

Post by Manfredi, Albert E
-----Original Message-----
Sent: Wednesday, June 28, 2017 13:52

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

I donât see why not. The IID has to be "unique within a subnet prefix," quoted directly from section 2.5.1. (Same as for IPv4.)
"Note that the uniqueness of interface identifiers is independent of the uniqueness of IPv6 addresses."
Doesn't matter. That was in a different context. If you go on the notion that EUI-64 embeds a MAC address, presumably it becomes a unique IID, and presumably, with SLAAC, you don't have to worry about collisions. There is no other rationale for global uniqueness of IIDs.

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

Post by Manfredi, Albert E

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

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

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

--james woodyatt <***@google.com <mailto:***@google.com>>

Manfredi, Albert E

2017-06-28 21:38:27 UTC

we have moved the “Modified EUI-64” format for interface identifiers
into the historical appendix, but changing the uniqueness properties
of interface identifiers is a completely different thing, and it is
neither necessary nor warranted.

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

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

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

that it tries to admit more variability in the length of interface
identifiers without clarifying how the uniqueness properties of
respected

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

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

Bert

David Farmer

2017-06-28 20:41:42 UTC

The first node will have an interface will have a link-local address of

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

[âŠ]

To define a /112 subnet prefix means the IID must be only 16 bits long.
Thatâs not valid under RFC 4291.
Specifically, when the DHCPv6 server generates the IID for the addresses
that it provides to hosts in IA_NA or IA_TA configuration options, those
addresses do not have /112 subnet prefixes and 16 bit IIDs. They have /64
subnet prefixes and 64 bit IIDS.

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

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

"They are REQUIRED to be unique within a subnet prefix.â
"It is RECOMMENDED that the same interface identifier not be assigned to
different nodes on a link."
"They MAY also be unique over a broader scope."
"Note that the uniqueness of interface identifiers is independent of the
uniqueness of IPv6 addresses."
"Note that the uniqueness of interface identifiers is independent of the
uniqueness of IPv6 addresses."
"Note that the uniqueness of interface identifiers is independent of the
uniqueness of IPv6 addresses.â

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

There is no easy and straightforward way to break the /64 subnet prefix
the language defining the uniqueness properties of interface identifiers
independent of the uniqueness properties of IPv6 addresses. We should not
be entertaining any discussion of doing that in the context of
tries to admit more variability in the length of interface identifiers
without clarifying how the uniqueness properties of interface identifiers
interface identifier lengths are in use.
you insist on trying to do this in another draft, then provide sufficient
clarity about the uniqueness properties of interface identifiers on links
where their length is variable and subject to dynamic operational
configuration.

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

Thanks.

--
===============================================
David Farmer Email:***@umn.edu
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
===============================================

David Farmer

2017-06-28 21:37:02 UTC

Post by David Farmer

The first node will have an interface will have a link-local address of

[âŠ]

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

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

This information must be provided by the RA.

Post by David Farmer
The first two paragraphs of RFC 4291 Â§2.5.1 are clear about the

requirements for the uniqueness properties of IIDs, and these must be
respected by SLAAC, DHCPv6 and any other address configuration mechanism.

Interface identifiers in IPv6 unicast addresses are used to identify
interfaces on a link. They are required to be unique within a

subnet

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

There is no easy and straightforward way to break the /64 subnet prefix
the language defining the uniqueness properties of interface identifiers
independent of the uniqueness properties of IPv6 addresses. We should not
be entertaining any discussion of doing that in the context of
tries to admit more variability in the length of interface identifiers
without clarifying how the uniqueness properties of interface identifiers
interface identifier lengths are in use.
if you insist on trying to do this in another draft, then provide
sufficient clarity about the uniqueness properties of interface identifiers
on links where their length is variable and subject to dynamic operational
configuration.

You seem to be calming the uniqueness properties are not met, could I ask
where you see a problem, because I don't see one.
Thanks.
--
===============================================
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815>
Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952>
===============================================

--
===============================================
David Farmer Email:***@umn.edu
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
===============================================

james woodyatt

2017-06-28 22:25:11 UTC

Post by james woodyatt

To define a /112 subnet prefix means the IID must be only 16 bits long. That’s not valid under RFC 4291.
Specifically, when the DHCPv6 server generates the IID for the addresses that it provides to hosts in IA_NA or IA_TA configuration options, those addresses do not have /112 subnet prefixes and 16 bit IIDs. They have /64 subnet prefixes and 64 bit IIDS.
DHCPv6 only provides a 128bit address it doesn't provide any subnet or IID information at all.
Please explain how those uniqueness requirements are not met in this situation I described? And if they are not meet for DHCPv6 in the situation I described they are not meet for manual configuration either.

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

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

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

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

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

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

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

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

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

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

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

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

Here, Alfa has two addresses with the same IID:

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

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

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

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

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

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

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

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

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

--james woodyatt <***@google.com>

DY Kim

2017-06-28 23:26:10 UTC

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

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

james woodyatt

2017-06-28 23:44:32 UTC

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

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

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

--james woodyatt <***@google.com <mailto:***@google.com>>

DY Kim

2017-06-29 00:14:27 UTC

Hi James,

[Quote]

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

[QED}

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

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

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

David Farmer

2017-06-29 07:02:36 UTC

Post by james woodyatt
In the concrete case, above, both Alfa and Bravo have the same IID=1 in
their global IPv6 addresses if the subnet prefix is /112 in both cases, and
therefore the recommended uniqueness property in
The two IDs (1) are within different /112 subnet prefixes (2001:db8::1 vs 2001:db8::2).So
each is unique within each subnet prefix. Iâd think this configuration is
"They are required to be unique within a subnet prefix.â
But they do not meet the recommendation that the same IID not be assigned
to different nodes on the same link. With long interface identifiers
generated by pseudo-random or random number generators, the recommended
uniqueness property is achieved by statistical uniqueness. If short
interface identifiers are admissible, then some other mechanism must be
recommended for achieving uniqueness. There is neither any such recommended
Thatâs my point.
Fix that, and youâve addressed my concern. Not sure how you can address it though...

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

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

--
===============================================
David Farmer Email:***@umn.edu
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
===============================================

james woodyatt

2017-06-29 17:45:42 UTC

I disagree. There is a serious problem.

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

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

--james woodyatt <***@google.com <mailto:***@google.com>>

David Farmer

2017-06-29 18:59:35 UTC

Post by David Farmer
Yes, you can derive situations with /112 prefixes that don't meet that
recommendation, but I can derive ones that do meet the recommendation. That
simply means ones set of situation are recommended and the others are not.
This would only truly be a problem if it were impossible to meet the
recommendation with a /112 prefix.
I disagree. There is a serious problem.
All the currently standard and best current practice methods of generating
IPv6 interface addresses meet the recommendation provided you accept that
statistical uniqueness is a adequate for the purpose. Changing the /64
subnet prefix length from a constant to a dynamic operational configuration
parameter removes that condition, and thatâs what makes this change
Internet Standard. Either drop the recommendation in another draft that
a method of meeting it with short interface identifiers that doesnât rely
on statistical uniqueness.
I think I have now restated this argument in sufficiently different terms
that it should be clear to anyone legitimately confused about my reasoning,
and any further repetition would be combative in my view. So, Iâm done.

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

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

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

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

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

Thanks

Manfredi, Albert E

2017-06-29 19:23:19 UTC

Post by james woodyatt
I disagree. There is a serious problem.
All the currently standard and best current practice methods of generating
IPv6 interface addresses meet the recommendation provided you accept that
statistical uniqueness is a adequate for the purpose.

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

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

Bert

Manfredi, Albert E

2017-06-28 23:53:01 UTC

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

Post by james woodyatt
IID(address=fe80::1 length=64) -> 1
IID(address=2001:db8::1:1 length=112) -> 1
identifier may be used on multiple interfaces on a single node,
as long as they are attached to different subnets."

Okay. Just like IPv4.

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

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

This is the quote:

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

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

Bert

Manfredi, Albert E

2017-06-29 00:02:58 UTC

This is the quote from RFC 4291:

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

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

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

Bert

Alexandre Petrescu

2017-06-29 17:41:50 UTC

Post by james woodyatt
To define a /112 subnet prefix means the IID must be only 16 bits long. Tha

ts not valid under RFC 4291.

Post by james woodyatt
Specifically, when the DHCPv6 server generates the IID for the addresses th

at it provides to hosts in IA_NA or IA_TA configuration options, those addres
ses do not have /112 subnet prefixes and 16 bit IIDs. They have /64 subnet pr
efixes and 64 bit IIDS.

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

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

So I'd like to propose that we kill any connection between IA_NA and /64 from
all relevant documents.

I agree.

Alex

Keeping this will only create confusion and lead to
implementations that mistakenly derive (or restrict) prefix lengths related
to addresses configured this way. The same applies to manually configured
addresses.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Alexandre Petrescu

2017-06-29 06:40:20 UTC

Post by David Farmer
On Tue, Jun 27, 2017 at 8:02 PM, Brian E Carpenter

At Thu, 22 Jun 2017 09:38:04 +1200, Brian E Carpenter

Post by David Farmer
I think this is getting really close. However, there still

seems to be an

Post by David Farmer
implication that a subnet must be /64 or 64 bits for both
address generation and on-link determination.

Yes, that's what it says, except for documented exceptions. As

far as I

Post by Brian E Carpenter
understand the motivation of my co-authors on draft-bourbaki,

their main

Post by Brian E Carpenter
objection to the previous rfc4291bis was that it didn't allow

for those

Post by Brian E Carpenter
documented exceptions.
Since SLAAC has always assumed that the two lengths are equal,

What do you mean by this? Do you mean "SLAAC has always assumed
the prefix length for address generation and the prefix length for

on-link

determination are equal"?

Yes.

Specifically which text of RFC4862 says that (or are you referring
to other RFCs for SLAAC)?

It doesn't say that. But on a normal broadcast LAN nothing else makes
much sense, so I believe that users have always made this assumption,
regardless of what implementations might support.
I would agree the normal use of SLAAC is with "64 bits for both
address generation and on-link determination." For normal (common,
default, etc...) use that is fine, you will have a PIO for /64 with
both A and L flags set, and is as it probably should be most of the
time. Further, for link-local address generation and on-link
determination 64 bits is always the case, all valid link-local
address are always on-link by definition.
However, the protocol itself doesn't require use of 64 bits for
on-link determination for GUA regardless of how the address is
generated and I think this is the root of the disagreement here. In
reality if it is made clear on-link determination may normally be
based on a /64, but is not required to be /64, then manual
configuration of an address with an on-link prefix of anything
between 0 and 128 isn't actually an exception, it is simply a
consequence of how the protocol actually is intended to work, and the
same goes of DHCP with an on-link RA other than /64.
Now in my option, with the exception of point-to-point links, on-link
determination based on /64 prefix is RECOMMENDED.
On 28/06/2017 10:12, james woodyatt wrote: ...

I’m still further confused now. Are you now saying that LwIP is

correctly interpreting RFC 4291 by assuming the two lengths must be
equal and rejecting advertisements containing a different on-link
prefix length than is the standard address configuration prefix
length for the link type?
No, because RFC 4291 doesn't say that: it simply states the IID
length. So you're describing an implementation choice, which very
possibly doesn't conform to RFC 4862.
And subnet prefix is tangled up in the definition of IID and it's
length, which without something saying otherwise from the definition
and use of subnet in IPv4 it is perfectly reasonable to make such an
assumption. Therefore we need to fix this misconception in
RFC4291bis.
I believe the way to clear this up is to say "a 64 bit IID is
REQUIRED for address generation, and /64 prefix is RECOMMENDED for
on-link determination."
For the sake of discussion, lets say I have pair of nodes connected
with an ethernet, I manually configure one with 2001:db8::1:1/112 and
the other with 2001:db8::1:2/112.
The first node will have an interface will have a link-local address
of FE80::/64 with a random 64 bit IID, and a GUA with a subnet prefix
of 2001:db8::1/112 and a 16bit IID of 1. The second node will have
an interface will have a link-local address of FE80::/64 with a
random 64 IID, and a GUA with a subnet prefix of 2001:db8::1/112 and
a 16bit IID of 2.
Now I add a router, and manually configure the address as
2001:db8::1:3/112, it will generate a link-local address of FE80::/64
probably with an EUI-64 as the IID, and a GUA with a subnet prefix
of 2001:db8::1/112 and a 16bit IID of 3, the router will generate a
RA with a PIO of 2001:db8::1/112 with L=1 and A=0, if A=1 this would
be an invalid PIO. Further, I could tell the router to set M=1 in
the RA, and configure a DHCPv6 server on the router to respond with
addresses 2001:db8::1:4 through 2001:db8::1:ffff.
Now, I can attach an additional node and if able it will receive and
address via DHCPv6 and for this discussion lets say it receives
2001:db8::1:4, and from the RA it gets the on-link prefix of
2001:db8::1/112.
Lets be clear, this is not a recommended configuration, however it is
nevertheless a valid configuration, it doesn't violate protocol. And
I believe this is constant with saying "a 64 bit IID is REQUIRED for
address generation, and /64 prefix is RECOMMENDED for on-link
determination."

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

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

Hmm...

Alex

Post by David Farmer
Thanks.
-- =============================================== David Farmer
Telecommunication Services Office of Information Technology
612-626-0815 <tel:(612)%20626-0815> Minneapolis, MN 55414-3029
Cell: 612-812-9952 <tel:(612)%20812-9952>
===============================================
--------------------------------------------------------------------
Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

神明達哉

2017-06-28 21:19:11 UTC

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

Post by ç¥æéå

Post by Brian E Carpenter
Since SLAAC has always assumed that the two lengths are equal,

What do you mean by this? Do you mean "SLAAC has always assumed the
prefix length for address generation and the prefix length for on-link
determination are equal"?

Yes.

Post by ç¥æéå
Specifically which text of RFC4862 says
that (or are you referring to other RFCs for SLAAC)?

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

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

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

--
JINMEI, Tatuya

james woodyatt

2017-06-27 22:12:29 UTC

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

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

--james woodyatt <***@google.com <mailto:***@google.com>>

james woodyatt

2017-06-21 22:04:37 UTC

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

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

--james woodyatt <***@google.com <mailto:***@google.com>>

Bob Hinden

2017-07-03 17:36:06 UTC

Hi,

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

The summary of the changes are:

o Added text to the last paragraph in Section 2.1 to clarify
the differences on how subnets are hangled in IPv4 and IPv6,
includes a reference to RFC5942 "The IPv6 Subnet Model: The
Relationship between Links and Subnet Prefixes".

o Removed short paragraph about manual configuration in
Section 2.4.1 that was added in the -08 version.

o Revised "Changes since RFC4291" Section to have a summary of
changes since RFC4291 and a separate subsection with a change
history of each Internet Draft. This subsection will be
removed when the RFC is published.

o Editorial changes.

A diff from the previous version is available at:

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

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

Thanks,
Bob

A new version of I-D, draft-ietf-6man-rfc4291bis-09.txt
has been successfully submitted by Robert M. Hinden and posted to the
IETF repository.
Name: draft-ietf-6man-rfc4291bis
Revision: 09
Title: IP Version 6 Addressing Architecture
Document date: 2017-07-03
Group: 6man
Pages: 35
URL: https://www.ietf.org/internet-drafts/draft-ietf-6man-rfc4291bis-09.txt
Status: https://datatracker.ietf.org/doc/draft-ietf-6man-rfc4291bis/
Htmlized: https://tools.ietf.org/html/draft-ietf-6man-rfc4291bis-09
Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-6man-rfc4291bis-09
Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-rfc4291bis-09
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".

David Farmer

2017-07-03 20:22:24 UTC

I was thinking about suggesting a reference to RFC5942 "The IPv6 Subnet
Model", but I wasn't sure where to put it, I really like were you put it.

However, I still think the following paragraph is still too easily
misunderstood to imply subnets must be /64 or 64 bits for both address
generation and on-link determination.

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

[RFC7421]. An example of a standards track exception is [RFC6164]
that standardises 127 bit prefixes on inter-router point-to-point
links.

How about a note clarifying the intent of the this paragraph, something
like this;

Note: While the previous paragraph does imply 64 bit subnet prefixes
are typically assigned to most links. It does not imply anything
about what portion, if any, of a subnet is considered to be on-link,
see Section 2.1 for more discussion. However, Router Advertisements
[RFC4861] specifying 64 bit on-link prefixes are typically
configured on most links.

Thanks

Bob Hinden

2017-07-05 20:34:32 UTC

Hi David,

Post by Bob Hinden
Hi,
I published a new 6man w.g. version (-09) of the RFC4291bis draft. See links below.
o Added text to the last paragraph in Section 2.1 to clarify
the differences on how subnets are hangled in IPv4 and IPv6,
includes a reference to RFC5942 "The IPv6 Subnet Model: The
Relationship between Links and Subnet Prefixes".
I was thinking about suggesting a reference to RFC5942 "The IPv6 Subnet Model", but I wasn't sure where to put it, I really like were you put it.

Good, thanks.

Post by Bob Hinden
However, I still think the following paragraph is still too easily misunderstood to imply subnets must be /64 or 64 bits for both address generation and on-link determination.
Interface Identifiers are 64 bit long except if the first three bits
of the address are 000, or when the addresses are manually
configured, or by exceptions defined in standards track documents.
The rationale for using 64 bit Interface Identifiers can be found in
[RFC7421]. An example of a standards track exception is [RFC6164]
that standardises 127 bit prefixes on inter-router point-to-point
links.
How about a note clarifying the intent of the this paragraph, something like this;
Note: While the previous paragraph does imply 64 bit subnet prefixes
are typically assigned to most links. It does not imply anything
about what portion, if any, of a subnet is considered to be on-link,
see Section 2.1 for more discussion. However, Router Advertisements
[RFC4861] specifying 64 bit on-link prefixes are typically
configured on most links.

Now that the text you refer to is in Section 2.4.1. "Interface Identifiersâ, it is about Interface Identifiers, very little is said about prefixes (except that IIDs are required to be unique on a prefix, but even that is about IIDs). I donât think it is implying anything one way or about on-link properties. I think that is covered pretty well in the new paragraph in Section 2.1 "Addressing Modelâ that includes the link to RFC5942.

Thanks,
Bob

Post by Bob Hinden
Thanks
--
===============================================
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
===============================================

David Farmer

2017-07-06 06:40:42 UTC

Post by Bob Hinden
Hi David,

Post by David Farmer
However, I still think the following paragraph is still too easily

misunderstood to imply subnets must be /64 or 64 bits for both address
generation and on-link determination.

Post by David Farmer
Interface Identifiers are 64 bit long except if the first three bits
of the address are 000, or when the addresses are manually
configured, or by exceptions defined in standards track documents.
The rationale for using 64 bit Interface Identifiers can be found in
[RFC7421]. An example of a standards track exception is [RFC6164]
that standardises 127 bit prefixes on inter-router point-to-point
links.
How about a note clarifying the intent of the this paragraph, something

like this;

Post by David Farmer
Note: While the previous paragraph does imply 64 bit subnet

prefixes

Post by David Farmer
are typically assigned to most links. It does not imply anything
about what portion, if any, of a subnet is considered to be

on-link,

Post by David Farmer
see Section 2.1 for more discussion. However, Router Advertisements
[RFC4861] specifying 64 bit on-link prefixes are typically
configured on most links.

Now that the text you refer to is in Section 2.4.1. "Interface
Identifiersâ, it is about Interface Identifiers, very little is said about
prefixes (except that IIDs are required to be unique on a prefix, but even
that is about IIDs). I donât think it is implying anything one way or
about on-link properties. I think that is covered pretty well in the new
paragraph in Section 2.1 "Addressing Modelâ that includes the link to
RFC5942.

As long as the others that who were insisting that the statement "IIDs MUST
be 64" means that subnets must be 64 bits for both address generation and
on-link determination are satisfied that this is not the case for on-link
determination based on what has been added to section 2.1, then I could
live without this.

However, I like the idea of having some kind of recommendation for the
on-link prefix. I don't think there is guidance anywhere else as to what
the on-link prefix should normally be, at least explicitly, and the
addressing architecture seems like as good of a place as any to recommend
something in this regard.

Instead of directly recommending 64 bits, maybe in section 2.1 recommend
that in most cases on-link prefixes are configured the same as the subnet
prefixes they are associated with. Combined this with 64 bit IIDs and
therefore 64 bit subnet prefixes, you get a recommendation for 64 bit
on-link prefixes in most cases.

While IIDs were the primary controversy, there were several other points
raised during the Last Call discussion, is there a plan to revisit any of
these as well?

Thanks.

--
===============================================
David Farmer Email:***@umn.edu
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
===============================================

Brian E Carpenter

2017-07-06 20:43:30 UTC

On 07/07/2017 07:12, Philip Homburg wrote:
...

redefine anycast to be within a single subnet

What does that mean? I can't attach any meaning to those words.

Apart from that, I believe it's way past time to stop wordsmithing this document.
It now seems to to define reality, including the reality that IPv6 routing
is classless.

Brian

David Farmer

2017-07-06 21:22:14 UTC

On Thu, Jul 6, 2017 at 3:43 PM, Brian E Carpenter <

Post by Brian E Carpenter
...

redefine anycast to be within a single subnet

What does that mean? I can't attach any meaning to those words.
Apart from that, I believe it's way past time to stop wordsmithing this document.
It now seems to to define reality, including the reality that IPv6 routing
is classless.

I'm sympathetic to Philip's thesis;

Technically, the text is not wrong, but I really wonder if for somebody
new to IPv6 we should explain the address architecture this way.

But the unfortunate answer is; that is not the purpose of this document.
This document is a specification, not a document meant to teach anyone
about IPv6. In fact in the Introduction the document says this is a
specification, but maybe it would help if it also said what it isn't, that
is an Introduction to IPv6 and maybe even include a reference to the ISOC
IPv6 tutorial.

https://www.internetsociety.org/tutorials/exploring-ipv6/

Put another way, you don't learn to drive by reading the state traffic
ordinances, you read a drivers manual or guide, this document is much more
the state traffic ordinances in this analogy, than it is intended to be a
drivers manual or guide.

Thanks.

Mark Smith

2017-07-07 00:09:46 UTC

Post by David Farmer

Post by Bob Hinden
Hi David,

Post by David Farmer
However, I still think the following paragraph is still too easily
misunderstood to imply subnets must be /64 or 64 bits for both address
generation and on-link determination.
Interface Identifiers are 64 bit long except if the first three bits
of the address are 000, or when the addresses are manually
configured, or by exceptions defined in standards track documents.
The rationale for using 64 bit Interface Identifiers can be found in
[RFC7421]. An example of a standards track exception is [RFC6164]
that standardises 127 bit prefixes on inter-router point-to-point
links.
How about a note clarifying the intent of the this paragraph, something like this;
Note: While the previous paragraph does imply 64 bit subnet prefixes
are typically assigned to most links. It does not imply anything
about what portion, if any, of a subnet is considered to be on-link,
see Section 2.1 for more discussion. However, Router
Advertisements
[RFC4861] specifying 64 bit on-link prefixes are typically
configured on most links.

Now that the text you refer to is in Section 2.4.1. "Interface
Identifiers”, it is about Interface Identifiers, very little is said about
prefixes (except that IIDs are required to be unique on a prefix, but even
that is about IIDs). I don’t think it is implying anything one way or about
on-link properties. I think that is covered pretty well in the new
paragraph in Section 2.1 "Addressing Model” that includes the link to
RFC5942.

I'm confused by this and have been on the occasions it has been
discussed. I also don't understand why it matters and is related to
the on-link property of a subnet prefix.

"2.4. Unicast Addresses" says that IIDs are 128 bits minus the size of
the subnet prefix.

If the subnet prefix is a /64, then the IID is 64 bits; for a /127,
the IID is 1 bit in size. Of course, conversely, a 64 bit IID results
in a 64 bit subnet prefix.

If you're describing some other property of the bits that are not part
of the subnet prefix, and that part isn't 128-subnet prefix size i.e.
the IID, then IID is not the accurate term for it and it needs to be
explained at least here if not in the RFC and given another name.

Post by David Farmer
However, I like the idea of having some kind of recommendation for the
on-link prefix. I don't think there is guidance anywhere else as to what
the on-link prefix should normally be, at least explicitly, and the
addressing architecture seems like as good of a place as any to recommend
something in this regard.

I'm not sure what an "on-link prefix" is in the sense of the above paragraph.

A subnet-prefix is assigned to a link, which is a statement of where
that the set of addresses (or IIDs) that fall within the subnet-prefix
are present within the network topology. It is a statement to the
forwarding domain as to the network location of a set or range of
addresses.

On-link or not for a subnet-prefix is a statement to the hosts
attached to a link whether they are to try to directly reach other
addresses within the subnet-prefix across the link, or whether they're
to use their default router to reach them. A host doesn't have to have
an address from within the subnet-prefix for it to consider
destinations within the subnet-prefix reachable directly across the
link.

e.g.

Host address: 2001:db8::1234

RA PIOs host receives : 2001:db8::/64 [on-link], 2001:db8:abcd::/64 [on-link]

With those RA PIOs, the host will attempt to directly send across the
link to destinations 2001:db8::5678 and 2001:db8:abcd::fffe, and will
do so for all addresses within the 2001:db8::/64 and
2001:db8:abcd::/64 subnet-prefixes.

If the host instead had just received

RA PIOs host receives : 2001:db8:abcd::/64 [on-link]

Then it would only try to directly send across the link to
destinations that fall within 2001:db8:abcd::/64. It would not try to
directly send to destinations inside 2001:db8::/64, even though its
2001:db8::1234 address is within that same /64, as, per RFC5942, all
destinations are by default off-link except for Link-Local
destinations.

So to me an "on-link prefix" is a subnet-prefix that hosts will
attempt to send directly to across the link they're attached to,
indicated to the host by RA PIOs, ICMP redirects or manual
configuration on the host (per RFC5942). What you and others are
describing as an "on-link prefix" sounds like something different to
that.

Post by David Farmer
Instead of directly recommending 64 bits, maybe in section 2.1 recommend
that in most cases on-link prefixes are configured the same as the subnet
prefixes they are associated with. Combined this with 64 bit IIDs and
therefore 64 bit subnet prefixes, you get a recommendation for 64 bit
on-link prefixes in most cases.
While IIDs were the primary controversy, there were several other points
raised during the Last Call discussion, is there a plan to revisit any of
these as well?

神明達哉

2017-07-07 17:40:16 UTC

At Fri, 7 Jul 2017 10:09:46 +1000,

Post by David Farmer
As long as the others that who were insisting that the statement "IIDs MUST
be 64" means that subnets must be 64 bits for both address generation and
on-link determination are satisfied that this is not the case for on-link
determination based on what has been added to section 2.1, then I could live
without this.

I'm confused by this and have been on the occasions it has been
discussed. I also don't understand why it matters and is related to
the on-link property of a subnet prefix.

[...]

Post by Mark Smith
So to me an "on-link prefix" is a subnet-prefix that hosts will
attempt to send directly to across the link they're attached to,
indicated to the host by RA PIOs, ICMP redirects or manual
configuration on the host (per RFC5942). What you and others are
describing as an "on-link prefix" sounds like something different to
that.

I can't speak for others, but I believe David's understanding of
"on-link prefix" is consistent with yours. My interpretation of his
comment is that the current (09) text of rfc4291bis could be
misunderstood regarding this point as follows:

A. According to Section 2.4.1. IIDs are 64 bit long (with some exceptions)
B. Based on this, and according to the format of Section 2.4, subnet
prefixes are also 64 bit long (with some exceptions)
C. Some readers might jump to the conclusion from A and B that this
64-bit subnet prefix is used by hosts "to send directly to across
the link they're attached to", i.e., this prefix is used as an
"on-link prefix". Of course, this conclusion is wrong, not least
as clarified in RFC5942.

Some people (probably including you) don't see the possibility of this
misunderstanding, and some others still think the misunderstanding is
possible. Personally, I tend to agree with the latter group of people
- I still feel the current text is not crystal clear and could be
misunderstood by fresh readers. On the other hand I also tend to
agree with Brian in that the wordsmith period of this doc is now over
(and it's more productive to complete this task as long as we can
agree on the high-level content). So I'd rather move on at this
point.

--
JINMEI, Tatuya

Lorenzo Colitti

2017-07-08 05:47:37 UTC

I don't think we should say "by exceptions defined in standards track
documents". Whatever document wants to allow non-64-bit prefixes should
formally update RFC 4291. Anything else will be confusing for implementers.

David Farmer

2017-07-08 15:00:08 UTC

Those are not my words, they were added in version 8 of RFC4291bis. I don't
like it either, but I think we have much different reasons. I think it is
much cleaner to recognize this is a recommendation, then you don't need to
enumerate the exceptions at all.

Thanks.

--
===============================================
David Farmer Email:***@umn.edu
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
===============================================

Brian E Carpenter

2017-07-08 20:35:48 UTC

We're trying to find a compromise between excessive rigidity and excessive
flexibility. I don't see any confusion in the present text: if you've read
4291bis and you come upon a standards track document specifying a value
!=64, you can use it. If you've only read RFC4291, you're out of date.

You can certainly argue that RFC6164 should have formally updated RFC4291.

Brian

Templin, Fred L

2017-07-10 15:52:51 UTC

Hi, something that I think is a bit under-specified is whether the address "fe80::"
should be considered as an Anycast address. In particular, the leftmost 10 bits
are "link-local" and the rightmost 118 bits are all-zero.

Should fe80:: be considered as the subnet router Anycast address for "link-local"?
If so, I think that it could be mentioned somewhere in Section 2.5 that even the
link-local subnet has an Anycast address.

Thanks - Fred

Post by Manfredi, Albert E
-----Original Message-----
Sent: Monday, July 03, 2017 10:36 AM
Subject: <draft-ietf-6man-rfc4291bis-09.txt>
Hi,
I published a new 6man w.g. version (-09) of the RFC4291bis draft. See links below.
o Added text to the last paragraph in Section 2.1 to clarify
the differences on how subnets are hangled in IPv4 and IPv6,
includes a reference to RFC5942 "The IPv6 Subnet Model: The
Relationship between Links and Subnet Prefixes".
o Removed short paragraph about manual configuration in
Section 2.4.1 that was added in the -08 version.
o Revised "Changes since RFC4291" Section to have a summary of
changes since RFC4291 and a separate subsection with a change
history of each Internet Draft. This subsection will be
removed when the RFC is published.
o Editorial changes.
https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-rfc4291bis-09
This is part of the project to move the core IPv6 specifications to Internet Standard.
Thanks,
Bob

Brian E Carpenter

2017-07-10 20:52:10 UTC

Fred,

Post by Templin, Fred L
Hi, something that I think is a bit under-specified is whether the address "fe80::"
should be considered as an Anycast address. In particular, the leftmost 10 bits
are "link-local" and the rightmost 118 bits are all-zero.
Should fe80:: be considered as the subnet router Anycast address for "link-local"?
If so, I think that it could be mentioned somewhere in Section 2.5 that even the
link-local subnet has an Anycast address.

I don't think so. The text in 4291 about the Subnet-Router anycast address says:
'The "subnet prefix" in an anycast address is the prefix that identifies a specific link.'
fe80::/10 does not identify a specific link, since it applies to every link.
Therefore, fe80:: is logically not a subnet-router anycast address.

Brian

Post by Templin, Fred L
Thanks - Fred

Templin, Fred L

2017-07-10 21:53:47 UTC

Hi Brian,

Post by Manfredi, Albert E
-----Original Message-----
Sent: Monday, July 10, 2017 1:52 PM
Subject: Re: <draft-ietf-6man-rfc4291bis-09.txt>
Fred,

'The "subnet prefix" in an anycast address is the prefix that identifies a specific link.'
fe80::/10 does not identify a specific link, since it applies to every link.
Therefore, fe80:: is logically not a subnet-router anycast address.

I am OK with that answer, but if fe80:: is not an anycast address what is it?
For example, is it available for use by a specific link-layer? Is it just an ordinary
unicast address like any other? Is it a reserved address that must never be
used? Is it a nothing?

I am hoping you would say that it is available for use by specific link-layers,
because I would like to use it in that way.

Thanks - Fred

Post by Manfredi, Albert E
Brian

Post by Templin, Fred L
Thanks - Fred

Mark Smith

2017-07-10 23:32:49 UTC

I would disagree. fe80::/64 identifies a specific link - it identifies
the link the host is attached to - "this" link.

fe80::/64 could also be described as an anycast prefix, because it is
assigned to multiple links. Other prefixes can be anycast prefixes
too.

The forwarding system sends to the closest instance of an anycast
prefix, which in the case of fe80::/64 is always on-link, for other
anycast prefixes it may not and usually won't be. The only thinh
special about fe80::/64 in this context is that is automatically
configured on all links, so it is never an off-link anycast fe80::/64
prefix.

I think this text would have to specifically exclude fe80::/64 if
fe80::/128 is not a router-subnet anycast address.

"Packets sent to the Subnet-Router anycast address will be delivered
to one router on the subnet. All routers are required to support the
Subnet-Router anycast addresses for the subnets to which they have
interfaces."

Regards,
Mark.

Post by Brian E Carpenter
Brian

Post by Templin, Fred L
Thanks - Fred

Brian E Carpenter

2017-07-11 01:36:51 UTC

I would disagree. fe80::/64 identifies a specific link - it identifies
the link the host is attached to - "this" link.

fe80::%eth0 specifies an address on an interface.
fe80::%eth1 specifies an address on a different interface.
Which kind of shows that fe80::/64 in the abstract doesn't
specify much of anything. fe80::%eth0/64 is valid syntax
under RFC 4007, however.

Post by Mark Smith
fe80::/64 could also be described as an anycast prefix, because it is
assigned to multiple links. Other prefixes can be anycast prefixes
too.

Well, that's the trouble. fe80::/64 refers to a single interface
if there is only one, but if there's more than one, does it
refer to a default choice of interface, or to all interfaces
simultaneously? I don't think that is discussed anywhere.

Post by Mark Smith
The forwarding system sends to the closest instance of an anycast
prefix, which in the case of fe80::/64 is always on-link, for other
anycast prefixes it may not and usually won't be. The only thinh
special about fe80::/64 in this context is that is automatically
configured on all links, so it is never an off-link anycast fe80::/64
prefix.

So the address fe80:: might, or might not, be reached on all the
interfaces.

Post by Mark Smith
I think this text would have to specifically exclude fe80::/64 if
fe80::/128 is not a router-subnet anycast address.
"Packets sent to the Subnet-Router anycast address will be delivered
to one router on the subnet. All routers are required to support the
Subnet-Router anycast addresses for the subnets to which they have
interfaces."

My FritzBox at home certainly does not answer on fe80::%12, and as far
as I can tell the Juniper switch at the uni does not answer on fe80::%11

Brian

Post by Mark Smith
Regards,
Mark.

Post by Brian E Carpenter
Brian

Post by Templin, Fred L
Thanks - Fred

Mark Smith

2017-07-11 03:49:46 UTC

I would disagree. fe80::/64 identifies a specific link - it identifies
the link the host is attached to - "this" link.

I understood the question was whether there is a subnet-router anycast
address within the link-local prefix, meaning that all routers on a
link would also have a fe80::/128 subnet-router interface address.

Your comments seem to be about selecting an outbound interface using
fe80::/128, although I'm not sure if you're talking about using it is
the source or destination address. fe80::/64 is of course ambiguous,
so zone information needs to be provided in either case.

Post by Mark Smith
fe80::/64 could also be described as an anycast prefix, because it is
assigned to multiple links. Other prefixes can be anycast prefixes
too.

I seem to remember a few years ago somebody posted a draft related to
that. I can't remember the approach they suggested, however I think
there are two, although both have issues - ND for the address out of
all of the host's interface, and use the first response to select the
outgoing interface (multi-homed host), or use just assume the
interface the default router appears on (single-homed host). I don't
think it considered anycast link-local addresses.

An alternative thought I"ve had is to create unique link-local
addresses by using the same method as ULAs, utilising the bits between
fe80::/10 and fe80::/64 for a random number. The first host or router
on a link would pick the random number, announcing the ULL prefix in
RAs that have a zero value router lifetime, so the host isn't used as
a default router. The second host on the link would learn that ULA
prefix and then start announcing it too in RAs (RLife = 0) as a backup
if the first host goes away. I think that is all doable, from memory
the issue I ran into was where to put the ULA in the address selection
rules, before or after the current LL prefix. This is very similar to
how Appletalk had seed routers that seeded other non-configured
routers with the link's cable range information.

So the address fe80:: might, or might not, be reached on all the
interfaces.

My FritzBox at home certainly does not answer on fe80::%12, and as far
as I can tell the Juniper switch at the uni does not answer on fe80::%11

I've had some experiences with FritzBoxes back in 2010, they do some
unusual IPv6 things e.g., they thought that ULA and GUA prefixes were
to be swapped in RAs, rather than being advertised in parallel,
following the state of the WAN link.

My OpenWRT router is answering pings to fe80::.

$ ping6 -c 3 -I wlp3s0 fe80::
PING fe80::(fe80::) from <deleted>%wlp3s0 wlp3s0: 56 data bytes
64 bytes from fe80::<deleted>%wlp3s0: icmp_seq=1 ttl=64 time=4.78 ms
64 bytes from fe80::<deleted>%wlp3s0: icmp_seq=2 ttl=64 time=42.5 ms
64 bytes from fe80::<deleted>%wlp3s0: icmp_seq=3 ttl=64 time=4.46 ms

--- fe80:: ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 4.469/17.273/42.566/17.885 ms
$

I'm also getting a neighbor table entry for it on the sending host.

fe80:: dev wlp3s0 lladdr <deleted> router STALE

I also verified with tcpdump that it is using fe80:: as the ICMP echo
request destination address.

Regards,
Mark.

Templin, Fred L

2017-07-11 16:10:00 UTC

Hi,

Post by Manfredi, Albert E
-----Original Message-----
Sent: Monday, July 10, 2017 8:50 PM
Subject: Re: <draft-ietf-6man-rfc4291bis-09.txt>

I would disagree. fe80::/64 identifies a specific link - it identifies
the link the host is attached to - "this" link.

I understood the question was whether there is a subnet-router anycast
address within the link-local prefix, meaning that all routers on a
link would also have a fe80::/128 subnet-router interface address.
Your comments seem to be about selecting an outbound interface using
fe80::/128, although I'm not sure if you're talking about using it is
the source or destination address. fe80::/64 is of course ambiguous,
so zone information needs to be provided in either case.

Post by Mark Smith
fe80::/64 could also be described as an anycast prefix, because it is
assigned to multiple links. Other prefixes can be anycast prefixes
too.

I seem to remember a few years ago somebody posted a draft related to
that. I can't remember the approach they suggested, however I think
there are two, although both have issues - ND for the address out of
all of the host's interface, and use the first response to select the
outgoing interface (multi-homed host), or use just assume the
interface the default router appears on (single-homed host). I don't
think it considered anycast link-local addresses.
An alternative thought I"ve had is to create unique link-local
addresses by using the same method as ULAs, utilising the bits between
fe80::/10 and fe80::/64 for a random number. The first host or router
on a link would pick the random number, announcing the ULL prefix in
RAs that have a zero value router lifetime, so the host isn't used as
a default router. The second host on the link would learn that ULA
prefix and then start announcing it too in RAs (RLife = 0) as a backup
if the first host goes away. I think that is all doable, from memory
the issue I ran into was where to put the ULA in the address selection
rules, before or after the current LL prefix. This is very similar to
how Appletalk had seed routers that seeded other non-configured
routers with the link's cable range information.

So the address fe80:: might, or might not, be reached on all the
interfaces.

My FritzBox at home certainly does not answer on fe80::%12, and as far
as I can tell the Juniper switch at the uni does not answer on fe80::%11

I've had some experiences with FritzBoxes back in 2010, they do some
unusual IPv6 things e.g., they thought that ULA and GUA prefixes were
to be swapped in RAs, rather than being advertised in parallel,
following the state of the WAN link.
My OpenWRT router is answering pings to fe80::.
PING fe80::(fe80::) from <deleted>%wlp3s0 wlp3s0: 56 data bytes
64 bytes from fe80::<deleted>%wlp3s0: icmp_seq=1 ttl=64 time=4.78 ms
64 bytes from fe80::<deleted>%wlp3s0: icmp_seq=2 ttl=64 time=42.5 ms
64 bytes from fe80::<deleted>%wlp3s0: icmp_seq=3 ttl=64 time=4.46 ms
--- fe80:: ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 4.469/17.273/42.566/17.885 ms
$
I'm also getting a neighbor table entry for it on the sending host.
fe80:: dev wlp3s0 lladdr <deleted> router STALE
I also verified with tcpdump that it is using fe80:: as the ICMP echo
request destination address.

Interesting to hear that that works. I ran into a snag with the KEA DHCPv6
server on Ubuntu 14.04 when I had the client use fe80:: as the IPv6 source
address of its DHCPv6 messages. I can't remember if it was KEA or linux
that didn't like it, but it did not work. Some sort of bogon filter must have
rejected it.

It therefore seems like there is something special about fe80:: and that
different implementations handle it in different ways. Whether fe80::
is a subnet router anycast address, an ordinary unicast address or a
bogus address it seems like the spec should say something about it.

Thanks - Fred

Post by Manfredi, Albert E
Regards,
Mark.

Templin, Fred L

2017-07-11 16:49:35 UTC

Hi again,

Post by Manfredi, Albert E
-----Original Message-----
Sent: Tuesday, July 11, 2017 9:10 AM
Subject: RE: <draft-ietf-6man-rfc4291bis-09.txt>
Hi,

Post by Manfredi, Albert E
-----Original Message-----
Sent: Monday, July 10, 2017 8:50 PM
Subject: Re: <draft-ietf-6man-rfc4291bis-09.txt>

I would disagree. fe80::/64 identifies a specific link - it identifies
the link the host is attached to - "this" link.

I understood the question was whether there is a subnet-router anycast
address within the link-local prefix, meaning that all routers on a
link would also have a fe80::/128 subnet-router interface address.
Your comments seem to be about selecting an outbound interface using
fe80::/128, although I'm not sure if you're talking about using it is
the source or destination address. fe80::/64 is of course ambiguous,
so zone information needs to be provided in either case.

Post by Mark Smith
fe80::/64 could also be described as an anycast prefix, because it is
assigned to multiple links. Other prefixes can be anycast prefixes
too.

I seem to remember a few years ago somebody posted a draft related to
that. I can't remember the approach they suggested, however I think
there are two, although both have issues - ND for the address out of
all of the host's interface, and use the first response to select the
outgoing interface (multi-homed host), or use just assume the
interface the default router appears on (single-homed host). I don't
think it considered anycast link-local addresses.
An alternative thought I"ve had is to create unique link-local
addresses by using the same method as ULAs, utilising the bits between
fe80::/10 and fe80::/64 for a random number. The first host or router
on a link would pick the random number, announcing the ULL prefix in
RAs that have a zero value router lifetime, so the host isn't used as
a default router. The second host on the link would learn that ULA
prefix and then start announcing it too in RAs (RLife = 0) as a backup
if the first host goes away. I think that is all doable, from memory
the issue I ran into was where to put the ULA in the address selection
rules, before or after the current LL prefix. This is very similar to
how Appletalk had seed routers that seeded other non-configured
routers with the link's cable range information.

So the address fe80:: might, or might not, be reached on all the
interfaces.

My FritzBox at home certainly does not answer on fe80::%12, and as far
as I can tell the Juniper switch at the uni does not answer on fe80::%11

I've had some experiences with FritzBoxes back in 2010, they do some
unusual IPv6 things e.g., they thought that ULA and GUA prefixes were
to be swapped in RAs, rather than being advertised in parallel,
following the state of the WAN link.
My OpenWRT router is answering pings to fe80::.
PING fe80::(fe80::) from <deleted>%wlp3s0 wlp3s0: 56 data bytes
64 bytes from fe80::<deleted>%wlp3s0: icmp_seq=1 ttl=64 time=4.78 ms
64 bytes from fe80::<deleted>%wlp3s0: icmp_seq=2 ttl=64 time=42.5 ms
64 bytes from fe80::<deleted>%wlp3s0: icmp_seq=3 ttl=64 time=4.46 ms
--- fe80:: ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 4.469/17.273/42.566/17.885 ms
$
I'm also getting a neighbor table entry for it on the sending host.
fe80:: dev wlp3s0 lladdr <deleted> router STALE
I also verified with tcpdump that it is using fe80:: as the ICMP echo
request destination address.

Interesting to hear that that works. I ran into a snag with the KEA DHCPv6
server on Ubuntu 14.04 when I had the client use fe80:: as the IPv6 source
address of its DHCPv6 messages. I can't remember if it was KEA or linux
that didn't like it, but it did not work. Some sort of bogon filter must have
rejected it.
It therefore seems like there is something special about fe80:: and that
is a subnet router anycast address, an ordinary unicast address or a
bogus address it seems like the spec should say something about it.

I just tried assigning the address fe80::/128 to the eth0 interface of a
first linux host then tried ping6 from a second linux host and the ping6's
succeeded. So, whether it is a plain unicast address or a subnet router
anycast address it looks like linux is not rejecting it as a bogon. So, it
must be KEA that didn't like it.

Thanks - Fred

Post by Manfredi, Albert E
Thanks - Fred

Post by Manfredi, Albert E
Regards,
Mark.

Lorenzo Colitti

2017-07-11 01:24:03 UTC

Post by Bob Hinden
I published a new 6man w.g. version (-09) of the RFC4291bis draft. See links below.

Actually, after lots of thought, I object to this document in its current
form, specifically due to the text "or by exceptions defined in standards
track documents". I feel that this text is a net negative in terms of the
functionality provided by the protocol to its users.

Allowing IIDs shorter than 64 bits has no value that I can see that is not
already covered by the exception for manual configuration. Pretty much the
only thing we can do with it is support SLAAC with shorter IIDs, and
*nobody* has yet answered the question of how that would be beneficial in
the long therm.

In the short term we might tell ourselves that shorter IIDs will allow
users to extend the network at the edges. But the reality is that in the
long term we'll just see some networks provide the minimum allocation that
is accepted by hosts. (There are examples of this today, in the case of
cable networks that only provide a single /64 to the home.) Because hosts
adapt to the lowest-common denominator network, over time the only effect
is to move the commonly-used subnet boundary between subnet prefix and IID
from 64 towards 128. This will be accelerated by networks whose policies
include limiting the number of devices allowed on a particular connection.
(Again, there are examples today: enterprise networks that want one GUA per
host, mobile carriers have a requirement to allow only x devices to tether
behind a smartphone, etc.) I don't think that's a use case.

So, what are the other use cases? If there are no use cases, we should not
make this change.

I understand Brian and David's position that this is just a parameter and
that the architecture is inconsistent, but better an inconsistent network
architecture than a degradation of function.

David Farmer

2017-07-17 21:42:23 UTC

Post by Bob Hinden
I published a new 6man w.g. version (-09) of the RFC4291bis draft. See links below.

Actually, after lots of thought, I object to this document in its current
form, specifically due to the text "or by exceptions defined in standards
track documents". I feel that this text is a net negative in terms of the
functionality provided by the protocol to its users.
Allowing IIDs shorter than 64 bits has no value that I can see that is not
already covered by the exception for manual configuration. Pretty much the
only thing we can do with it is support SLAAC with shorter IIDs, and
*nobody* has yet answered the question of how that would be beneficial in
the long therm.
In the short term we might tell ourselves that shorter IIDs will allow
users to extend the network at the edges. But the reality is that in the
long term we'll just see some networks provide the minimum allocation that
is accepted by hosts. (There are examples of this today, in the case of
cable networks that only provide a single /64 to the home.) Because hosts
adapt to the lowest-common denominator network, over time the only effect
is to move the commonly-used subnet boundary between subnet prefix and IID
from 64 towards 128. This will be accelerated by networks whose policies
include limiting the number of devices allowed on a particular connection.
(Again, there are examples today: enterprise networks that want one GUA per
host, mobile carriers have a requirement to allow only x devices to tether
behind a smartphone, etc.) I don't think that's a use case.
So, what are the other use cases? If there are no use cases, we should not
make this change.
I understand Brian and David's position that this is just a parameter and
that the architecture is inconsistent, but better an inconsistent network
architecture than a degradation of function.

I've begun to think there are two real problems here;

1. RFC4291 categorically says architecturally IIDs are 64bits, and seems
to imply this is the case for all components of IPv6. While it is the case
for several components of IPv6, it is not the case for other important
components. Neighbor Discovery, DHCPv6, and Routing, etc... are not
architecturally based on 64bit IIDs at all, in fact they are clearly based
on IIDs of any length.

2. The fact that some components of IPv6 are architecturally based on 64bit
IIDs doesn't mean that operationally IIDs are always required to be 64
bits. Rather than implying that operationally IID are required to be
64bits, how about simply stating that operationally 64 bit IIDs are
recommended. This eliminates the need to enumerate all the exceptions,
which probably isn't something an architectural document should be doing.

So, I would propose the following for RFC4291bis;

Several components of IPv6 are architecturally based on a requirement that
Interface Identifiers are 64 bit long except if the first three bits of the
address are 000. The rationale for using 64 bit Interface Identifiers can
be found in [RFC7421]. However, other components of IPv6 are
architecturally based
on Interface Identifiers of any length, most importantly Neighbor Discovery
[RFC4861]. Neither of these two architectures override or invalidate the
other. Accordingly, 64 bit Interface Identifiers are recommended for
operational use.

Thanks.

james woodyatt

2017-07-18 08:04:11 UTC

Post by David Farmer
I've begun to think there are two real problems here;
1. RFC4291 categorically says architecturally IIDs are 64bits, and seems to imply this is the case for all components of IPv6. While it is the case for several components of IPv6, it is not the case for other important components. Neighbor Discovery, DHCPv6, and Routing, etc... are not architecturally based on 64bit IIDs at all, in fact they are clearly based on IIDs of any length.

Those other components arenât based on IIDs at all. Theyâre based on IPv6 addresses and routing prefixes, but theyâre not based on IIDs. That RFC 4291 still has this obsolescent concept of an IID that comes from embedding Modified EUI-64 transformations of MAC addresses isnât actually causing any real problem that Iâm seeing stated anywhere. It seems perfectly safe to me to promote to Standard a minor revision of RFC 4291 that retains the existing definition of the IID in the architecture.

Post by David Farmer
2. The fact that some components of IPv6 are architecturally based on 64bit IIDs doesn't mean that operationally IIDs are always required to be 64 bits. Rather than implying that operationally IID are required to be 64bits, how about simply stating that operationally 64 bit IIDs are recommended. This eliminates the need to enumerate all the exceptions, which probably isn't something an architectural document should be doing.

See above.

--james woodyatt <***@google.com <mailto:***@google.com>>

Manfredi, Albert E

2017-07-18 19:19:42 UTC

Post by David Farmer
I've begun to think there are two real problems here;
1. RFC4291 categorically says architecturally IIDs are 64bits,

Actually, a better way to state this, to get past this "required" problem that keeps recurring, is to say that RFC 4291 "categorically states that IIDs must consist of EUI-64 format." Then that should put in perspective this whole issue. Quoting:

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

Besides which, SLAAC RFC 4862 is agnostic in principle, on the length of the IID. Everything becomes a matter of RFC 2464 (IPv6 over Ethernet), which is no better than RFC 4291. It too "categorically mandates" use of EUI-64 as IID.

RFC 4862:

The
length of the interface identifier is defined in a separate link-
type-specific document, which should also be consistent with the
address architecture [RFC4291] (see Section 2).

RFC 2464:

The Interface Identifier [AARCH] for an Ethernet interface is based
on the EUI-64 identifier [EUI64] derived from the interface's built-
in 48-bit IEEE 802 address.

Enfin bref, may I suggest that all of our more recent decisions and considerations have gone well beyond what these outdated RFCs are saying? I think that any notion of "mandated 64-bit IIDs" is a bit like cherry-picking only one phrase of the requirement, and ignoring the other phrase concerning EUI-64.

Those other components aren’t based on IIDs at all. They’re based on
IPv6 addresses and routing prefixes, but they’re not based on IIDs.

Good point. Still, if a prefix is permitted to be 128 bits long, that kind of implies something about IIDs too. Indirectly.

Well, no one wants to say that embedding EUI-64 is a good idea anymore. But the way we have agreed to proceed, with SLAAC retaining a 64-bit boundary, and otherwise keeping the matter flexible, is the right way to go.

Rather than implying that operationally IID are required to be 64bits,
how about simply stating that operationally 64 bit IIDs are recommended.

Amen.

Bert

Brian E Carpenter

2017-07-18 23:15:52 UTC

Those other components aren’t based on IIDs at all. They’re based on IPv6 addresses and routing prefixes, but they’re not based on IIDs.

Hmm. Let's consider a case in which the last-hop route to a given LAN has a prefix of
length, say, /80. What is the name of the bit-string from bits 81 through 127 of the
host address? If they aren't called the "IID" what are they called?

That RFC 4291 still has this obsolescent concept of an IID that comes from embedding Modified EUI-64 transformations of MAC addresses isn’t actually causing any real problem that I’m seeing stated anywhere. It seems perfectly safe to me to promote to Standard a minor revision of RFC 4291 that retains the existing definition of the IID in the architecture.

In what respect does draft-ietf-6man-rfc4291bis-09 fail to be such a minor revision?
I'm unaware of any single place that anyone would need to modify their code
if that text was published as an RFC. That's a major part of the criteria for
Internet Standard.

Brian

james woodyatt

2017-07-19 06:22:50 UTC

Post by Brian E Carpenter
Hmm. Let's consider a case in which the last-hop route to a given LAN has a prefix of
length, say, /80. What is the name of the bit-string from bits 81 through 127 of the
host address? If they aren't called the "IID" what are they called?

If have yet to find where RFC 4291 clearly names the part of an IPv6 address that follows a *routing* prefix apart from a *subnet* prefix. Moreover, the phrase âlast-hop route to a given LANâ is not equivalent to the concept of a subnet, and such a routing prefix is not equivalent to a subnet prefix. As RFC 5942 clarifies.

Post by james woodyatt
That RFC 4291 still has this obsolescent concept of an IID that comes from embedding Modified EUI-64 transformations of MAC addresses isnât actually causing any real problem that Iâm seeing stated anywhere. It seems perfectly safe to me to promote to Standard a minor revision of RFC 4291 that retains the existing definition of the IID in the architecture.

In what respect does draft-ietf-6man-rfc4291bis-09 fail to be such a minor revision?

None. I think it succeeds. Iâm happy with I-D.ietf-6man-rfc4291bis-09, and I think it should be published with a fresh STD number.

Post by Brian E Carpenter
I'm unaware of any single place that anyone would need to modify their code
if that text was published as an RFC. That's a major part of the criteria for
Internet Standard.

Agreed.

--james woodyatt <***@google.com <mailto:***@google.com>>

Brian E Carpenter

2017-07-19 07:57:58 UTC

If have yet to find where RFC 4291 clearly names the part of an IPv6 address that follows a *routing* prefix apart from a *subnet* prefix. Moreover, the phrase “last-hop route to a given LAN” is not equivalent to the concept of a subnet, and such a routing prefix is not equivalent to a subnet prefix. As RFC 5942 clarifies.

Agreed, but I phrased my question in full knowledge of that. What do we call those trailing
bits of the address? (I was reading the source of the Python 'ipaddress' module yesterday,
and saw a comment about 'host bits', but that seems very 20th century, given that the
IPv6 architecture refers to interfaces.)

Brian

In what respect does draft-ietf-6man-rfc4291bis-09 fail to be such a minor revision?

None. I think it succeeds. I’m happy with I-D.ietf-6man-rfc4291bis-09, and I think it should be published with a fresh STD number.

Agreed.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

james woodyatt

2017-07-19 08:12:23 UTC

Post by james woodyatt

Iâve been mentally using âaddress suffixâ for this concept, and I find that I rarely have much need for it. I suppose if I were using on-link prefixes longer than /64, then Iâd need it so I could differentiate between the 64-bit Interface ID and the shorter part of the address that follows the on-link prefix.

--james woodyatt <***@google.com <mailto:***@google.com>>

Lorenzo Colitti

2017-07-19 08:26:37 UTC

Post by james woodyatt
If have yet to find where RFC 4291 clearly names the part of an IPv6
address that follows a *routing* prefix apart from a *subnet* prefix.

There is no name for this concept because it doesn't make sense.

The zero or more on-link prefixes on a link are entirely separate from any
IP addresses the host might have on that link.

Any address the host has on that interface might be covered by zero on-link
prefixes, one on-link prefix, or more than one. Similarly, any on-link
prefix may cover zero or more addresses that the host has on that interface.

David Farmer

2017-07-19 13:44:30 UTC

Sent from my iPhone

Post by james woodyatt
If have yet to find where RFC 4291 clearly names the part of an IPv6 address that follows a *routing* prefix apart from a *subnet* prefix.

There is no name for this concept because it doesn't make sense.
The zero or more on-link prefixes on a link are entirely separate from any IP addresses the host might have on that link.
Any address the host has on that interface might be covered by zero on-link prefixes, one on-link prefix, or more than one. Similarly, any on-link prefix may cover zero or more addresses that the host has on that interface.

If there is truly a distinction in IPv6 between a subnet prefix that is pair with an IID and a routing/on-link prefix, purportedly without an IID, that is an important architectural distinction that needs to be much more clearly explained in RFC4291bis.

In the current text, this point is either way too subtle or missing all together. In fact I believe at least the diagrams in section 2.4, mislead casual readers to the exact opposite conclusion, maybe even some careful readers too. :)

I think it is important to the understanding of the IPv6 Addressing Architecture that this gets clarified prior to moving to Internet Standard, otherwise I suspect there will be continued misunderstanding of this distinction.

David Farmer

Nick Hilliard

2017-07-19 13:51:48 UTC

Post by David Farmer
2. The fact that some components of IPv6 are architecturally based on
64bit IIDs doesn't mean that operationally IIDs are always required to
be 64 bits.

this is certainly implied by the current text in -09.

Post by David Farmer
Rather than implying that operationally IID are required to
be 64bits, how about simply stating that operationally 64 bit IIDs are
recommended. This eliminates the need to enumerate all the exceptions,
which probably isn't something an architectural document should be doing.

This would be a good way of dealing with this issue and you're correct
to state that enumerating exceptions is something that ought to be
avoided in architectural documents.

Nick

Brian E Carpenter

2017-07-20 02:01:35 UTC

Post by Nick Hilliard

Post by David Farmer
2. The fact that some components of IPv6 are architecturally based on
64bit IIDs doesn't mean that operationally IIDs are always required to
be 64 bits.

this is certainly implied by the current text in -09.

This would be a good way of dealing with this issue and you're correct
to state that enumerating exceptions is something that ought to be
avoided in architectural documents.

But what is needed is clarity in definitions, which is why I've been
asking what the low order bits in an IPv6 address are called in cases
where people claim they are not called an IID.

(My answer fwiw is that they are always called an IID, because once
you're on the final link, those bits serve only to deliver the packet
to the intended interface, so they must uniquely identify that
interface.)

Brian

Brian

神明達哉

2017-07-19 23:47:48 UTC