Subject: IIDs, u and g bits, and 4rd

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 18 Dec 2012 18:50:40 -0500

In reading the discussion,a nd trying to think through what I understand 
to be correct, it seems that there is an unforeseen ambiguity in the way 
the current documents about IPv6 IIDs are written.

I think that there are two possible meanings, ad we should decide 
explicitly which one we want.

1) u=1 means that the IID is derived from an IEEE OUI (of some form). 
With that meaning, u=1, g=1 is clearly some sort of multi-entity 
identifier.  And we should say that somewhere.

2) u=1, g=1 was unforeseen, and we don't know what it means.  In that 
case, we ought to figure out how we want that portion of the IID space 
used, and write it down clearly.  It seems to me that allowing this 
space to be used for special-semantic IIDs (with suitable care so that 
the entire ecosystem is not affected by them) is a very reasonable path.

It seems unlikely that there is actual practice in the wild with u=1, 
g=1 under either interpretation.  We do now have a request to start 
using it (4rd).  So we should decide.

Yours,
Joel

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Wed, 19 Dec 2012 00:35:35 +0000

Why do we care about u and g in the first place? Is there code in an IPv6 router or host that interprets them?

On Dec 18, 2012, at 3:50 PM, Joel M. Halpern wrote:

> In reading the discussion,a nd trying to think through what I understand to be correct, it seems that there is an unforeseen ambiguity in the way the current documents about IPv6 IIDs are written.
> 
> I think that there are two possible meanings, ad we should decide explicitly which one we want.
> 
> 1) u=1 means that the IID is derived from an IEEE OUI (of some form). With that meaning, u=1, g=1 is clearly some sort of multi-entity identifier.  And we should say that somewhere.
> 
> 2) u=1, g=1 was unforeseen, and we don't know what it means.  In that case, we ought to figure out how we want that portion of the IID space used, and write it down clearly.  It seems to me that allowing this space to be used for special-semantic IIDs (with suitable care so that the entire ecosystem is not affected by them) is a very reasonable path.
> 
> It seems unlikely that there is actual practice in the wild with u=1, g=1 under either interpretation.  We do now have a request to start using it (4rd).  So we should decide.
> 
> Yours,
> Joel
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

----------------------------------------------------
The ignorance of how to use new knowledge stockpiles exponentially. 
   - Marshall McLuhan

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 18 Dec 2012 20:06:29 -0500

As I understand it, the original intent with the U bit was to provide an 
easy way to create IID that were highly likely to be distinct from all 
other IIDs (on the link).  As IEEE reserves the G bit, we marked that as 
special as well when the U bit was set.

Changing the meaning of U=1, G=0 seems a major chane with no particular 
benefit.

When we defined it, we were unclear about the U=1, G=1 case.  Given the 
way the U bit is defined, U=1, G=1 can not occur in the normal course of 
events.  We can ignore it.  we can define it.  We can reserve it and thn 
sit on our hands.  But given taht we have text already, and that text is 
ambiguous, it seems like we should at least clear up the ambiguity.

Yours,
Joel

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Wed, 19 Dec 2012 01:13:58 +0000

As you know, the EUI-64 address is but one of the seeds that an EID can be generated from. Having been generated, it's a bit string, and another bit string either equals it or doesn't.

You didn't answer my question.

What, on an IPv6 host or router, cares about the g bit apart from the code that uses an EUI-48 or EUI-64 to create an EID? What starts from an EID and extracts from it an EUI-64/48 address, or in any other way interprets the g flag in an EID? 

u and g are a recurring theme. Apart from the people who wrote RFC 4291, who are under the delusion that the only link layer in the world is an Ethernet, who actually cares?

On Dec 18, 2012, at 5:06 PM, Joel M. Halpern wrote:

> As I understand it, the original intent with the U bit was to provide an easy way to create IID that were highly likely to be distinct from all other IIDs (on the link).  As IEEE reserves the G bit, we marked that as special as well when the U bit was set.
> 
> Changing the meaning of U=1, G=0 seems a major chane with no particular benefit.
> 
> When we defined it, we were unclear about the U=1, G=1 case.  Given the way the U bit is defined, U=1, G=1 can not occur in the normal course of events.  We can ignore it.  we can define it.  We can reserve it and thn sit on our hands.  But given taht we have text already, and that text is ambiguous, it seems like we should at least clear up the ambiguity.
> 
> Yours,
> Joel
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 18 Dec 2012 20:16:18 -0500

Phrased that way, I do not think any stack anywhere looks at the U or G 
its in a received IPv6 address.

I have no problem if we declare hem to be irrelevant.

Your,
Joel

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 19 Dec 2012 08:23:54 +0000

> its in a received IPv6 address.

That's why I asked if ILNP depends on the u bit. You presumably
saw Ran's reply, including "The U bit does have value for ILNP."

> I have no problem if we declare hem to be irrelevant.

If we could, IMHO it would be a step forward. But that needs
a debate.

    Brian

>> As you know, the EUI-64 address is but one of the seeds that an EID
>> can be generated from. Having been generated, it's a bit string, and
>> another bit string either equals it or doesn't.
>>
>> What, on an IPv6 host or router, cares about the g bit apart from the
>> code that uses an EUI-48 or EUI-64 to create an EID? What starts from
>> an EID and extracts from it an EUI-64/48 address, or in any other way
>> interprets the g flag in an EID?
>>
>> u and g are a recurring theme. Apart from the people who wrote RFC
>> 4291, who are under the delusion that the only link layer in the world
>> is an Ethernet, who actually cares?
>>
>>> As I understand it, the original intent with the U bit was to provide
>>> an easy way to create IID that were highly likely to be distinct from
>>> all other IIDs (on the link).  As IEEE reserves the G bit, we marked
>>> that as special as well when the U bit was set.
>>>
>>> When we defined it, we were unclear about the U=1, G=1 case.  Given
>>> the way the U bit is defined, U=1, G=1 can not occur in the normal
>>> course of events.  We can ignore it.  we can define it.  We can
>>> reserve it and thn sit on our hands.  But given taht we have text
>>> already, and that text is ambiguous, it seems like we should at least
>>> clear up the ambiguity.
>>>
>>> Yours,
>>> Joel
>>>
>>>> Why do we care about u and g in the first place? Is there code in an
>>>> IPv6 router or host that interprets them?
>>>>
>>>>> In reading the discussion,a nd trying to think through what I
>>>>> understand to be correct, it seems that there is an unforeseen
>>>>> ambiguity in the way the current documents about IPv6 IIDs are
>>>>> written.
>>>>>
>>>>> 1) u=1 means that the IID is derived from an IEEE OUI (of some
>>>>> form). With that meaning, u=1, g=1 is clearly some sort of
>>>>> multi-entity identifier.  And we should say that somewhere.
>>>>>
>>>>> 2) u=1, g=1 was unforeseen, and we don't know what it means.  In
>>>>> that case, we ought to figure out how we want that portion of the
>>>>> IID space used, and write it down clearly.  It seems to me that
>>>>> allowing this space to be used for special-semantic IIDs (with
>>>>> suitable care so that the entire ecosystem is not affected by them)
>>>>> is a very reasonable path.
>>>>>
>>>>> It seems unlikely that there is actual practice in the wild with
>>>>> u=1, g=1 under either interpretation.  We do now have a request to
>>>>> start using it (4rd).  So we should decide.
>>>>>
>>>>> Yours,
>>>>> Joel

---

From: Ray Hunter <[email-masked]>
Date: Wed, 19 Dec 2012 09:57:58 +0100

OK I'll bite. All IMVHO.

In answer to Fred's question, to me the current problem is on the end
hosts and not on existing intermediate devices.

There are many different ways to assign IPv6 addresses, including manual
assignment, that can all run simultaneously on the same interface/link
and the same /64 prefix. New IDs are still being generated on address
assignment even today e.g.
https://datatracker.ietf.org/doc/draft-gont-6man-stable-privacy-addresses &
4rd https://datatracker.ietf.org/doc/draft-ietf-softwire-4rd/. I'm sure
there'll be many more in the future.

Some of those ID's do put additional semantics into the IID. Others don't.

Some of those that use semantics in the IID sometimes do not rely on DAD
to detect assignment clashes.

It seems to me with the benefit of hindsight that a fundamentally better
approach would have been to reserve many more bits in the IID, or in RA
PIO, to create mutually exclusive subspaces per assignment mechanism or
per class of assignment mechanism, but that train has probably left the
station long ago, and that now assigning a huge block of space for u=1
g=1 exclusively for a tunnel protocol like 4rd is fundamentally unfair
and restrictive for future assignment mechanisms. Also having addresses
assigned without performing DAD would seem a bad move to me on any
prefix with more than one address assignment scheme running.

Besides, who will guarantee that the IEEE won't come up with some future
use for u=1 g=1? I'm not even sure the IETF should define these semantics.
So in response to Joel, I'd humbly suggest defining u=1 g=1 as reserved
for future use (to be defined in conjunction with the IEEE).

To me, an alternative for consideration for 4rd would be either to use a
dedicated IEEE-defined special-purpose OUI (together with an additional
rd4 specific header for any remaining bits that cannot be encoded
directly in the IID/IPv6 address), or to use locally assigned IIDs
starting with binary 000 and ensure no other locally assigned IIDs are
running on this particular scope. That should avoid changing any other
standards or existing implementations.

regards,
RayH

Joel M. Halpern wrote:
>>> ambiguity in the way the current documents about IPv6 IIDs are written.
>>>

---

From: Rémi Després <[email-masked]>
Date: Wed, 19 Dec 2012 10:24:34 +0100

Hello, Fred,

> Why do we care about u and g in the first place? Is there code in an IPv6 router or host that interprets them?

The current situation is AFAIK the following:
(a) No RFC implies behaviors that differ depending on whether g=0 or g=1 in received IIDs.
(b) On the contrary, in the SLAAC privacy extension of RFC 4941, which has u=0, addresses can be unicast although they have g=1. The IEEE semantic of group addresses must explicitly be ignored in this case.
(c) In the Identifier-Locator Network Protocol of RFC 6741 (ILNP), the IEEE semantic of g=0 applies to unicast addresses (section 3). Besides, "ILNP uses IPv6 multicast for ILNPv6", which implies that addresses are not concerned with IID formats (RFC 4291 sec 2.7).  Other formats are envisaged but explicitly depend on further work. The u=g=1 remains unused.

Regards,
RD

---

From: Rémi Després <[email-masked]>
Date: Wed, 19 Dec 2012 10:45:49 +0100

Hello, Ray,

2012-12-19 09:57, Ray Hunter <[email-masked]> :
...
> and restrictive for future assignment mechanisms.

The proposal is precisely to use the only remaining unused pattern (u=g=1) as an escape mechanism FOR ALL future IID formats. 
(Among IIDs having u=g=1, 4rd is proposed to reserve only IIDs starting with 00000011, i.e. 1/64th of the left space.) 

In my understanding, this exactly what you are looking for in view of constraints of compatibility with past decisions.  

Note that, with the 4rd specification as is, the 4rd reserved pattern could even be 0000001100000000, i.e. 1/16384 of the left space.

Hoping it clarifies,
Regards,
RD

---

From: Ray Hunter <[email-masked]>
Date: Wed, 19 Dec 2012 11:20:56 +0100

> Rémi Després <mailto:[email-masked]>
> 19 December 2012 10:45
> Hello, Ray,
>
> The proposal is precisely to use the only remaining unused pattern
> (u=g=1) as an escape mechanism FOR ALL future IID formats.
> (Among IIDs having u=g=1, 4rd is proposed to reserve only IIDs
> starting with 00000011, i.e. 1/64th of the left space.)
>
> In my understanding, this exactly what you are looking for in view of
> constraints of compatibility with past decisions.
>
> Note that, with the 4rd specification as is, the 4rd reserved pattern
> could even be 0000001100000000, i.e. 1/16384 of the left space.
>
> Hoping it clarifies,
> Regards,
> RD
>
I already understood this [I do read all posts on this list, even if I
don't post replies].

My points are:

1) I am not comfortable with the IETF overloading IEEE semantics: the
semantics of g & u bits aren't exclusively ours to assign.
The combination g=1 u=1 is not unused as you state: that's IEEE OUI
assigned multicast.
It is only in combination with IETF IPv6 unicast address space that they
are deemed "ambiguous".

2) They may be used for something else in the future (and potentially by
the IEEE without reference to the IETF)

You want to use the using the existing (ambiguous) combination u=1 g=1
EUI-64 and IPv6 unicast to statelessly map IPv4 over IPv6 unicast (or as
an escape for other IID formats). Given that large scale deployment of
multicast in general (and multicast IPv6 routing in particular) is still
very much in its infancy, someone might well want to map the whole IEEE
EUI-64 multicast addresses statelessly also using u=1 g=1 into unicast
IPv6. And any use by 4rd would likely prevent that mapping unless 4rd is
assigned it's own OUI.

I understand that the base requirements for 4rd are that
1) every node has to have the potential to be able to easily assign an
identifier for terminating a 4rd tunnel from existing IPv6 space if possible
2) stateless 4rd gateways have to be able to easily recognise 4rd
traffic (without explicitly configuring a tunnel or IPv6 address space
in advance)
3) IPv4 space (potentially overloaded with RFC1918) has to be mapped
transparently, symmetrically, and easily, over the 4rd tunnel at the 4rd
endpoints and the 4rd gateways.

I see no requirement that *all* of the above requirements need to be
encoded directly into the IPv6 IID.
Existing nodes that do not process 4rd at all do not need 3)

Hence my suggestion to investigate using an alternative of an IEEE
assigned OUI for 1&2 together with standard IPv6 SLAAC (without changing
any existing standards at all) and add an additional 4rd header for 3)
to add any additional information that is 4rd specific. I don't think
that would fundamentally change your existing ID at all, just how the
specific bits are packaged into an IPv6 unicast packet.

This also having the advantage that if ever there was an 4rdv2 you'd
have a lot more to play with in your 4rd specific header.

regards,
RayH
> Ray Hunter <mailto:[email-masked]>
> 19 December 2012 09:57
> OK I'll bite. All IMVHO.
>
> ------------------------------------------------------------------------

---

From: "Bless, Roland (TM)" <[email-masked]>
Date: Wed, 19 Dec 2012 13:14:58 +0100

Hi,

it's not really clear to me what (particular) problem we are trying to
solve here. I don't think that it's a good idea to introduce a structure
into the IID. The IID space is usually flat and the u- and g-bit
semantics are only relevant in the IEEE EUI format. It's clear
that we map them somehow into the IID if creating a modified
EUI-64 as IID, but I don't think that we should derive something
_from_ the IID (yes, I know that also RFC4941 cares about setting the
u-bit, but it's not really clear that we gain anything from it?).

I briefly read into the 4rd draft, but it's not entirely clear to me
whether other solutions don't exist. Maybe there are other means to
get the context knowledge that this particular IPv6 address has a
special structure encoded somehow.

Regards,
 Roland

---

From: Ole Troan <[email-masked]>
Date: Wed, 19 Dec 2012 13:37:49 +0100

[...]

> special structure encoded somehow.

as a clarification of what has happened in softwire. (Suresh, please correct me if I'm wrong.)

the softwire working group has chosen to standardize "MAP-E (http://tools.ietf.org/html/draft-ietf-softwire-map-02)" as the solution for
stateless A+P. the two competing proposals MAP-T (dIVI) and 4rd are being published on experimental track.

all of these 3 solutions use interface-ids. MAP-E a single address of a certain format. while MAP-T and 4rd uses the interface-id field to carry destination IPv4 address, and in 4rd's case a checksum neutraliser field.

the interface-ids that 4rd uses must be unique on the link, and it doesn't handle conflicts with other (native) nodes well.
alternative approaches to reserving interface-id space for this mechanism could be:

 - reserve a /64 of the customers delegated prefix for the sole use of 4rd
 - the 4rd node protects all possible 4rd interface-ids using DAD

Best regards,
Ole

---

From: Rémi Després <[email-masked]>
Date: Wed, 19 Dec 2012 13:49:02 +0100

> I already understood this [I do read all posts on this list, even if I

Well, this was to answer your statement that (upper cases added) "assigning a huge block of space for u=1 g=1 EXCLUSIVELY for a tunnel protocol like 4rd is fundamentally unfair
and restrictive for future assignment mechanisms".

> It is only in combination with IETF IPv6 unicast address space that they

IEEE isn't concerned with what uses IETF makes, at the IP layer, of IEEE-specified link-layer formats.
In this context, IETF problems, if any, can and must be solved in IETF alone.
 
> IPv6. And any use by 4rd would likely prevent that mapping unless 4rd is

If you have a specific idea about a format you would like to see for multicast, it can be looked at but, in any case, it won't change the fact that no RFC-compliant unicast address has u=g=1.

In IETF, rather than being "ambiguous", u=g=1 is simply UNUSED (no meaning at all so far).

(*) An assigned OUI wouldn't be sufficient because the IID wouldn't have enough free bits for an IPv4 address plus a checksum-neutrality preserver. It was already explained in an answer to Bob)
Besides, even if a reserved OUI would work, it would need to involve IEEE, which isn't necessary.

> Existing nodes that do not process 4rd at all do not need 3)

The fact that SOME nodes need it is sufficient for the need to exist.

> have a lot more to play with in your 4rd specific header.

See (*) above.

Regards,
RD

---

From: "Bless, Roland (TM)" <[email-masked]>
Date: Wed, 19 Dec 2012 14:01:08 +0100

Hi Ole,

Thanks for clarification. See below for comments.

> alternative approaches to reserving interface-id space for this mechanism could be:

Yes, that was another question: how can conflicts be handled/detected if
addresses have a meaningful V-field by chance...

>  - the 4rd node protects all possible 4rd interface-ids using DAD

IMHO the first option (if viable) sounds more reasonable to me than
fiddling with supposed format fields in the IID.

Just my 2 cents.

Roland

---

From: Rémi Després <[email-masked]>
Date: Wed, 19 Dec 2012 14:21:20 +0100

Ole, Roland,

Could we limit the 6man discussion to the question asked by Softwire, i.e. whether new IID types can be defined, using u=g=1, with a first one for 4rd, is compatible with the current IPv6 specification?

If the answer is positive (as it seems it can be), restarting a discussion on the 4rd design is unnecessary. That is only if the answer is negative that Softwire will have to restart working on the subject.

Regards,
RD

---

From: Randy Bush <[email-masked]>
Date: Wed, 19 Dec 2012 08:30:31 -0500

> is an Ethernet, who actually cares?

they are a repeating pita and should be removed.

my only hesitation is if ilnp has no viable alternative.  though i am
sufficiently unclear about ilnp's deployability to be uncomfortable
retaining painful kink for it.

Rey Hunter:
> There are many different ways to assign IPv6 addresses, including
> manual assignment, that can all run simultaneously on the same
> interface/link and the same /64 prefix. New IDs are still being
> generated on address assignment

i am unsure this is a feature

randy

---

From: Ole Troan <[email-masked]>
Date: Wed, 19 Dec 2012 14:50:49 +0100

> retaining painful kink for it.

my reading of RFC6741 section 2.1 is that ILNP does not depend on the u/g flags.
i.e. ILNP appear to work fine with both global scope and local scope identifiers, and does not
appear to require code to actually look at the u-bit.

cheers,
Ole

---

From: Bob Hinden <[email-masked]>
Date: Wed, 19 Dec 2012 16:16:51 +0200

Fred,

> u and g are a recurring theme. Apart from the people who wrote RFC 4291, who are under the delusion that the only link layer in the world is an Ethernet, who actually cares?

I am one of the authors of RFC4291.  I am not under any delusion that Ethernet is the only link layer.  I have no clue what would make you say that.

Bob

---

From: "Bless, Roland (TM)" <[email-masked]>
Date: Wed, 19 Dec 2012 15:44:45 +0100

Hi,

On 19.12.2012 14:21, Rémi Després wrote:
> Could we limit the 6man discussion to the question asked by Softwire,
> i.e. whether new IID types can be defined, using u=g=1, with a first
                ^^^^^^^^^^^^
Sorry, I'm not yet aware of a concept called IID _types_?
Do we really have such a thing "IID types"?

> If the answer is positive (as it seems it can be), restarting a
> discussion on the 4rd design is unnecessary. That is only if the
> answer is negative that Softwire will have to restart working on the
> subject.

Obviously, this question has further implications, so I
think it's legitimate to ask whether the proposed solution
is really a reasonable way of solving the problem.

Regards,
 Roland

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Wed, 19 Dec 2012 15:34:58 +0000

> (c) In the Identifier-Locator Network Protocol of RFC 6741 (ILNP), the IEEE semantic of g=0 applies to unicast addresses (section 3). Besides, "ILNP uses IPv6 multicast for ILNPv6", which implies t…

It is true that ILNP uses multicast addresses; so do a number of applications, such as multicast DNS, routing protocols, etc. Last I checked, an IPv6 multicast address is not identified by having bit 71 of the address set to 1 (RFC 4291 section 2.5.1), but by being within the prefix FF00::/8 (RFC 4291 section 2.7).

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 19 Dec 2012 15:58:28 +0000

>> i.e. whether new IID types can be defined, using u=g=1, with a first

I think that's an important point. If we could make a statement like

"The IID consists of N bits that have no meaning; the only constraint
is that they must be unique within the scope of a given link and
routing prefix."

then perhaps we could move forward. Today, the u and g bits are the
only ones that make the previous statement untrue for N=64, I believe.

This would require formally updating RFC 4291, which says:
   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.

s/required/recommended/ might be enough. Why is it "required" anyway?

      Brian

---

From: Rémi Després <[email-masked]>
Date: Wed, 19 Dec 2012 18:59:26 +0100

> is that they must be unique within the scope of a given link and

As is, the sentence misses that IIDs that have u=1 are expected to be universally unique. (This uniqueness is key to ensure that, as long as a site has a stable IPv6 prefix, its statelessly auto-configured hosts can have stable addresses if so desired.) 

The sentence becomes completely accurate if limited to to local-scope IIDs and to the 63 bits other than the u bit. 

Ensuring IID universal uniqueness for new types of universal-scope addresses is the subject at hand.  It can fortunately be dealt with because we know that, today, all u=1 IIDs must also have g=0.

>   constructed in Modified EUI-64 format.

Creating an additional RFC referenced in RFC 4291 as updating it seems to me a good approach. 
It would state that universal-scope IIDs other than that defined in RFC 4291 itself (i.e. in its Appendix A) are possible. Their formats are defined in specific RFCs, which are listed in an IANA registry. This registry indicates, for each of these RFCs, which bit pattern in IIDs determines its applicability.

RD

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 19 Dec 2012 19:19:55 +0100

Le 19/12/2012 00:50, Joel M. Halpern a écrit :
> form).

There is a difference between u=1 and u==1.

I think _setting_ u=1 may be done ok by a conscious programmer knowing
that interface is IEEE.  But _reading_ a u bit set, from an address
in a received packet, would not guarantee that that is an IEEE interface.

I think nothing prevents a DHCP Server to assign an address having that
u==1 to a Host and whose interface is non-IEEE (e.g. USB, cellular, or
other).  (I haven't seen a restriction in the DHCP specs saying that u=0
in case the Client's interface is not DHCP).

Other than DHCP there are other address assignment mechanisms,
documented and not, which make something in that 64bits without caring
the u-bit position may have a particular meaning.

Alex

---

From: "Bless, Roland (TM)" <[email-masked]>
Date: Wed, 19 Dec 2012 20:34:07 +0100

> then perhaps we could move forward. Today, the u and g bits are the

Yep.

> s/required/recommended/ might be enough. Why is it "required" anyway?

Yes, but I guess that we have enough examples where it's not
useful to construct IIDs according to Modified EUI-64 format
(privacy extensions, CGAs and the like).
Indeed, the IID has to unique within a link-local scope, which
is normally ensured by DAD. However, if one uses a globally
unique scheme such as a Modified EUI-64 to derive an IID,
the IID will be unique with very high probability within the
subnet scope. But that's IMHO the whole point and RFC 4291 is maybe
a little bit too restrictive.

Regards,
 Roland

---

From: "Bless, Roland (TM)" <[email-masked]>
Date: Wed, 19 Dec 2012 21:27:08 +0100

Hi Rémi,

On 19.12.2012 18:59, Rémi Després wrote:

> As is, the sentence misses that IIDs that have u=1 are expected to be
> universally unique. (This uniqueness is key to ensure that, as long

I don't agree. From an IPv6 functional point of view, IIDs only need to
be unique within the link-local/subnet scope, so _universal_ uniqueness
is not strictly _required_. Deriving the IID from a universally unique
address may help to minimize the conflict probability within a subnet
though.

> as a site has a stable IPv6 prefix, its statelessly auto-configured
> hosts can have stable addresses if so desired.)

You can also achieve the mentioned uniqueness of an IPv6 address by
having manually assigned locally unique IIDs (which is typically used
for servers since you don't want to change the IPv6 address each time
your network interface must be replaced due to hardware problems...)
combined with that stable (globally unique) IPv6 prefix.

> Ensuring IID universal uniqueness for new types of universal-scope
> addresses is the subject at hand.  It can fortunately be dealt with
> because we know that, today, all u=1 IIDs must also have g=0.

what new types of universal-scope addresses?

Regards,
 Roland

---

From: Mark Smith <[email-masked]>
Date: Wed, 19 Dec 2012 12:40:30 -0800 (PST)

>________________________________
> From: "Bless, Roland (TM)" <[email-masked]>
>To: Rémi Després <[email-masked]> 
>Cc: [email-masked] 
>Sent: Thursday, 20 December 2012 7:27 AM
>Subject: Re: IIDs, u and g bits, and 4rd
> 
>Hi Rémi,
>

I agree. It seems to me that all that RFC4291 is doing is specifying a method or algorithm deriving an IPv6 IID from an IEEE address when one is available. IPv6 IIDs aren't required to be derived from the IEEE address, otherwise static and privacy IPv6 addresses would be illegal on interfaces with IEEE link layer addresses.

I'm wondering what the real goal is. Is it to avoid having performing DAD by assuming that the link layer address is guaranteed to be globally unique? That guarantee hasn't ended up be true for IEEE addresses, so unless something better than what the IEEE have done is invented I don't think it can ever be an absolute guarantee, because you can't guarantee against future human error or stupidity.

---

From: Roger Jørgensen <[email-masked]>
Date: Wed, 19 Dec 2012 22:12:40 +0100

> Could we limit the 6man discussion to the question asked by Softwire, i.e. whether new IID types can be defined, using u=g=1, with a first one for 4rd, is compatible with the current IPv6 specifica…

sorry, but you start to really annoy me, who are you that can tell us
what we can and not discuss in this wg?

-- 

Roger Jorgensen           | ROJO9-RIPE
[email-masked]          | - IPv6 is The Key!
http://www.jorgensen.no   | [email-masked]

---

From: Roger Jørgensen <[email-masked]>
Date: Wed, 19 Dec 2012 23:01:22 +0100

see inline:

> prefix with more than one address assignment scheme running.

For most people, there are only two way of seting and IPv6 addresses,
either through RA/DHCPv6, or manual. In either case not many really
care about u/g bit, or know about it.

if you read RFC4291 and section 2.5.1. you'll see the following two paragraphs

   IPv6 nodes are not required to validate that interface identifiers
   created with modified EUI-64 tokens with the "u" bit set to universal
   are unique.

   The use of the universal/local bit in the Modified EUI-64 format
   identifier is to allow development of future technology that can take
   advantage of interface identifiers with universal scope.

First it say no hosts are required to validate it, only routers as I
read it. Any that really do that?
Second say it's open for the future to redefine the usage of the "u" bit.
The "g" bit ain't IETF's to play with as I read it - but all of this
is in EUI-64 context.

> standards or existing implementations.

this sum it up, it's not "fair" for 4rd to start using these two bits
as they ask for, it block for future usage of them.

However, we should define for future how we want "u" and "g" set to 1
being used.
But as other have stated, why should we keep them?

--

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 20 Dec 2012 08:11:31 +0000

Jouni,

On 19/12/2012 21:19, Jouni Korhonen wrote:
> On Dec 19, 2012, at 5:58 PM, Brian E Carpenter <[email-masked]> wrote:
> 
> Hmm.. how would this work with RFC5453 reserved IID space we already
> have for anycast addresses?

Good question, but I don't think it's a problem except one of wording.

"The IID consists of N bits that have no encoded meaning; the only
constraint is that they must be unique within the scope of a given link
and routing prefix. Some IID values are reserved for special use [RFC5453]."

    Brian

---

From: [email-masked]
Date: Thu, 20 Dec 2012 09:17:38 +0100 (CET)

> care about u/g bit, or know about it.

Agreed. As long as the "wrong" setting of the u/g bits has zero
operational consequence, and no compelling argument has been made
for why they are important - the u/g bits will continue to be ignored.

Steinar Haug, AS 2116

---

From: Rémi Després <[email-masked]>
Date: Thu, 20 Dec 2012 09:22:04 +0100

2012-12-19 23:01, Roger Jørgensen <[email-masked]> :
...
>   created with modified EUI-64 tokens with the "u" bit set to universal

That's precisely why uniqueness of such addresses must continue to be ensured.

>   advantage of interface identifiers with universal scope.

4rd IPv6 addresses are universally unique because:
- Each one contains a public IPv4 address
- If this IPv4 address is shared between several sites, checksum-neutrality preserver fields of their IIDs are different. (They depend on subnet prefixes of these sites, which differ by the few bits of their port-set IDs.) 

This is fully in scope of the sentence you have quoted (even if such an application wasn't anticipated when RFC 4291 was adopted). 

> All in all, nothing prevent 4rd to use u and g set to 1,

Agreed.

> however:

> as they ask for, it block for future usage of them.

As already explained, reserving for 4rd a particular IID pattern having u=g=1 (as needed to avoid confusion with EUI-64-based addresses having u=1), doesn't block "future usage" of these two bits.
On the contrary, it opens the path for new patterns using them, while no conflict with current usages has been identified (including ILNP).  

> But as other have stated, why should we keep them?

Not understood what is meant by "why should we keep them?".

RD

---

From: Jouni Korhonen <[email-masked]>
Date: Wed, 19 Dec 2012 23:19:47 +0200

- Jouni

---

From: Rémi Després <[email-masked]>
Date: Thu, 20 Dec 2012 09:54:40 +0100

> address may help to minimize the conflict probability within a subnet

Interface addresses at the link layer are specified by IEEE to be universally unique. This has been effective fort link-layer communication to need neither manual configuration nor a DAD-like protocol at this layer.

At the IP layer, it has also been effective to support a good level of address stability without needing manual configurations. 

> combined with that stable (globally unique) IPv6 prefix.

Address stability is useful for servers, yes, but also for referrals, and in general when addresses are advertised in various ways.

Relaxing uniqueness of IIDs that are based on universal-scope EUI-64  would be a step backward. 
There is no need AFAIK for such a regression.

> what new types of universal-scope addresses?

One appears now with 4rd. 
As stated in the note of the draft submitted to 6man, "Its function is to ensure that 4rd IPv6 addresses are recognizable by CEs without any interference with the choice of subnet prefixes in CE sites". These prefixes, as well as IIDs used in sites that support 4rd may have been chosen before 4rd is activated.

Regards,
RD

---

From: Rémi Després <[email-masked]>
Date: Thu, 20 Dec 2012 11:07:05 +0100

Hello, chairs,

- First a great thank you Jouni for for the reference to RFC 5453, which is perfectly relevant but had been ignored in this discussion. 
The good news is that, since an IANA registry for IID ranges has already been created, no new registry is needed for any new IID type, and in particular for 4rd. 

- Small problem: at http://www.iana.org/protocols, a registry for "Reserved Internet Protocol version 6 (IPv6) Interface Identifiers" is listed but, when clicking to open it, the page that comes is that of "Instant Message Disposition Notification (IMDN) Headers". This should be easy to fix I suppose.

- For 4rd, it is then sufficient that the table of http://tools.ietf.org/html/rfc5453#section-3  (to be reflected in the IANA registry), becomes:

+-----------------------------------------+-------------------------+
|        Interface Identifier Range       |       Description       |
+-----------------------------------------+-------------------------+
|           0000:0000:0000:0000           |  Subnet-Router Anycast  |
|                                         |        [RFC4291]        |
|                                         |                         |
| 0300:0000:0000:0000-03FF:FFFF:FFFF:FFFF |   Reserved 4rd Unicast  |
|                                         |    Addresses [RFCxxxx]  |
|                                         |                         |
| FDFF:FFFF:FFFF:FF80-FDFF:FFFF:FFFF:FFFF | Reserved Subnet Anycast |
|                                         |    Addresses[RFC2526]   |
+-----------------------------------------+-------------------------+

A possible answer from 6man to Softwire is then a request to modify the IANA section of the 4rd draft to reflect the above.

Regards,
RD

2012-12-19 à 22:19, Jouni Korhonen <[email-masked]> :
...

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 20 Dec 2012 10:44:36 +0000

Rémi,

I think this might work, and is nicely orthogonal to my question
whether the u/g bits have any intrinsic value.

One question though. You suggest
 0300:0000:0000:0000-03FF:FFFF:FFFF:FFFF
but I understand that 4rd needs 6 bytes, not 7.

Is there any reason you did not propose
 0300:0000:0000:0000-0300:FFFF:FFFF:FFFF ?

Also, is there any reason not to choose (for example)
 FDFE:0000:0000:0000-FDFE:FFFF:FFFF:FFFF
which is near the existing anycast range ?

Regards
   Brian

---

From: Rémi Després <[email-masked]>
Date: Thu, 20 Dec 2012 12:06:22 +0100

> 0300:0000:0000:0000-0300:FFFF:FFFF:FFFF ?

The reason was compatibility with the current 4rd draft, but I agree that 6 free bytes is enough, and is therefore better.
This can be part of the 6man answer to Softwire.

> which is near the existing anycast range ?

No objection that I can see.
Support for including this in the 6man answer.

Thanks,
RD

---

From: Ole Troan <[email-masked]>
Date: Thu, 20 Dec 2012 13:46:27 +0100

> Support for including this in the 6man answer.

I think this is better than making any assumption abut the u/g flags.

even so I do feel uneasy about this proposal.

- principally I think we should design protocols that do not depend on well known addresses or ports.
- I believe the IPv6 interface identifier should be of length 128-n, and not carry any structure.
  at a stretch I can accept reserved identifiers for anycast addresses.
- even for reserved interface identifiers, an implementation must handle conflicts.
  anycast does that implicitly. I'm not sure how 4rd does that.
  wouldn't putting two 4rd CEs on the same link, break?
- the size of the reservation. do we want to reserve 2^48 addresses out of every interface-id,
  and update every implementation? for an experimental mechanism?

I think that a mechanism that requires a large swath of interface-id space, and does not handle collisions, should
use a separate prefix on a virtual interface.

cheers,
Ole

---

From: Randy Bush <[email-masked]>
Date: Thu, 20 Dec 2012 08:02:33 -0500

> have for anycast addresses?

is anyone aware of any deployment of the ipv6 invented anycast?

like most ipv6 magic, i think it is ignored and regular old ipv4-style
anycast is used.

randy

---

From: Rémi Després <[email-masked]>
Date: Thu, 20 Dec 2012 15:10:48 +0100

> even so I do feel uneasy about this proposal.

Wow, what a list !
Let me try to make you comfortable.  

> - principally I think we should design protocols that do not depend on well known addresses or ports.

This is a debatable viewpoint but, more important, it isn't a problem for 4rd: neither any WKA nor any WKP is needed.

>  at a stretch I can accept reserved identifiers for anycast addresses.

No change to RFC 4291 is proposed in this respect. 

However, 4rd addresses, which are concerned with the requirement that "All Global Unicast addresses other than those that start with binary 000 have a 64-bit interface ID field", must have 64-bit IIDs. 

>  wouldn't putting two 4rd CEs on the same link, break?

(*)
4rd implementors are free to add code to reject any intra-site IID that (by mistake) would be universal-scope, and in the 4rd-assigned IID range. 
Whether including this extra complexity would be valuable enough is debatable, not forgetting that:
- 4rd is experimental
- RFC 4862 says "IPv6 nodes are not required to validate that interface identifiers created with modified EUI-64 tokens with the "u" bit set to universal are unique". (There is no guarantee that DAD will prevent all misuses of universal-scope IIDs.)  

>  and update every implementation? for an experimental mechanism?

There must be a misunderstanding somewhere: no existing implementation needs to be modified (unless 4rd support is added to it). 

> use a separate prefix on a virtual interface.

Regarding collisions, see (*) above.
What you view as a large swath is in fact only 1/2^16 of the total IID space, nothing to feel uncomfortable about.

Hoping to have addressed all your fears,
Cheers,
RD

---

From: Bob Hinden <[email-masked]>
Date: Thu, 20 Dec 2012 16:47:33 +0200

Randy,

> like most ipv6 magic, i think it is ignored and regular old ipv4-style

I assume you mean the subnet-anycast addresses (i.e., Subnet-Router anycast address).  IPv6 has always had what you call regular old ipv4-style anycast.  See section 2.6 of RFC4291.

Bob

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 20 Dec 2012 15:51:50 +0100

Le 20/12/2012 14:02, Randy Bush a écrit :
>> Hmm.. how would this work with RFC5453 reserved IID space we
>> already have for anycast addresses?
>

In Mobile IPv6 the HA discovery (DHAAD) uses a dedicated anycast address
valid within the subnet of the HA.  This is implemented and demonstrated
although not sure about the scale of deployment.

> like most ipv6 magic, i think it is ignored and regular old
> ipv4-style anycast is used.

The anycast related to MIP6 works without any IPv4.

Some magic of IPv6 anycast _is_ ignored, in that the IPv6 anycast
address is treated like any other IPv6 unicast address - it is assigned
on an interface, ND is performed on it, etc.  It's just that it has a
particular 'reserved' anycast meaning in the head of the implementer,
not that routing code is modified.

AS the MN does not know the address of its HA, it must discover it
within its home network, so it sends a request to a 'reserved' address
which has the prefix of the home network, and a 'reserved' IID - RFC2526
'Mobile IPv6 Home-Agents anycast'.

It could as well have been 'multicast', as multicast is used in DHCP
discovery phase, or other protocols' discovery phases.

(maybe that's what's needed in any new protocol's discovery phases).

Alex

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

---

From: "Bless, Roland (TM)" <[email-masked]>
Date: Thu, 20 Dec 2012 16:50:51 +0100

Hi Rémi,

On 20.12.2012 09:54, Rémi Després wrote:
> Interface addresses at the link layer are specified by IEEE to be
> universally unique. This has been effective fort link-layer
> communication to need neither manual configuration nor a DAD-like
> protocol at this layer.

IEEE link layer addresses should be universally unique, but there
were cases in which this assumption is not true, esp. if you consider
that some manufacturers simply hijacked others OUIs or that most NICs
and drivers allow to set nearly arbitrary MAC addresses.
Moreover, there are now vast amounts of virtual machines in use that
may use non legitimate IEEE addresses. So IMHO one should not rely on
supposed universal uniqueness, but always perform DAD to detect
conflicts...

> At the IP layer, it has also been effective to support a good level
> of address stability without needing manual configurations.

Yep, however, this is also true for algorithmically derived IIDs
as with privacy extensions or CGAs.

> Address stability is useful for servers, yes, but also for referrals,
> and in general when addresses are advertised in various ways.

My point was that statically assigned IIDs may lead to even more
stable IPv6 addresses than those generated out of EUI-64s.

> Relaxing uniqueness of IIDs that are based on universal-scope EUI-64
> would be a step backward. There is no need AFAIK for such a
> regression.

I never promoted to "relax the uniqueness of IIDs" (whatever that
means), my point was to avoid introducing a certain structure into
IIDs.

> One appears now with 4rd. As stated in the note of the draft
> submitted to 6man, "Its function is to ensure that 4rd IPv6 addresses
> are recognizable by CEs without any interference with the choice of
> subnet prefixes in CE sites". These prefixes, as well as IIDs used in
> sites that support 4rd may have been chosen before 4rd is activated.

Yes, I read that, but it's unclear to me why it would be such a big
deal to "reconfigure" the subnet prefixes for 4rd use since you have
to activate and configure your box anyway, i.e., maybe you can
flag an existing prefix for 4rd use when turning 4rd on. Moreover,
would it really be such a big deal to change a subnet prefix when
turning 4rd on, since we have auto configuration?

BR,
 Roland

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 20 Dec 2012 16:32:00 +0000

On Dec 20, 2012, at 12:54 AM, Rémi Després wrote:

> Interface addresses at the link layer are specified by IEEE to be universally unique. 

Yes, and EIU-64 is one of several seeds from which an IID can be derived. It's not the only one. The fact that an underlying technology provides an intended-to-be-globally-unique value (not that it actually *is* globally unique, but it is intended to be) is a happy accident, but not a requirement for the value we derive from it.

To make assertions about IP addresses based on the EUI-64 is to impose requirements that don't actually exist in IP. It's a little like saying that concrete MUST ("are required to") be grey because the rocks we use in it happen to be grey; no I can have concrete of other colors if I want.

The comment Brian is making refers to IP's requirements, which are that the IID used in a subnet by an interface must be unique within that subnet. If one has a physical machine with an interface that supports a dozen virtual machines, the requirement is not that all of the physical and virtual machines use IP addresses derived from the physical interface MAC address; the requirement is that they each have IIDs that are unique within the subnet. The obvious choice will be to use privacy addresses for the VMs, which will appear outside the physical machine as the one interface having that many IP addresses.

---

From: Rémi Després <[email-masked]>
Date: Thu, 20 Dec 2012 18:35:02 +0100

Fred,
Please see inline.

> To make assertions about IP addresses based on the EUI-64 is to impose requirements that don't actually exist in IP. It's a little like saying that concrete MUST ("are required to") be grey because…

I do agree that, despite a rule exists in some RFC one can see configurations that don't comply with it. 
Consequently, "intended to be globally unique" doesn't mean "guaranteed to be globally unique in real life", right.

This isn't a reason, however, to abandon rules that proved to be useful. 
AFAIK, the rule that IIDs having u=1 must (so far) only be based on global IEEE EUI-64 addresses is one of these useful rule not to be abandoned. 

> The comment Brian is making refers to IP's requirements, which are that the IID used in a subnet by an interface must be unique within that subnet.

This is a clear requirement, on which I think we all agree.

It is worth noting here that satisfaction of this requirement DOES DEPEND in part on IIDs having u=1 being actually unique.
(Reason is that RFC 4862 says (uppercase added) "IPv6 nodes are NOT required to validate that interface identifiers created with modified EUI-64 tokens with the "u" bit set to universal are unique".)

> If one has a physical machine with an interface that supports a dozen virtual machines, the requirement is not that all of the physical and virtual machines use IP addresses derived from the physical interface MAC address;

Well understood.

> the requirement is that they each have IIDs that are unique within the subnet. The obvious choice will be to use privacy addresses for the VMs, which will appear outside the physical machine as the one interface having that many IP addresses.

Agreed.
Since these IIDs will have u=0, this is neutral in the discussion on u=1 IIDs.

AFAIK, no technical and/or operational consideration remains that would prevent the IANA registry on IIDs to be updated as follows (the 4rd range is that proposed by Brian). 

The answer returned to Softwire can then be a request to change the 4rd draft accordingly.

| FDFE:0000:0000:0000-FDFE:FFFF:FFFF:FFFF |   Reserved 4rd Unicast  |

Regards,
RD

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 20 Dec 2012 18:34:30 +0000

> (Reason is that RFC 4862 says (uppercase added) "IPv6 nodes are NOT required to validate that interface identifiers created with modified EUI-64 tokens with the "u" bit set to universal are unique"…

Which, operationally, has been proven to be faulty. Some networks, notably virtual machines but also physical NICs that have resulted from manufacturing errors, theoretically have unique addresses but in practical fact don't.

---

From: Ole Troan <[email-masked]>
Date: Thu, 20 Dec 2012 20:29:51 +0100

Remi,

[...]

> AFAIK, the rule that IIDs having u=1 must (so far) only be based on global IEEE EUI-64 addresses is one of these useful rule not to be abandoned. 

how has it proved to be useful?
I'm not aware of any protocol or implementation using it.

> (Reason is that RFC 4862 says (uppercase added) "IPv6 nodes are NOT required to validate that interface identifiers created with modified EUI-64 tokens with the "u" bit set to universal are unique"…

to be pedantic it is RFC4291 that says that.
the only thing it says is that an implementation does not have to validate that a interface-id is _globally_ unique (how could it?), it still
has to validate that an address created with that interface-id is unique.

> AFAIK, no technical and/or operational consideration remains that would prevent the IANA registry on IIDs to be updated as follows (the 4rd range is that proposed by Brian). 

that's a different question than what was asked by the softwire.
is the question to the 6man WG now, "is it acceptable to reserve 2^48 interface-id's" using the RFC5453 registry?

cheers,
Ole

cheers,
Ole

---

From: Mark Smith <[email-masked]>
Date: Thu, 20 Dec 2012 12:08:49 -0800 (PST)

----- Original Message -----
> From: Bob Hinden <[email-masked]>
> To: Randy Bush <[email-masked]>
> Cc: "[email-masked] List" <[email-masked]>; Bob Hinden <[email-masked]>
> Sent: Friday, 21 December 2012 1:47 AM
> I assume you mean the subnet-anycast addresses (i.e., Subnet-Router anycast 
> address).  IPv6 has always had what you call regular old ipv4-style anycast.  
> See section 2.6 of RFC4291.
> 

The other difference is that IPv6 supports "within subnet" anycast, where the source and the anycast address fall within the same prefix. Traditional anycast relies on packets entering the routing/forwarding domain, so it isn't possible to use anycast between hosts on the same subnet. IPv4 ARP use of the most recent reply as well as duplicate address detection prevents this from working, where as IPv6 has been changed to support it by using the first rather than last NA received when the address is an anycast, and allowing duplicate addresses to exist within a subnet when they've been flagged as anycast addresses.

The use cases for IPv6 anycast are the same as IPv4's, with the IPv4 restriction that anycast destinations must always be outside of the subnet of the source address removed.

Regarding things like subnet-router anycast, Appletalk implemented this concept (Pg 4-7, Inside Appletalk, 2nd Ed.), and it was used by the Name Binding Protocol. Whether it was invented independently for IPv6 or inspired by Appletalk is something people like Bob would know.

---

From: Rémi Després <[email-masked]>
Date: Fri, 21 Dec 2012 09:23:37 +0100

> Which, operationally, has been proven to be faulty. Some networks, notably virtual machines but also physical NICs that have resulted from manufacturing errors, theoretically have unique addresses…

Where two NICs on the same link have the same universal-scope EUI-64 address (which can as you say result from manufacturing errors), problems will exist, right.
(Actually, these problems start at the link layer, independently from whether DAD is active for them at the IP layer.)

I don't see a difference of understanding on this.

Regards,
RD

---

From: Jouni Korhonen <[email-masked]>
Date: Fri, 21 Dec 2012 00:17:21 +0200

On Dec 20, 2012, at 3:02 PM, Randy Bush <[email-masked]> wrote:

> is anyone aware of any deployment of the ipv6 invented any cast?

I've seen some (very.. some) subnet anycast out there.. I do not know
(myself, which can be rather limited snapshot) a production network using
other RFC5453 reserved anycast IIDs. 

> like most ipv6 magic, i think it is ignored and regular old ipv4-style

Sure and that is fine.

What I am/was concerned about is that we do not walk over existing
(standards track) RFCs. If these IIDs meanings and 'u' & 'g' bits get
redefined/obsoleted/whatever.. fine but that must then be reflected
in other RFCs that today are based on RFC4291 etc. The whole blob needs
then be updated/obsoleted accordingly and with care. On this aspect I
care about specification correctness - not whether something is actually
deployed (yet).

- Jouni

---

From: Rémi Després <[email-masked]>
Date: Fri, 21 Dec 2012 10:22:14 +0100

> I'm not aware of any protocol or implementation using it.

As already said, it facilitates address stability.
This is so with OSes that, by default, base their IIDs on EUI-64 addresses of their link adapters.

> to be pedantic it is RFC4291 that says that.

Right, the RFC number wasn't the right one.
Thanks.
 
> has to validate that an address created with that interface-id is unique.

I find it very hard to interpret the above sentence the way you do.
Since, as you rightly imply, there is no way locally to check _global_ uniqueness, this sentence is useful only if it means that it is uniqueness _on the link_ that is "not required to be validated" if u=1.

Anyway, even with your interpretation, this isn't against adding a new reserved IID range to those of RFC5453.

> is the question to the 6man WG now, "is it acceptable to reserve 2^48 interface-id's" using the RFC5453 registry?

The basic question is whether reserving for 4rd a specific 8-bit IID is "compatible with the IPv6 addressing architecture" as currently specified.
Besides some expressed FUD, which isn't illegitimate in face of anything new, no such conflict has been identified by those who checked carefully.

This would normally lead to a flat "yes it is compatible" but, during the discussion, it appeared that the proposed 8-bit prefix can advantageously be replaced by a longer prefix closer to an already reserved prefix, and this without any problem for 4rd. 
A suggestion by 6man to change the proposed prefix value can therefore be constructive complement to the flat answer.
I hope the WG will make this step forward.

Regards,
RD

---

From: Rémi Després <[email-masked]>
Date: Fri, 21 Dec 2012 10:31:05 +0100

Jouni,

At this point, it appears that just adding one IID range reservation to those of RFC5453 (to be registered by IANA), can do the job. No need to change any existing RFC.

Besides, as suggested by Brian, a different IID range than that of the current 4rd draft can be recommended by 6man.

In absence of new fact, this can be IMHO a way to close this subject in 6man.

Regards,
RD

---

From: Ole Troan <[email-masked]>
Date: Fri, 21 Dec 2012 10:37:40 +0100

Remi,

> This is so with OSes that, by default, base their IIDs on EUI-64 addresses of their link adapters.

this might be off topic. but I disagree with you. it is the property of using stable globally unique identifiers to generate the interface-id that adds stability. see the draft on stable-privacy-addresses for another example (one which sets u=0).
given that no implementation uses the u-flag, it is hard to see what value it adds.

> Since, as you rightly imply, there is no way locally to check _global_ uniqueness, this sentence is useful only if it means that it is uniqueness _on the link_ that is "not required to be validated…

all implementations do validate uniqueness also for EUI-64 addresses. if you read the rest of RFC4862 that should be quite clear.

> Anyway, even with your interpretation, this isn't against adding a new reserved IID range to those of RFC5453.

correct.

> I hope the WG will make this step forward.

there appears to be quite a lot of pushback in 6man against the use of u/g bits as specified in the 4rd draft.

do I understand you correctly, that you now want to withdraw that proposal, and instead propose to make 2^48 interface-ids reserved for 4rd?
if so, I'm happy to have the discussion on the merit of that proposal here. I think the working group would benefit though, to hear
from you what problem you are actually trying to solve.

Best regards,
Ole

---

From: Ole Troan <[email-masked]>
Date: Fri, 21 Dec 2012 10:49:50 +0100

Remi,

> 4rd implementors are free to add code to reject any intra-site IID that (by mistake) would be universal-scope, and in the 4rd-assigned IID range. 

but the current specification does not handle conflicts?
I don't know what an intra-site IID is.

> - RFC 4862 says "IPv6 nodes are not required to validate that interface identifiers created with modified EUI-64 tokens with the "u" bit set to universal are unique". (There is no guarantee that DA…

that's not quite what 4862 says.

if the purpose of the reserved block is to avoid conflict with existing nodes on the link, then
that idea trivially breaks when you put two 4rd CEs on the same link.

> There must be a misunderstanding somewhere: no existing implementation needs to be modified (unless 4rd support is added to it). 

if you reserve a block out of the interface-id space, then all implementations that create interface identifers must be aware of it, to avoid creating conflicts. I don't understand why this additional reservations wouldn't require all nodes that implement RFC4941 to have to be updated.

> What you view as a large swath is in fact only 1/2^16 of the total IID space, nothing to feel uncomfortable about.

quite.

cheers,
Ole

---

From: Rémi Després <[email-masked]>
Date: Fri, 21 Dec 2012 11:35:34 +0100

Le 2012-12-21 à 10:37, Ole Troan <[email-masked]> a écrit :
...
> this might be off topic. but I disagree with you.
> it is the property of using stable globally unique identifiers to generate the interface-id that adds stability. see the draft on stable-privacy-addresses for another example (one which sets u=0).

I agree with "it is the property of using stable globally unique identifiers to generate the interface-id that adds stability", and therefore don't on what we would disagree here.

...

> all implementations do validate uniqueness also for EUI-64 addresses. if you read the rest of RFC4862 that should be quite clear.

All implementations you know, OK, but there can be others that don't.
For example, a small device that has a reserved OUI and an exclusive NIC number for this OUI, and that uses this link address to build its IID, MAY skip the check that no other interface on the link has the same address.
This is what RFC 4291 says. 
Deleting this MAY would be a significant change for which AFAIK no justification has expressed. 

>> Anyway, even with your interpretation, this isn't against adding a new reserved IID range to those of RFC5453.

So, if you agree, end of this subject for this particular discussion.

...
> there appears to be quite a lot of pushback in 6man against the use of u/g bits as specified in the 4rd draft.

FUD, yes, but technically founded pushback that haven't been answered, no one left AFAIK. 
For instance, in you own long list of doubts, you included:
- The need to "update every implementation". It definitely doesn't exist.
- The view that "we should design protocols that do not depend on well known addresses or ports". This doesn't concern 4rd which uses neither WHA nor WKP. 
With these two in particular, one can get the impression that your are trying to oppose 4rd by all possible means. Without  clarification of when your chair hat is on or off, this is unfortunate IMHO. 

> from you what problem you are actually trying to solve.

Well, I am still personally satisfied with the 4rd proposal as is.
Yet, I acknowledge that the suggestion made by Brian to choose a better prefix is valuable. 
I therefore support that the 6man answer to Softwire includes the following update of the reserved-IIDs table:

Regards,
RD

---

From: Simon Perreault <[email-masked]>
Date: Fri, 21 Dec 2012 11:56:25 +0100

Le 2012-12-20 11:07, Rémi Després a écrit :
> - Small problem: at http://www.iana.org/protocols, a registry for
> "Reserved Internet Protocol version 6 (IPv6) Interface Identifiers"
> is listed but, when clicking to open it, the page that comes is that
> of "Instant Message Disposition Notification (IMDN) Headers". This
> should be easy to fix I suppose.

I mentioned the problem to IANA.

The right link should be:
<http://www.iana.org/assignments/ipv6-interface-ids/ipv6-interface-ids.xml>

You'll see that the registry has grown since the RFC was published:

>          Interface Identifier Range                                        Description                                  Reference Date Assigned
>    0000:0000:0000:0000                     Subnet-Router Anycast                                                        [RFC4291] 2008-12-24
>    0200:5EFF:FE00:0000-0200:5EFF:FE00:5212 Reserved IPv6 Interface Identifiers corresponding to the IANA Ethernet Block [RFC4291]
>    0200:5EFF:FE00:5213                     Proxy Mobile IPv6                                                            [RFC6543]
>    0200:5EFF:FE00:5214-0200:5EFF:FEFF:FFFF Reserved IPv6 Interface Identifiers corresponding to the IANA Ethernet Block [RFC4291]
>    FDFF:FFFF:FFFF:FF80-FDFF:FFFF:FFFF:FFFF Reserved Subnet Anycast Addresses                                            [RFC2526] 2008-12-24

Note that the new registrations are part of the IANA Ethernet block...

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Ole Troan <[email-masked]>
Date: Fri, 21 Dec 2012 12:00:57 +0100

Remi,

> FUD, yes, but technically founded pushback that haven't been answered, no one left AFAIK. 

I can't parse the above.

> - The need to "update every implementation". It definitely doesn't exist.

can you please explain that? given that a RFC4941 implementation may create interface-id's that conflict with the 4rd
reserved range.

> - The view that "we should design protocols that do not depend on well known addresses or ports". This doesn't concern 4rd which uses neither WHA nor WKP. 

well-known or reserved range. I'm not in favour of either.

> With these two in particular, one can get the impression that your are trying to oppose 4rd by all possible means. Without  clarification of when your chair hat is on or off, this is unfortunate IM…

chair off, I thought I made that clear. I have asked Bob to make the call on this. I don't believe you are in a position to declare what consensus of the 6man working group is either. ;-)

I'm not trying to oppose 4rd by "all possible means". I'm trying to limit collateral damage to IPv6 specifications and implementations.
I think that 4rd would function perfectly well without any reserved interface-identifier space. do you disagree with that?

cheers,
Ole

---

From: Rémi Després <[email-masked]>
Date: Fri, 21 Dec 2012 13:56:49 +0100

Hi, Simon,

Thanks a lot for this pointer.
I will check, hopefully with Brian, which 4rd range can best fit in this up-to-date table.

RD

---

From: Ray Hunter <[email-masked]>
Date: Fri, 21 Dec 2012 14:03:47 +0100

Inline

Rémi Després wrote:
>>> AFAIK, the rule that IIDs having u=must (so far) only be based on global IEEE EUI-64 addresses is one of these useful rule not to be abandoned. 
>>> It is worth noting here that satisfaction of this requirement DOES DEPEND in part on IIDs having u=being actually unique.
> Since, as you rightly imply, there is no way locally to check _global_ uniqueness, this sentence is useful only if it means that it is uniqueness _on the link_ that is "not required to be validated" if u=
>
>>> Since these IIDs will have u= this is neutral in the discussion on u=1 IIDs.
>>>
>>>
You may call it FUD, but could you please point the WG members to the
text in either the IPv6 addressing architecture (RFC4291) or SLAAC
(RFC4862)  that says that the g bit MUST be overridden to 0 before
creating an IID (and thus link-local and global IPv6 unicast addresses
when they are appended to a /64 prefix)?

It may be sensible, but where is it *defined* in an IETF standards track
RFC that automatic address generation based on an EUI-64 seed MUST NOT
use g=1?

I think we both agree that being able to guarantee unique addresses on a
link is pretty fundamental to correct operation of IPv6, especially
considering the 4rd proposal as documented in your published ID would
not appear to use DAD, and failing DAD in existing nodes currently
causes an interface to cease processing IPv6 packets.

The only text I can find is in the Ethernet specific encapsulation
(RFC2604) which states "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." And even then it's not
specific that if a manufacturer decided to burn in an EUI-48 into their
NIC with g=1 (e.g. for a technology that multicasts by default for
multi-channel television distribution) and this address is from within
their IEEE -assigned OUI space, whether that would be illegal for use
with IETF IPv6 standards.

Also not everything is Ethernet.

regards,
RayH

---

From: Rémi Després <[email-masked]>
Date: Fri, 21 Dec 2012 14:46:26 +0100

Ray,
Please see inline.

2012-12-21 à 14:03, Ray Hunter <[email-masked]> :
...
> when they are appended to a /64 prefix)?

I hope I never suggested that any RFC says that g must always be set to 0. 
On the contrary, g can clearly be either 0 or 1 for local-scoppe IIDs (i.e. having u=0).

Now, if u=1, RFC 4291 specifies in its Annex A one way to build IIDs, and which happens to imply g=0 (a consequence of the IEEE rule for individual addresses).
AFAIK, this is so far THE ONLY IID specified by IETF with u=1, so that  u=g=1 REMAINS AVAILABLE for new IID formats. 

OK?
(If I missed another RFC specifying an IID format with u=1, thank you for giving a reference.)

> RFC that automatic address generation based on an EUI-64 seed MUST NOT

Nowhere (see above).

> with IETF IPv6 standards.

Not using a group address at the link layer for an IP unicast address is obvious enough for not needing an RFC to say it. It is AFAIK reflected by what manufacturers do.  
If you would have evidence of the contrary, I agree that it should be looked at.

> Also not everything is Ethernet.

Agreed.
(But AFAIK it doesn't change the above.)

Regards,
RD

---

From: Rémi Després <[email-masked]>
Date: Fri, 21 Dec 2012 14:57:50 +0100

2012-12-2110:49, Ole Troan <[email-masked]> :
...
> but the current specification does not handle conflicts?

There is no relation between this subject and whether assigning to 4rd an IID range having u=g=1 is "actually compatible with the IPv6 addressing architecture", which is the question asked to 6man by Suresh. 

> I don't know what an intra-site IID is.

An IID that is used in within a site.

> that's not quite what 4862 says.

Indeed, as you noted in another mail, that's RFC 4291 that says it ;-).

> that idea trivially breaks when you put two 4rd CEs on the same link.

This can be continued offline if you insist, but there has already been discussions in Softwire on this subject, with no issue left.

> if you reserve a block out of the interface-id space, then all implementations that create interface identifers must be aware of it, to avoid creating conflicts. I don't understand why this additio…

When supporting RFC 4941 a node forces u = 0.
Its implementation obviously doesn't need to be changed  because an additional use of u=1 is specified.
Ole, your expressing such unchecked objection is a pain. 

>> What you view as a large swath is in fact only 1/2^16 of the total IID space, nothing to feel uncomfortable about.

Different view.

RD

---

From: Rémi Després <[email-masked]>
Date: Fri, 21 Dec 2012 16:27:44 +0100

>> FUD, yes, but technically founded pushback that haven't been answered, no one left AFAIK. 

Fair enough.
I mean that,  AFAIK, all technical objections to u=g=1 being used for new IID formats have been answered.
I do understand that some may feel differently, and that in this case the debate must go on to reach common enough understanding. 
That's why I continue to provide explanations on technical points that, in others' opinions, appear to be unresolved.  

> can you please explain that? given that a RFC4941 implementation may create interface-id's that conflict with the 4rd

Privacy option IIDs (RFC 4941) all have u=0. They cannot conflict with 4rd IIDs which all have u=1 .

> chair off, I thought I made that clear. I have asked Bob to make the call on this. I don't believe you are in a position to declare what consensus of the 6man working group is either. ;-)

The fact that the chairs are in charge of identifying consensus is crystal clear to me.
I just express my opinion when I believe it is useful to the community.

> I think that 4rd would function perfectly well without any reserved interface-identifier space. do you disagree with that?

Yes, we do disagree on this:
- With the reserved IID range, 4rd can be activated in any IPv6 site without interfering with its subnet assignments, and without any host having to be renumbered because of a conflict with a 4rd IPv6 address. 
- This wouldn't work if 4rd IIDs would have u=0, because some hosts having RFC4291-compliant IIDs may be in conflict.
- MAP-E hasn't the same need because implementations can use the protocol field to discriminate MAP-E packets from native IPv6 packets. 

Regards,
RD

---

From: Rémi Després <[email-masked]>
Date: Fri, 21 Dec 2012 16:47:46 +0100

Hi, all,

Examining more carefully to IID range proposed by Brian for 4rd, I noticed that it didn't have the key u=g=1 combination!
Sorry for having overlooked that when I supported this particular choice.

Hence the new proposal:
- Keep Brian's proposal that the length of the 4rd IID prefix be increased to 16 (instead of 8).
- Abandon, by necessity, the idea of sharing the first 8 bits with an already reserved range.
- Consequently, take for instance 0300:0000:0000:0000-0300:FFFF:FFFF:FFFF (instead of FDFE:0000:0000:0000-FDFE:FFFF:FFFF:FFFF) 

If consensus is reached on the principle, IANA can be required to add this range to its table of www.iana.org/assignments/ipv6-interface-ids/ipv6-interface-ids.xml (Thanks to Simon for having found where it is).

Regards,
RD

---

From: Rémi Després <[email-masked]>
Date: Fri, 21 Dec 2012 18:28:54 +0100

> supposed universal uniqueness, but always perform DAD to detect

No disagreement. Systematic DAD can be recommended, but without ignoring that RFC 4291 permits to skip it for IIDs that have universal scope (u=1).  

> as with privacy extensions or CGAs.

- CGAs contribute maintain address stability, true, but also true that EUI-64 IIDs having u=1 contribute too, and have been largely deployed, and this is no reason to abandon the current meaning of the u bit.
- "Privacy" and "address stability" are to a good extent contradictory. To get privacy, EUI-64 IIDs are out of scope.

> stable IPv6 addresses than those generated out of EUI-64s.

Same view on this too, but not forgetting that, in well-behaved hosts, statically assigned IIDs MUST comply with RFC 4291 (and therefore not have u=g=1). 

> means),

No disagreement on this, then. 

> my point was to avoid introducing a certain structure into
> IIDs.

There is no structure today in IIDs that have u=0", but there is one in RFC 4291 for those that have u=1.
Abandoning it would be a step backward.

> turning 4rd on, since we have auto configuration?

Whether it is a big deal or not to reconfigure can be debated but, AFAIK, that operation is simplified if the need for such reconfigurations is avoided by design. 

Hoping this helps to reach common understanding,
Regards,
RD

---

From: Roger Jørgensen <[email-masked]>
Date: Fri, 21 Dec 2012 22:12:19 +0100

> An IID that is used in within a site.

and what is a site? thought we gave up that definition ages ago?

> This can be continued offline if you insist, but there has already been discussions in Softwire on this subject, with no issue left.

again, can you please give us a brief summary instead of just
"claiming" it has already been solved?

--

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 21 Dec 2012 16:46:04 -0500

> stateless A+P. the two competing proposals MAP-T (dIVI) and 4rd are being published on experimental track.

I can confirm this is the case. The proposal in question (4rd) is an
alternative (experimental) solution to the MAP-E standards track solution.

Thanks
Suresh

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 21 Dec 2012 17:09:19 -0500

Hi Remi/Ole/Bob,
  Speaking as the author of RFC5453, I am afraid that this will not
work. The allocation policy for this registry is *Standards Action* and
hence requires a Standards track RFC. This was done to keep the bar high
to minimize disruption to existing implementations as they do not check
against this registry. If 6man will propose this as the way forward,
then we need to change the IANA policy for the registry.

Thanks
Suresh

---

From: Rémi Després <[email-masked]>
Date: Sat, 22 Dec 2012 00:27:16 +0100

Hi, Suresh,
Comments inline.

2012-12-21 à 23:09, Suresh Krishnan <[email-masked]> :

> hence requires a Standards track RFC.

Bad news, but an indisputable fact!
Thank you for signaling it.

> This was done to keep the bar high

Because the proposed range is disjoint from any IID values that are currently permitted by RFC 4291, no disruption of any existing implementation that complies with this RFC can be caused by this new range being used for 4rd. 
Some seem to still have doubts about this so. Of course, if it would be proven to be false, this approach should be abandoned, but I am confident that sooner or later it will be understood as being a fact.

To proceed, yes, an update of RFC 5453 happens to be needed. It could add permission to include,in this registry, experimental-track protocols that are understood to not disrupt any implementation that complies with existing RFCs.

Regards,
RD

---

From: Rémi Després <[email-masked]>
Date: Sat, 22 Dec 2012 19:41:02 +0100

Roger,
Please se inline.

> and what is a site? thought we gave up that definition ages ago?

That's only site-local unicast addresses which have been deprecated in 2004 (RFC 3879).
"Site" is till in use, for instance in RFC 6368 of September 2011 and RFC 6513 of February 2012.

> "claiming" it has already been solved?

I only said that no issue concerning "two 4rd CEs on the same link" is left open in Softwire.

You can check this on the issue tracker of Softwire where pending issues are listed (trac.tools.ietf.org/wg/softwire/trac/report/1).  No one remains for 4rd.

The only point to be cleared concerns the necessary endorsement by 6man of the proposed 4rd IID prefix (as expressed in the draft itself, and raised by Suresh in his mail to 6man).

Regards,
RD

---

From: [email-masked]
Date: Sat, 22 Dec 2012 21:48:21 +0100

After some searching, I've finally found a reference in an IETF BCP  
document that to my mind does demonstrate that u==1 && g==1 && unicast  
IID = "currently unused"

http://tools.ietf.org/html/rfc5342

Quote: "Two bits within the initial 3 octets of an EUI-48 have special
    significance: the Group bit (01-00-00) and the Local bit (02-00-00).
    OUIs and IABs are allocated with the Local bit zero and the Group bit
    unspecified.  Multicast identifiers may be constructed by turning on
    the Group bit, and unicast identifiers constructed by leaving the
    Group bit zero."

Hope this helps,
RayH

Quoting Rémi Després <[email-masked]>:

>>> The basic question is whether reserving for 4rd a specific 8-bit  
>>> IID is "compatible with the IPv6 addressing architecture" as  
>>> currently specified.
>>> Besides some expressed FUD, which isn't illegitimate in face of  
>>> anything new, no such conflict has been identified by those who  
>>> checked carefully.
> Now, if u=1, RFC 4291 specifies in its Annex A one way to build  
> IIDs, and which happens to imply g=0 (a consequence of the IEEE rule  
> for individual addresses).
> AFAIK, this is so far THE ONLY IID specified by IETF with u=1, so  
> that  u=g=1 REMAINS AVAILABLE for new IID formats.
>
> OK?
> Not using a group address at the link layer for an IP unicast  
> address is obvious enough for not needing an RFC to say it. It is  
> AFAIK reflected by what manufacturers do.

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 23 Dec 2012 08:14:01 +0000

Ray,

That is about an IEEE EUI-48 and we are talking about an IETF Modified EUI-64.

I think we can say whatever we like about the bits in an IETF Modified EUI-64.

   Brian

On 22/12/2012 20:48, [email-masked] wrote:
>>>> The basic question is whether reserving for 4rd a specific 8-bit IID
>>>> is "compatible with the IPv6 addressing architecture" as currently
>>>> specified.
>> Now, if u=1, RFC 4291 specifies in its Annex A one way to build IIDs,
>> and which happens to imply g=0 (a consequence of the IEEE rule for
>> individual addresses).
>> Not using a group address at the link layer for an IP unicast address
>> is obvious enough for not needing an RFC to say it. It is AFAIK
>> reflected by what manufacturers do.

---

From: Rémi Després <[email-masked]>
Date: Sun, 23 Dec 2012 09:42:55 +0100

> That is about an IEEE EUI-48 and we are talking about an IETF Modified EUI-64.

True, but the same RFC 5342 says, in its EUI-64 section, "As with EUI-48 identifiers, the  OUI has the same Group/unicast and Local/Global bits."

>> Hope this helps,

It does (IMHO). Thanks for this reference.

Regards,
RD