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

From: Bob Hinden <[email-masked]>
Date: Mon, 3 Jul 2017 10:36:06 -0700

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
> 
> Abstract:
>   This specification defines the addressing architecture of the IP
>   Version 6 (IPv6) protocol.  The document includes the IPv6 addressing
>   model, text representations of IPv6 addresses, definition of IPv6
>   unicast addresses, anycast addresses, and multicast addresses, and an
>   IPv6 node's required addresses.
> 
>   This document obsoletes RFC 4291, "IP Version 6 Addressing
>   Architecture".
>

---

From: David Farmer <[email-masked]>
Date: Mon, 3 Jul 2017 15:22:24 -0500

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

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

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

---

From: Bob Hinden <[email-masked]>
Date: Wed, 5 Jul 2017 13:34:32 -0700

Hi David,

> On Jul 3, 2017, at 1:22 PM, David Farmer <[email-masked]> wrote:
> 
> 
> 
> 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.

> 
> 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.
> 
> How about a note clarifying the intent of the this paragraph, something like this;
> 

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

> 2218 University Ave SE        Phone: 612-626-0815
> Minneapolis, MN 55414-3029   Cell: 612-812-9952

---

From: David Farmer <[email-masked]>
Date: Thu, 6 Jul 2017 01:40:42 -0500

On Wed, Jul 5, 2017 at 3:34 PM, Bob Hinden <[email-masked]> wrote:

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

---

From: Philip Homburg <[email-masked]>
Date: Thu, 06 Jul 2017 21:12:07 +0200

I find the presentation in Sections 2.4, 2.4.1, and 2.5 very confusing.

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

Section 2.4 starts by explaining that all addresses have a subnet prefix /
IID split. This reinforces the IPv4 notion that address assignment and
router are connected. For extra confusion it describes how some hosts may not
be aware of the split.

Then Section 2.4.1 says "It is recommended that the same interface identifier
not be assigned to different nodes on a link."

Later Section 2.5 says that some addresses that look like unicast addresses
are actually anycast addresses and then Section 2.5 has a lot of confusing
text on how anycast is supposed to work.

In practice, ND just has an 'O' flag which essentially specifies an anycast
address when clear.

Practical suggestion, remove all of the routing talk from Section 2.5,
redefine anycast to be within a single subnet and move 2.5 to be just before
2.4.1

But the main issue is that Section 2.4.1 implicitly talks about SLAAC without
actually saying so. 

And then in the middle of a sentence, it say, oh yeah, if you are doing
manual configuration, all this doesn't apply.

I assume that DHCPv6 IA_NA is considered manual configuration in this 
context. Otherwise there is no sensible way of reading that RFC.

Practical suggestion, in Section 2.4, describe that address assignment is
separate from routing. That onlink prefixes can learned from RA or be
configured manually.

Then that some address assignment mechanisms, such as SLAAC have an
prefix / IID split. Other assignment mechanisms such as manual config
(and RFC 6164) or DHCPv6 IA_NA treat the address as an opague 128-bit value.

(then have the section on anycast)

And then the section that describes how IIDs are used in SLAAC.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 7 Jul 2017 08:43:30 +1200

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

---

From: David Farmer <[email-masked]>
Date: Thu, 6 Jul 2017 16:22:14 -0500

> It now seems to to define reality, including the reality that IPv6 routing

I'm sympathetic to Philip's thesis;

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.

---

From: Philip Homburg <[email-masked]>
Date: Thu, 06 Jul 2017 23:24:14 +0200

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

It should be obvious that Section 2.5 really tries to define 2 separate
concepts.

If other people find those sections readable, then fine with me.

To me this reads like a piece of code from the 90s, that has seen 2 decades
of hacking. Techincally it does the right thing, but only an expert
recognizes all the magic hidden inside.

---

From: Philip Homburg <[email-masked]>
Date: Thu, 06 Jul 2017 23:55:48 +0200

>is an Introduction to IPv6 and maybe even include a reference to the ISOC

It used to be that RFCs were quite readable.

It makes me sad if we now produce RFCs that essentially require you
to read all the previous versions of the same RFC and the mailing list
discussions surrounding it, to understand what the RFC really tries to
say.

If somebody needs auxiliary materials just to understand an RFC as basic
as addressing architecture, then we are only a small step removed from the
mostly unreadable telco specs.

---

From: Mark Smith <[email-masked]>
Date: Fri, 7 Jul 2017 10:09:46 +1000

On 6 July 2017 at 16:40, David Farmer <[email-masked]> wrote:
>> 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
> 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.

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

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

---

From: 神明達哉 <[email-masked]>
Date: Fri, 7 Jul 2017 10:40:16 -0700

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

> the on-link property of a subnet prefix.
[...]
> describing as an "on-link prefix" sounds like something different to

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

---

From: Lorenzo Colitti <[email-masked]>
Date: Sat, 8 Jul 2017 14:47:37 +0900

>    configured, or by exceptions defined in standards track documents.
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.

---

From: David Farmer <[email-masked]>
Date: Sat, 8 Jul 2017 10:00:08 -0500

> formally update RFC 4291. Anything else will be confusing for implementers.

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.

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 9 Jul 2017 08:35:48 +1200

> formally update RFC 4291. Anything else will be confusing for implementers.

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

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 10 Jul 2017 15:52:51 +0000

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

> -----Original Message-----
> From: ipv6 [mailto:[email-masked]] On Behalf Of Bob Hinden
> Sent: Monday, July 03, 2017 10:36 AM
> To: IPv6 List <[email-masked]>
> Cc: Bob Hinden <[email-masked]>
> Subject: <draft-ietf-6man-rfc4291bis-09.txt>
> 
> Hi,
>

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 11 Jul 2017 08:52:10 +1200

Fred,

> 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

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

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 10 Jul 2017 21:53:47 +0000

Hi Brian,

> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Monday, July 10, 2017 1:52 PM
> To: Templin, Fred L <[email-masked]>; IPv6 List <[email-masked]>
> Subject: Re: <draft-ietf-6man-rfc4291bis-09.txt>
> 
> Fred,
> 

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

---

From: Mark Smith <[email-masked]>
Date: Tue, 11 Jul 2017 09:32:49 +1000

> Therefore, fe80:: is logically not a subnet-router anycast address.

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.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 11 Jul 2017 10:24:03 +0900

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

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.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 11 Jul 2017 13:36:51 +1200

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

> assigned to multiple links. Other prefixes can be anycast prefixes

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.
 
> configured on all links, so it is never an off-link anycast fe80::/64

So the address fe80:: might, or might not, be reached on all the
interfaces.
 
>    Subnet-Router anycast addresses for the subnets to which they have

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

---

From: Mark Smith <[email-masked]>
Date: Tue, 11 Jul 2017 13:49:46 +1000

> specify much of anything. fe80::%eth0/64 is valid syntax

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.

> simultaneously? I don't think that is discussed anywhere.

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.

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

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 11 Jul 2017 16:10:00 +0000

Hi,

> From: Mark Smith [mailto:[email-masked]]
> Sent: Monday, July 10, 2017 8:50 PM
> To: Brian E Carpenter <[email-masked]>
> Cc: Templin, Fred L <[email-masked]>; IPv6 List <[email-masked]>; Bob Hinden <[email-masked]>

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

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 11 Jul 2017 16:49:35 +0000

Hi again,

> From: ipv6 [mailto:[email-masked]] On Behalf Of Templin, Fred L
> Sent: Tuesday, July 11, 2017 9:10 AM
> To: Mark Smith <[email-masked]>; Brian E Carpenter <[email-masked]>
> Cc: Bob Hinden <[email-masked]>; IPv6 List <[email-masked]>
> Subject: RE: <draft-ietf-6man-rfc4291bis-09.txt>
> 
> Hi,
> 

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

---

From: David Farmer <[email-masked]>
Date: Mon, 17 Jul 2017 16:42:23 -0500

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

---

From: james woodyatt <[email-masked]>
Date: Tue, 18 Jul 2017 10:04:11 +0200

On Jul 17, 2017, at 23:42, David Farmer <[email-masked]> wrote:
> 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.

> 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 <[email-masked] <mailto:[email-masked]>>

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Tue, 18 Jul 2017 19:19:42 +0000

From: ipv6 [mailto:[email-masked]] On Behalf Of james woodyatt

On Jul 17, 2017, at 23:42, David Farmer <[email-masked]> wrote:

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

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

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

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 19 Jul 2017 11:15:52 +1200

On 18/07/2017 20:04, james woodyatt wrote:
> 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

---

From: james woodyatt <[email-masked]>
Date: Wed, 19 Jul 2017 08:22:50 +0200

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

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

> if that text was published as an RFC. That's a major part of the criteria for

Agreed.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 19 Jul 2017 19:57:58 +1200

> 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 no…

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

---

From: james woodyatt <[email-masked]>
Date: Wed, 19 Jul 2017 10:12:23 +0200

On Jul 19, 2017, at 09:57, Brian E Carpenter <[email-masked]> wrote:
>> On Jul 19, 2017, at 01:15, Brian E Carpenter <[email-masked] <mailto:[email-masked]>> wrote:
>>> 

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.

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 19 Jul 2017 10:26:37 +0200

On Wed, Jul 19, 2017 at 8:22 AM, james woodyatt <[email-masked]> wrote:

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

---

From: David Farmer <[email-masked]>
Date: Wed, 19 Jul 2017 08:44:30 -0500

Sent from my iPhone
> On Jul 19, 2017, at 02:26, Lorenzo Colitti <[email-masked]> wrote:
> 
>> 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.
> 
> 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

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 19 Jul 2017 14:51:48 +0100

David Farmer wrote:
> 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.

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

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

---

From: 神明達哉 <[email-masked]>
Date: Wed, 19 Jul 2017 16:47:48 -0700

At Mon, 17 Jul 2017 16:42:23 -0500,

> other. Accordingly, 64 bit Interface Identifiers are recommended for

I don't see how RFC4861 is related to IID.  This seems to be based on
the common confusion on the difference between on-link prefixes and
address assignment prefixes (RFC4861 refers to "interface identifier"
only in a handful of phrases, none of which seems to be relevant to
this topic).  But I guess you are one of the few people who actually
understand this point quite well, so this is probably an editorial
problem.  Maybe you're trying to answer the question like the one
Brian asked: "if we manually configure an IPv6 address and gets an RA
PIO with L=1 and A=0 whose and the prefix length being 80 bits that
(happens to) match the configured address, then what would we call the
rightmost 48 bits of the address?  Is it the 'interface identifier'"?
I agree that's a valid question, but it's too subtle to explain by
such a brief explanation like the above one.  It's really subtle and
if we want to answer the question in rfc4291bis, much verbose text
will be necessary.

But, even if we address this point, I don't see any possibility in
making "64" a mere "recommendation" in the context rfc4291bis.  Let's
be realistic - it simply won't be accepted by one of the "camp"s that
want to keep the current requirement on this point as much as
possible.

If the proposal only clarifies the question like the above one without
trying to tweak the most contentious points, that may make sense and
as a fan of clarity I might actually support it.  But as I said above
it will result in much more verbose text and it will have its own
drawback - for example I thought Bob didn't want to talk about too
much on how to generate addresses or refer to other specs that do not
directly related to the addressing architecture (ND, SLAAC, DHCPv6
etc).

So, to me, the time for tweaking the text is over.  IMO we should now
just see if we can form a rough consensus on some basic point (e.g.,
explicitly excluding the manually configured addresses for the 64-bit
requirement) and move on or drop the effort.  The result will still
leave questions (such as the above one) and contain some awkward
content (like the listed exceptions in the architecture), and I'd be
sad about that, but that's probably an inconvenient truth when what's
needed to make progress is compromise rather than technical purity.

--
JINMEI, Tatuya

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 20 Jul 2017 14:01:35 +1200

> 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

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Thu, 20 Jul 2017 02:14:11 +0000

From: ipv6 [mailto:[email-masked]] On Behalf Of Brian E Carpenter

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

That's certainly my answer too. But more to the point, I don't understand what other answer could be valid, or said another way, why ask the question?

RFC 4291 wasn't ambiguous about this, was it?

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

That isn't limited to 64 bits? It says:

We've been over the broadening of the exceptions in 4291-bis, but even as written, the IID isn't constrained to being just 64 bits.

Bert

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 20 Jul 2017 14:40:53 +1200

> That's certainly my answer too. But more to the point, I don't understand what other answer could be valid, or said another way, why ask the question?

a) Because of the several subtly different meanings of 'prefix' in IPv6.
b) Because some people seem to be limiting their use of 'IID' to the SLAAC meaning of 'prefix'.

    Brian

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Thu, 20 Jul 2017 03:36:21 +0000

-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]] 
Sent: Wednesday, July 19, 2017 22:41

>> why ask the question?

Some prefixes can be on-link, while others are not. Okay, but this is a question of address architecture, and whatever prefix bits exist in that 128-bit address, the remaining bits are by definition IID.

   |          n bits               |           128-n bits            |

> b) Because some people seem to be limiting their use of 'IID' to the SLAAC

I see only a small ambiguity in this regard. From RFC 4862:

   interface identifier -  a link-dependent identifier for an interface
      that is (at least) unique per link [RFC4291].  Stateless address
      autoconfiguration combines an interface identifier with a prefix
      to form an address.  From address autoconfiguration's perspective,
      an interface identifier is a bit string of known length.  The
      exact length of an interface identifier and the way it is created
      is defined in a separate link-type specific document that covers
      issues related to the transmission of IP over a particular link
      type (e.g., [RFC2464]).  Note that the address architecture
      [RFC4291] also defines the length of the interface identifiers for
      some set of addresses, but the two sets of definitions must be
      consistent.  In many cases, the identifier will be derived from
      the interface's link-layer address.

This definition does not limit the IID to 64 bits either, giving RFC 2464 only as an example, and saying only that "in many cases," the IID is derived from the link layer address. Without specifying how long that might be. And it refers back to RFC 4291, which does not limit IID to 64 bits.

The ambiguity is this:

      a link-dependent identifier for an interface
      that is (at least) unique per link [RFC4291].

IMO, that should now be stated as "unique per subnet prefix," as clearly stated in 2.5.1 of RFC 4291. I think we mentioned this in discussion recently. Still, this doesn't change the main point, that IIDs should not be constrained to always 64 bits, unless formed using SLAAC, as a self-imposed, artificial limitation. (Which as you pointed out, some clever hack can change in due course.)

Bert

---

From: 神明達哉 <[email-masked]>
Date: Thu, 20 Jul 2017 13:39:23 -0700

At Thu, 20 Jul 2017 03:36:21 +0000,
"Manfredi, Albert E" <[email-masked]> wrote:

> Some prefixes can be on-link, while others are not. Okay, but this
> is a question of address architecture, and whatever prefix bits
> exist in that 128-bit address, the remaining bits are by definition
> IID.

I suspect Brian tried to explain that some people interpret prefixes
for on-link determination are a different kind of prefix than the
"subnet prefix" as defined in Section 2.5 of RFC4291.  For those
people it's not obvious whether the remaining bits that follow the
on-link prefix are "by definition IID".  Before saying "those people
are simply wrong because section X of RFC Y says this...", please see
below.

[...]
> This definition does not limit the IID to 64 bits either, giving RFC
> 2464 only as an example, and saying only that "in many cases," the
> IID is derived from the link layer address. Without specifying how
> long that might be. And it refers back to RFC 4291, which does not
> limit IID to 64 bits.

I don't see how this can be a counter-argument to what Brian said,
which was not about the length of IID.  The original question was
whether the "remaining bits" in the above context are considered to be
IID.  In that context, 'b' should be interpreted as:

- some people seem to be limiting their use of 'IID' to SLAAC meaning
  of 'prefix', i.e, a prefix advertised via RA PIO with A flag being 1.
- if a prefix for on-link determination (a prefix advertised via PIO
  with L flag being 1 and A flag maybe being 0) is different from this
 'SLAAC meaning of prefix' (either in the bit pattern or in the prefix
 length), this means the "remaining bits" are not IID "by definition"
 for those people since in their definition "IID" is used only for
 remaining bits that follow an SLAAC meaning of prefix.

Whether the IID in those people's definition is fixed at 64 bits is
irrelevant in this context.

Here, I'm not trying to convince you that their view is correct.  To
me, however, those "some people" and people like you or Brian have
both some valid points, and it's not that one of the views is definitely
correct and the other is completely wrong.  The difference of the
views comes from the fact that RFC4291 or its bis is not super crystal
clear and there is some possible inconsistency between it and other
IPv6 RFCs, leaving questions like this one to one's interpretation.
It seems that people believing one particular view tend to refer to
some specific part of those RFCs or drafts or existing implementations
that are convenient to reach their favorite interpretation, but the
reality is that other interpretations can be quite possible.  I don't
expect either group with a strong opinion to agree with the other, but
at least unless they recognize both groups have some reason to believe
a particular view, we will never be able to escape from this gridlock,
at least in the scope of rfc4291bis.

--
JINMEI, Tatuya

---

From: Philip Homburg <[email-masked]>
Date: Fri, 21 Jul 2017 11:26:01 +0200

>at least in the scope of rfc4291bis.

Independent of what RFC 4291 currently says, I would prefer IID to only refer
to address configuration using SLAAC.

What we currently have is that requirements on IID depend on the use case.
If you use an IID in the context of SLAAC then we have one set of requirements
(link dependent lenght), if you use it with a /127 prefix or manual config
it's. This causes way too much confusion.

Then again I'm of the opinion that the relevant sections of rfc4291bis need
to be rewritten to be actually readable. The current text should not be
published as an internet standard.

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Fri, 21 Jul 2017 17:41:19 +0000

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Philip Homburg

> Independent of what RFC 4291 currently says, I would prefer IID to
> only refer to address configuration using SLAAC.

Might I suggest that this is a bigger change than that of removing notions of hard 64-bit boundaries?

Two routers interconnected with /127s. Does that last bit not identify the interface?

Bert

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 22 Jul 2017 08:34:26 +1200

> to address configuration using SLAAC.

Then you really have to answer my question: if they are not called "interface
identifier" what are those bits called?

> What we currently have is that requirements on IID depend on the use case.

If they are called something else, the requirements will still depend on
the use case.

    Brian

> .

---

From: Philip Homburg <[email-masked]>
Date: Sat, 22 Jul 2017 17:27:51 +0200

>Might I suggest that this is a bigger change than that of removing notions =
>of hard 64-bit boundaries?

Note that it is meant to be a documentation change. No change in how
IPv6 is currently deployed.

So IID only refers to SLAAC.

>Two routers interconnected with /127s. Does that last bit not identify the =
>interface?

Let me just call the part after the prefix 'host part'. Then in the
case of a /127 the host part would be 1 bit.

By and large a 'host part' does have any properties. Other than that for a 
/n prefix, the host part is of length 128-n bits.

---

From: Philip Homburg <[email-masked]>
Date: Sat, 22 Jul 2017 17:37:39 +0200

>identifier" what are those bits called?

So let me call them 'host part'

>If they are called something else, the requirements will still depend on

Basically a 'host part' doesn't have any properties. You can say it
identifies an interface, but that is not the case if a 'host part' is 
part of an anycast address.

So a host part has a specific length, which is of course related to the
prefix length. And that's it.

For manual address configuration, a host part doesn't have any properties
except that it should be unique.

For DHCP IA_NA the same applies. Though in the context of DHCP you may also
want to talk about privacy. But that goes way beyond what rfc4291 deals
with. 

Some host parts may be anycast addresses. But by and large whether an
address is anycast is a local flag that needs to be set. There are no specific
requirements for host parts that are anycast addresses.

Only when a host part happens to be used in SLAAC, we get a completely
different story.

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 23 Jul 2017 08:47:23 +1200

> So let me call them 'host part'

Hate to be picky but in RFC8200 'host' does not include 'router' and these
bits certainly exist in router addresses.

So it would have to be 'node part'. But in most cases (the only exception
being anycast) these bits may be (not must be) different in the node per
interface, so 'node' is still wrong. I just don't get why it isn't
'interface part' (with an exception for anycast). And if it's 'interface
part' I really don't see why it isn't 'interface identifier'.

Here's a thought. How would it be if the contentious sentence in 4291bis
read, in its entirety:

"Interface Identifiers are 64 bits long when used for Stateless
Address Autoconfiguration (SLAAC) [RFC4862]."

?.

Who here could not live with that?

    Brian

---

From: David Farmer <[email-masked]>
Date: Sat, 22 Jul 2017 15:54:03 -0500

On Wed, Jul 19, 2017 at 3:12 AM, james woodyatt <[email-masked]> wrote:

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

I think I'd prefer to call the righthand side of both a subnet prefix and a
on-link prefix an interface identifier, because in both case it is a node's
interface that is being identified.  Then generically they are interface
identifiers, if you are referring to a specific aspect it is qualified with
the aspect.

generically;

prefix / interface identifier

with specific aspects being referred to as;

subnet prefix / subnet interface identifier
on-link prefix / on-link interface identifier

Then it would be subnet interface identifiers that are 64 bits, except ...
and on-link interface identifiers are any length.

That is basically the assertion that started this part of the discussion,
and that did fly with at least some.

So, I've been kicking around other ideas, because if the righthand side of
an on-link prefix isn't an interface identifier, it needs another name. How
about;

node identifier
on-link identifier
host identifier
on-link node
on-link host

I think I like on-link node best, but on-link identifier is a close second
for me.

so;

subnet prefix / interface identifier
on-link prefix / on-link node

or;

subnet prefix / interface identifier
on-link prefix / on-link identifier

What do others think?

---

From: David Farmer <[email-masked]>
Date: Sat, 22 Jul 2017 16:02:25 -0500

> Who here could not live with that?

I'd be fine with that.

But , how about instead of scoping it to SLAAC specifically, how bout more
generically scoping it to automatically configured addresses or
self-configured addresses as opposed to an address provided to the node
externally.

Just a suggestion, I can live with SLAAC specifically.

thanks

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Sat, 22 Jul 2017 23:34:33 +0000

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

> So let me call them 'host part'

So we would be renaming IID in every RFC. Quite a change. And it's not "host" anyway, right? Those bits identify an interface, not a host. So call it "interface part," or "interface ID."

> Basically a 'host part' doesn't have any properties.

But that's not a distinction. I can just as easily give a structure to an IID as I can to any non-64-bit IID, if I so choose. Or, use a pseudo random value if I'm worried about privacy or security.

> You can say it identifies an interface, but that is not the case if
> a 'host part' is part of an anycast address.

Not sure why you make this distinction. Even in the anycast address, these last bits identify an interface, even if one of several possible. It's the topologically closest interface, and others would be identified by the same bit pattern. It's still an ID of an interface, as opposed to being a prefix.

I just don't see why IIDs used in SLAAC should be thought of differently. I mean, the anycast example was always a little weird, but those are a tiny minority anyway.

Bert

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Sat, 22 Jul 2017 23:42:10 +0000

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

> Here's a thought. How would it be if the contentious sentence in
> 4291bis read, in its entirety:
>

I think that is a pointless semantic complication for no benefit other than to make non-64-bit IIDs appear to be more outcasts. I vote -1 on that.

Bert

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 23 Jul 2017 11:55:06 +1200

On 23/07/2017 11:42, Manfredi, Albert E wrote:
> I think that is a pointless semantic complication 

Actually, by removing all the exceptions in the -09 text, I contend
it is a considerable semantic simplification.

> for no benefit other than to make non-64-bit IIDs appear to be more outcasts. 

Not at all. It sticks to the principle that an Internet Standard doesn't
change the existing protocol but clarifies the applicability of the
64 bit rule. You need to compare it with RFC4291, not with the -09 text.

If you want to *change* the rule for SLAAC IID lengths, that's outside
the scope of promoting 4291 to IS status. 

Regards,
     Brian

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Sun, 23 Jul 2017 00:10:08 +0000

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

> Actually, by removing all the exceptions in the -09 text, I
> contend it is a considerable semantic simplification.

I agree that the "exceptions" could be reworded, because the issue is far simpler now than what the "exceptions" imply.

IIDs used in SLAAC, LLA, or ULA, must be 64 bits long. Otherwise, there are no restrictions, other than the total address length must be 128 bits. So this avoids creating another new subtlety for IPv6, that serves no useful purpose (IMO).

One of the biggest changes in 4291-bis, which should carry over to RFC 2464 and others, has been deprecation of the use of EUI-64. The consequence of that change is that this 64-bit IID requirement becomes diminished, and by extension, the previously-listed exceptions increase. So now, rather than list the exceptions, we should be listing where 64-bit IIDs are still required.

I've no objection to using language like "default" or "recommended," though.

Bert

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 23 Jul 2017 13:58:01 +1200

On 23/07/2017 12:10, Manfredi, Albert E wrote:
> IIDs used in SLAAC, LLA, 

Link-local address creation is part of SLAAC (RFC4862 section 5.3).

> or ULA, 

There is nothing special about a ULA prefix. An address derived from
a ULA prefix may, or may not, be created by SLAAC. BCP198 applies
to ULA prefixes.

    Brian

> must be 64 bits long. Otherwise, there are no restrictions, other than the total address length must be 128 bits. So this avoids creating another new subtlety for IPv6, that serves no useful purpose (IMO).
>

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Sun, 23 Jul 2017 23:27:29 +0000

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

>> IIDs used in SLAAC, LLA, 
>
> Link-local address creation is part of SLAAC

True ... although this weakens the argument for claiming that IIDs must only be 64 bits long. Strict interpretation of RFC 4862 implies that some SLAAC addresses could have other lengths of IID, at least in principle. RFC 4862 says to refer to the link layer-specific RFC to see how long the IID had to be. Is this still what people want? Sounds like another good reason for NOT redefining IIDs as only applying to 64-bit IIDs.

> There is nothing special about a ULA prefix. An address derived
> from a ULA prefix may, or may not, be created by SLAAC.

But RFC 4193 is pretty specific about IID length of ULAs:

3.1.  Format

   The Local IPv6 addresses are created using a pseudo-randomly
   allocated global ID.  They have the following format:

      | 7 bits |1|  40 bits   |  16 bits  |          64 bits           |
      +--------+-+------------+-----------+----------------------------+
      | Prefix |L| Global ID  | Subnet ID |        Interface ID        |
      +--------+-+------------+-----------+----------------------------+

   Where:

      Prefix            FC00::/7 prefix to identify Local IPv6 unicast
                        addresses.

      L                 Set to 1 if the prefix is locally assigned.
                        Set to 0 may be defined in the future.  See
                        Section 3.2 for additional information.

      Global ID         40-bit global identifier used to create a
                        globally unique prefix.  See Section 3.2 for
                        additional information.

      Subnet ID         16-bit Subnet ID is an identifier of a subnet
                        within the site.

      Interface ID      64-bit Interface ID as defined in [ADDARCH].

So hey, perhaps ULAs are the *only* strictly mandated 64-bit IID, as of now? RFC 2464 is in jeopardy, sort of, given its rationale for requiring 64-bit IID over Ethernet links. For example, once upon a time, there was a 16-bit option for MAC addresses. Could that creep into RFC 2464-bis somehow? No telling what other IID lengths would be required for other link layer types, in the future? I'm pretty sure most people wouldn't approve of the direction these considerations would lead us to, on the 64-bit boundary question.

Bert

---

From: "t.petch" <[email-masked]>
Date: Mon, 24 Jul 2017 09:47:18 +0100

----- Original Message -----
From: "David Farmer" <[email-masked]>
To: "james woodyatt" <[email-masked]>
Cc: "IPv6 List" <[email-masked]>
Sent: Saturday, July 22, 2017 9:54 PM

On Wed, Jul 19, 2017 at 3:12 AM, james woodyatt <[email-masked]> wrote:

> On Jul 19, 2017, at 09:57, Brian E Carpenter
<[email-masked]>
> wrote:
> On Jul 19, 2017, at 01:15, Brian E Carpenter
<[email-masked]>
> wrote:
>
>
> 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
> 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,

I think I'd prefer to call the righthand side of both a subnet prefix
and a
on-link prefix an interface identifier, because in both case it is a
node's
interface that is being identified.  Then generically they are interface
identifiers, if you are referring to a specific aspect it is qualified
with
the aspect.

generically;

Then it would be subnet interface identifiers that are 64 bits, except
...
and on-link interface identifiers are any length.

That is basically the assertion that started this part of the
discussion,
and that did fly with at least some.

So, I've been kicking around other ideas, because if the righthand side
of
an on-link prefix isn't an interface identifier, it needs another name.
How
about;

node identifier
on-link identifier
host identifier
on-link node
on-link host

I think I like on-link node best, but on-link identifier is a close
second
for me.

so;

or;

What do others think?

<tp>

How would that cope with address assignment prefixes being longer than
on-link prefixes?

My on-link prefix is /60 but for address assignment I use a /64 and have
one /64 for network management devices, another for print servers,
another for routers, one or more for hosts and so on.

Tom Petch

------------------------------------------------------------------------
--------

---

From: Philip Homburg <[email-masked]>
Date: Mon, 24 Jul 2017 11:36:09 +0200

>part' I really don't see why it isn't 'interface identifier'.

I'm not attached to any particular term. However, I think it is important 
that the reader of rfc4291bis gets a clear under standing of the difference
between an IID as used for SLAAC. Which has a lot of properties, including
that it is generated locally on the node and is used for address configuration.

And on the other hand, what I called 'host part' which in general doesn't have
any properties. Calling it an 'interface identifier' is confusing if the
address is an anycast address. In the context of ND, an address is either 
covered by an onlink prefix which means that a sending node should try to
resolve the address to a link layer address or if not, the packet should be
passed to a (default) router. In the context of ND, the 'host part' is
completely transparent to the sending host, except that a NA indirectly
signals whether the address is anycast or not.

>Address Autoconfiguration (SLAAC) [RFC4862]."

In my opinion rfc4291bis should not be a random collection of true statements
that have to be assembled by the reader.

---

From: Philip Homburg <[email-masked]>
Date: Mon, 24 Jul 2017 11:51:19 +0200

>> Basically a 'host part' doesn't have any properties.
But that's not a distinction. I can just as easily give a structure to an I=
>ID as I can to any non-64-bit IID, if I so choose. Or, use a pseudo random =
>value if I'm worried about privacy or security.

I cannot parse this. 

>Not sure why you make this distinction. Even in the anycast address, these =
>last bits identify an interface, even if one of several possible. It's the =
>topologically closest interface, and others would be identified by the same=
> bit pattern. It's still an ID of an interface, as opposed to being a prefi=
>x.

Maybe I spend to much time with math, but for me an anycast address identifies
a set of interfaces and packet destined to such an address ends up on any of
them. 

To me that is completely different from the case where an address identifies
at most one interface and you know that if it gets delivered to the destination
it will always be the same interface.

>So we would be renaming IID in every RFC. Quite a change. And it's not "hos=
>t" anyway, right? Those bits identify an interface, not a host. So call it =
>"interface part," or "interface ID."

Possibly. Thought it seems that RFC 4861 and 4862 use IID only in the context
of SLAAC so that would not change.

And as a I said before, I consider a set of interfaces something quite
distinct from a single interface.

>I just don't see why IIDs used in SLAAC should be thought of differently. I=
> mean, the anycast example was always a little weird, but those are a tiny =
>minority anyway.

Because way too many seem hopelessly confused. They read about 64 bit IIDs
and do not realize that this only applies to SLAAC.

People write code that if you configure an address manually, the system
automatically considers the /64 prefix onlink.

People managed to write code that drops an onlink prefix because it doesn't 
match the length of a SLAAC IID.

---

From: David Farmer <[email-masked]>
Date: Mon, 24 Jul 2017 09:18:15 -0500

> How would that cope with address assignment prefixes being longer than

You say an address assignment prefix longer than the on-link prefix, but
then you describe below a on-link prefix longer than the address assignment
prefixes below, which do you really mean?

> another for routers, one or more for hosts and so on.

To achieve the desired result you state above, a /60 on-link prefix and /64
address assignment prefixes,  I don't see how you would be able to use
SLAAC, but you could achieve what you state above with DHCPv6, or manual
config.

Having the on-link prefix as a /60 just says that all 16 /64s are
associated with that link. But SLAAC devices will have no knowledge of
which of the 16 /64 they are suppose to generate an addresses from.

You could have a PIO with a /60 prefix with the L flag set, and 1 to 16 /64
PIOs with the A flag set. Most devices will generate addresses on all the
/64s that have an A flag set.  Printers will have no way to know they
should only use the first /64 verses the last /64 or any in between. Same
for management devices.  Now you could manually assign devices to different
/64s or use DHCPv6.  You could use DHCP for the hosts, but if set a PIO
with a A flag for the hosts on one /64 you would need to configure the
non-hosts to not use SLAAC, which is not a trivial thing to do as far as
I've seen on most devices.

What we name the righthand side of a on-link prefix isn't going to change
how it works, as Shakespeare says "a rose by any other name would smell as
sweet", we just need to agree its called a rose.

Thanks.

---

From: David Farmer <[email-masked]>
Date: Mon, 24 Jul 2017 12:22:31 -0500

> prefixes below, which do you really mean?

Sorry, I should have had caffeine before doing email. :(

/64 address assignment prefixes are longer than /60 on-link prefixes.

I think everything below is correct though. :)

> To achieve the desired result you state above, a /60 on-link prefix and
> /64 address assignment prefixes,  I don't see how you would be able to use
> You could have a PIO with a /60 prefix with the L flag set, and 1 to 16
> /64 PIOs with the A flag set. Most devices will generate addresses on all
> the /64s that have an A flag set.  Printers will have no way to know they

---

From: james woodyatt <[email-masked]>
Date: Mon, 24 Jul 2017 20:02:57 +0200

On Jul 24, 2017, at 10:47, t.petch <[email-masked]> wrote:
> 
> I think I'd prefer to call the righthand side of both a subnet prefix and a on-link prefix an interface identifier, because in both case it is a node’s interface that is being identified.  Then generically they are interface identifiers, if you are referring to a specific aspect it is qualified with the aspect.

Here is the reason I can’t do that: the fact a destination address has an on-link prefix does not, in fact, identify a destination at a node on that link. For one, it may be an anycast address. However, even if it’s a unicast address, it may— in practice, if not in standard theory— identify a destination on a node that in reality is attached to a completely different link.

An important exception, with which I find myself increasingly concerned these days, is the case where a 6LBR is sharing the subnet prefix advertised in PIO by a CE router, preferably, with plen=64, L=1 and A=1, naturally, and proposals to make plen>64 + L=1 into BCP is worrisome accordingly— and providing reachability at global scope addresses to nodes on another link by proxying ND. In this case, the CE router sends inbound packets to the 6LBR which retransmits them to the destination on its 6LO interface only if it has a host route and a ND proxy binding.

In that scenario, to say that the part of the IPv6 address that follows the on-link prefix, which‚ let me repeat, is really a routing prefix and its address configuration operational semantics are completely orthogonal to this discussion, identifies the interface on the 6LBR node and not the real destination address at the downstream 6LO node's interface, is to make a technical distinction in the context of forwarding and routing without any good purpose.

For that reason, I’d prefer not to use “interface identifier” for the part of a unicast address that follows a routing prefix, particularly the part the follows the routing prefix advertised in RA message PIO elements with A=0 and L=1.

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Mon, 24 Jul 2017 18:26:43 +0000

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

> I'm not attached to any particular term. However, I think it is
> important that the reader of rfc4291bis gets a clear under standing of
> the difference between an IID as used for SLAAC. Which has a lot of
> properties, including that it is generated locally on the node and is
> used for address configuration.
>
> And on the other hand, what I called 'host part' which in general
> doesn't have any properties.

So let's look at this. The properties of the SLAAC IID, according to RFC 4862 anyway, are that it must be whatever the IPv6-over-foo RFC tells us it must be. "Properties" would include the length, in principle not constrained to 64 bits, and for Ethernet, in accordance RFCs 2464, 4291 and 4862, an exact, predictable value, EUI-64. In the newer implementation of SLAAC, we have said that the IID for SLAAC must be a random 64 bits. And RFC 4291-bis wants to stipulate this aversion to EUI-64.

For LLAs, same deal. IID must be EUI-64 for Ethernet. We may prefer to modernize that to a random sequence, same considerations as in SLAAC.

For ULAs, RFC 4193 requires IIDs to be as defined in RFC 3513, so there too, EUI-64, exactly like SLAAC according to RFC 4862, and LLA according to RFC 2464. With our new sensitivities, probably the ULA IIDs should also be randomly chosen. I suppose SLAAC can also be used with ULA prefixes. I don't see any difference in properties so far?

The IID used in DHCPv6 can be predictable, like 1, 2, 3, etc. But theoretically, EUI-64 or a random sequence can also be applied to DHCPv6. The same considerations apply as in the previous two examples, in terms of properties we might or might not care about. In principle, even using DHCPv6, we might care not to make IIDs too obvious.

Statically assigned IIDs, much the same, except they're going to have long lifetimes.

> In my opinion rfc4291bis should not be a random collection of true
> statements that have to be assembled by the reader.

Agreed, but RFC 4291-bis should be consistent and logical. The properties we worry about for IIDs are not necessarily different, in any of these address assignment schemes, that I can tell, and it doesn't make a lot of sense to give "IID" a different name for every address assignment scheme? That would get too confusing.

Bert

---

From: 神明達哉 <[email-masked]>
Date: Mon, 24 Jul 2017 11:27:29 -0700

At Sun, 23 Jul 2017 11:55:06 +1200,

> the scope of promoting 4291 to IS status.

+1.  We really need to stop introducing the discussion on non-64 SLAAC
IID length to the rfc4291bis discussion.  It's perfectly fine to
discuss it in any post-rfc4291bis updates (although I'm quite
skeptical whether we can reach any consensus), or we could even say
"given the possibility of the post-rfc4291bis discussion we should now
give up promoting RFC4291 to IS".  But, due to the conservative nature
of rfc4291bis we can't simply have this discussion in that context
anyway, and given its controversy it would simply waste our time.  We
don't need any more unnecessary controversy for out-of-scope topics
and need to focus on the point.

>> Who here could not live with that?

I'd personally live with any editorial hack as long as we can reach
rough consensus (and unless it violates RFC4291 or current
deployments).  Also, IMO it's at least better than the draft-09 text
(excluding addresses "manually configured") as it's less ambiguous.
But I thought Bob didn't like to refer to a particular way of
generating addresses whether it's SLAAC or DHCPv6.

--
JINMEI, Tatuya

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Mon, 24 Jul 2017 18:44:25 +0000

Oh, on the IID length, as far as I can tell, we have fairly much agreed that SLAAC should insist on 64 bit IIDs, and as written, RFC 4193 clearly mandates 64-bit IIDs for ULAs, in its current incarnation. Even after EUI-64 has been deprecated, the prefix described for ULAs is going to be 64 bits. For all other examples of addresses, the length restriction doesn't need to be stated, however all the other "properties" of predictability and lifetime should still be a consideration.

>> Who here could not live with that?

Works for me.

Bert

-----Original Message-----
From: Manfredi, Albert E 
Sent: Monday, July 24, 2017 14:27
To: 'Philip Homburg' <[email-masked]>; [email-masked]
Subject: RE: <draft-ietf-6man-rfc4291bis-09.txt> 

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

Bert

---

From: David Farmer <[email-masked]>
Date: Mon, 24 Jul 2017 14:43:47 -0500

On Mon, Jul 24, 2017 at 1:44 PM, Manfredi, Albert E <
[email-masked]> wrote:

> Oh, on the IID length, as far as I can tell, we have fairly much agreed
> that SLAAC should insist on 64 bit IIDs, and as written, RFC 4193 clearly
> mandates 64-bit IIDs for ULAs, in its current incarnation.

What? Yes it says they are 64bits, but it is just referencing RFC 3513,
which is what I would expect it to do, which is the predecessor of RFC
4291. If you think RFC 4291 is really saying SLAAC IIDs are 64 bits then so
is RFC 3513 and RFC 4193 too.

> Even after EUI-64 has been deprecated, the prefix described for ULAs is
> going to be 64 bits. For all other examples of addresses, the length
> restriction doesn't need to be stated, however all the other "properties"
> of predictability and lifetime should still be a consideration.
>

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Mon, 24 Jul 2017 20:18:36 +0000

From: David Farmer [mailto:[email-masked]] 

> which is what I would expect it to do, which is the predecessor of RFC 4291.

Agreed. These two RFCs do not differ, in regards to requiring 64 bits, *and* EUI-64 in particular.

> If you think RFC 4291 is really saying SLAAC IIDs are 64 bits then so is
> RFC 3513 and RFC 4193 too.

No, RFC 4291 is agnostic on SLAAC IID length. It refers the reader to whatever IPv6-over-foo RFC, for IID length and formulation. But RFC 4193 (ULA) seems more insistent that it must be 64 bits and EUI-64. After all, as specific as RFC 4193 is on how to create ULA prefixes, there's no other option than 64-bit IIDs, for ULAs.

What I am saying is that 6man seems to have come to an agreement that SLAAC should be restricted to using 64-bit IIDs.

This SLAAC restriction is not directly related to RFCs 2464, 4291, or 4862, because these all mandated EUI-64. Still, we seem to want 64-bit IIDs mandatory for SLAAC. Why? Because we want 64-bit IIDs to be the "default" and "recommended" length, and because we figure that SLAAC will be the most popular way of forming IPv6 addresses.

So, if RFC 4291-bis wants to state as much, that's okay with me.

I think the IID length rules can be considerably simplified, compared with the "exceptions" listed in RFC 4291. Instead of "exceptions" to the 64-bit hard boundary, list the cases where it applies. SLAAC mostly, maybe a mention of Ethernet LLAs (although subject to update of RFC 2464), and ULAs. Just trying to be consistent here.

Bert

---

From: [email-masked]
Date: Tue, 25 Jul 2017 08:08:41 +0200 (CEST)

> I think the IID length rules can be considerably simplified, compared with the "exceptions" listed in RFC 4291. Instead of "exceptions" to the 64-bit hard boundary, list the cases where it applies.…

ULAs work just fine with manual configuration, and therefore should come
under the same exception for manually configured addresses.

Steinar Haug, AS2116