Subject: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt]

From: Brian E Carpenter <[email-masked]>
Date: Fri, 01 Feb 2013 08:13:01 +0000

Hi,

We've put this together to address the general question of the
u/g bits in Interface IDs. Discussion is requested.

   Brian + Sheng

-------- Original Message --------
Subject: I-D Action: draft-carpenter-6man-ug-00.txt
Date: Fri, 01 Feb 2013 00:10:13 -0800
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : The U and G bits in IPv6 Interface Identifiers
	Author(s)       : Brian Carpenter
                          Sheng Jiang
	Filename        : draft-carpenter-6man-ug-00.txt
	Pages           : 7
	Date            : 2013-02-01

Abstract:
   The IPv6 addressing architecture defines a method by which the
   Universal and Group bits of an IEEE link-layer address are mapped
   into an IPv6 unicast interface identifier.  This document clarifies
   the status of those bits for interface identifiers that are not
   derived from an IEEE link-layer address.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-carpenter-6man-ug

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-carpenter-6man-ug-00

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Fernando Gont <[email-masked]>
Date: Fri, 01 Feb 2013 17:13:13 -0300

Hi, Brian & Sheng,

> u/g bits in Interface IDs. Discussion is requested.

Some comments:

Section 1:

>    The specification assumes that that the normal case is to transform
>    an Ethernet-style address into an IID, preserving the semantics of
>    two bits in particular:
> 
>    o  The "u" bit in an IEEE address is set to 0 to indicate universal
>       scope (implying uniqueness) or to 1 to indicate local scope
>       (without implying uniqueness).  In an IID this bit is inverted,
>       i.e., 1 for universal scope and 0 for local scope.  According to
>       [RFC5342], the reason for this was "to make it easier for network
>       operators to type in local-scope identifiers".
>    o  The "g" bit in an IEEE address is set to 1 to indicate group
>       addressing (link-layer multicast).  This value is supposed to be
>       preserved in an IID.

The second bullet is not tru: e.g. temp addresses do not do anything to
preserve the "g" bit (the "u" bit *is* forced to 0, though);

Section 2:

> 
>    NOTE IN DRAFT: Are there other examples we should include?  Are we
>    sure that no IID format defines semantics for u/g?

Not that I'm aware of. -- AFAIK, the u bit is just used to reduce the
probability of collisions if your IIDs are derived from global
identifiers (more on this below).

Section 2, page 4:
> 
>   "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."

This seems to assume that the namespace (Identifiers) of two different
technologies does not overlap. Such assumption sounds like dubious to
me... but I might be missing something.

i.e. some non-IEEE technology is expected to obey the u/g bits?

Section 3:
>    It should be noted that IIDs known or guessed to have been created
>    according to RFC 4941 could be transformed back into MAC addresses,
>    for example during fault diagnosis.  For that reason, keeping the "u"
>    and "g" bits in the IID has operational value.  Therefore, the EUI-64
>    to IPv6 IID transformation defined in RFC 4941 MUST be used for all
>    cases where an IID is derived from a MAC address.

How can you tell whether an IID was really derived from a MAC address,
or you just had pretty bad luck with your IID randomization -- such tha
it *looks* like derived form a mac address?

Thanks!

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

---

From: Mark Smith <[email-masked]>
Date: Fri, 1 Feb 2013 14:19:04 -0800 (PST)

Hi,

Regarding this,

"Also, there is
   evidence from the field that IEEE MAC addresses with "u" = 0 are
   sometime incorrectly assigned to multiple MAC interfaces."

I came across the following this week which might be worth referencing regarding occurrence of duplicate MAC addresses:

- How the data was collected -
https://speakerdeck.com/hdm/derbycon-2012-the-wild-west?slide=63

- The numbers
https://speakerdeck.com/hdm/derbycon-2012-the-wild-west?slide=64

I was quite surprised at the numbers as I've never encountered duplicate MAC addresses in around 20 years, and have only heard one or two first hand stories of it.

Regards,

Mark.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 01 Feb 2013 19:41:21 -0500

With regard to section 3, I would ask the question in the reverse. 
(which may actually be the same quewstion Fernando is asking.)

If we assume that there is value in being able to perform the diagnostic 
operation described, then it seems that one needs to be able to tell 
when it can be applied.
Currently, that is u==1 in the IID field.
The text says that u==1 must be used n the IID field for IIDs derived 
from EUI-64.
But it the goes on to say that u=1 can be used by other addresses.
If u=1 can be used by addresses not derived from EUI-64, then the 
diagnostic operation can not be applied without a-priori knowledge.
And in the presence of such knowledge, the u bit does not seem to help.

The obvious answer is that to enable the diagnostic, and because there 
is no need to make a gratuitous change, we stick with u=1 being used 
always and only for addresses derived from EUI-64.

The other alternative I can understand, although I do not favor it, is 
to not allow the diagnostic at all.

Yours,
Joel

---

From: Fernando Gont <[email-masked]>
Date: Fri, 01 Feb 2013 21:56:46 -0300

> always and only for addresses derived from EUI-64.

But if we enforce u=1 only for IIDS based on EUI-64, there might be
other IIDs generated with some other mechanism, that lead to IIDs with
such bit set to 1.

Unless u=1 is enforced for all identifiers, chances are that eventually
some other technology will generate an IID with u==1, and one would
mistakenly assume that such IID was based on IEEE identifiers...

(yes, in order for such "collisions" to occur, u would have to be 1, and
the other technology would also have to produce the 0xfffe we currently
insert to generate the Modified EUI64 identifiers... but "s* happens",
they say...)

Cheers,

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 02 Feb 2013 08:25:07 +0000

Hi Fernando,

> preserve the "g" bit (the "u" bit *is* forced to 0, though);

Well yes, but the statement *is* true when an IID is created from a MAC
address, which is the point being made at that point in the document.
(See my next message for my comment on Joel's reply.)

> identifiers (more on this below).

Who said that though? You are suggesting an intention which is nowhere
in the documents. In any case, as soon as you admit a non-zero probability
of collision, the game is changed.

> me... but I might be missing something.

Yes, I believe it was a faulty assumption from the start (and I am one
of the guilty parties).

> it *looks* like derived form a mac address?

You can't. Operationally you *might* have enough knowledge, but that is
exactly why we included the word "guessed".

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 02 Feb 2013 08:35:48 +0000

Joel,

> And in the presence of such knowledge, the u bit does not seem to help.

Correct. Semantically, it's a dead duck. That's already true, whatever
words are written in RFCs - the fact that u=1 does not prove the IID
comes from a MAC address with u=0, and vice versa.

> always and only for addresses derived from EUI-64.

But that doesn't mean that the IID was derived from a MAC address,
so its value is limited.

> to not allow the diagnostic at all.

The alternative is what we have today: *assume* that an IID that looks
as if it came from a MAC address in fact did so.

    Brian

---

From: Rémi Després <[email-masked]>
Date: Sat, 2 Feb 2013 11:33:11 +0100

Brian,

I agree that this is a good time to clarify uses of u and g bits, and support the initiative Sheng and yourself has taken.
Comments and suggestions inline.

> identifiers (more on this below).

It completely eliminates collisions for all devices that comply with IEEE specifications, and dramatically reduces it where some vendors have reused some IEEE MAC addresses.
If two devices have the same IEEE MAC address on a link, they have a problem at the link layer, even before having one at the IP layer, and has to be fixed. 

In any case, and more important in my understanding, this doesn't change that any IID having u=g=1 can never conflict with IEEE-derived IIDs, be they duplicated or not. A clarification on this would IMHO be useful.

>>   advantage of interface identifiers with universal scope."
(*)

> me... but I might be missing something.

AFAIK, it means that *if u=1* the structure of other bits has to be universally specified. This is used so far for IEEE-derived IIDs. It can advantageously be used for other technologies, as foreseen in RFC4291 itself. 4rd is just the first proposed new use.

> i.e. some non-IEEE technology is expected to obey the u/g bits?

- For all addresses subject to SLAAC, all IETF technologies are constrained by the u-bit meaning of RFC4291. If u=0, all other bits have no recognizable structure; if u=11 if all other bits have a recognizable 
- For addresses that aren't subject to SLAAC like, for instance, those of inter-router links of RFC6164, the RFC4291 structure of /64 IIDs isn't applicable. A clarification on this would IMHO be useful.

Now, a new point:
The sentence of RFC 4291 about future technologies ((*) above) is, in my understanding and if taken rigorously, less open than it can be concerning future technologies. It is sufficient that IIDs of new technologies using u=1 have a universally recognizable structure. There IID scopes can have a non-universal scope without breaking anything. Your draft can be a place to clarify this.

Note that this point is made in general, as a contribution to clarify the u/g issue, not because it would concern 4rd. IIDs of 4rd are  universally unique (each one contains a globally unique IPv4 address, plus a CNP field which has different values for all CEs that share this address).

> it *looks* like derived form a mac address?

All currently specified randomizations concern IIDs that have u=0. None can conflict with formats  specified for u=1 IIDs.

Regards,
RD

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

---

From: Ray Hunter <[email-masked]>
Date: Sat, 02 Feb 2013 11:27:24 +0100

I've read the draft.

Quote:  It should be noted that IIDs known or guessed to have been created

Dumb question: I don't get this. 4941 is "privacy extensions for SLAAC"
and generates random IIDs with u=0.
How can you "transform" a privacy extension for SLAAC IID back to a MAC
address?

IMHO The only combination that has operational value for the purpose of
mapping IPv6 address to MAC today is:
u==1 && g==0 && (concatenated with unicast IPv6/64 prefix[2000::/3] ||
link local address [fe80::/10]) && SLAAC (RFC4862)

We've never had this sort of reverse mapping in IPv4, and "sh arp" on
the local router was generally considered good enough operationally
speaking.
I 'd presume "show ipv6 neighbor binding" would also suffice.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 02 Feb 2013 11:46:06 +0000

> Dumb question: I don't get this. 4941 is "privacy extensions for SLAAC"

AAARGH. s/4941/4291/

> I 'd presume "show ipv6 neighbor binding" would also suffice.

Maybe, but every little helps.

    Brian

---

From: Brian Haberman <[email-masked]>
Date: Sat, 02 Feb 2013 08:26:46 -0500

>> always and only for addresses derived from EUI-64.

And to state the obvious, that implies that u==g==1 means we are looking 
at an identifier derived from a hardware-based identifier (e.g., IEEE).

> insert to generate the Modified EUI64 identifiers... but "s* happens",

The assumption that 0xFFFE will be in the identifier is incorrect.  That 
pattern is only inserted when the 64-bit IID is generated from a 48-bit 
IEEE identifier.  If I use a 64-bit IEEE identifier, the u bit will be 
set to 1, but the 0xFFFE pattern will (most likely) not be there.

---

From: Ray Hunter <[email-masked]>
Date: Sat, 02 Feb 2013 14:45:27 +0100

Inline

>>>   an Ethernet-style address into an IID, preserving the semantics of
Right. "Normal case." Not "exclusive case."
>> identifiers (more on this below).
This is also my interpretation.
> In any case, and more important in my understanding, this doesn't change that any IID having u=1 can never conflict with IEEE-derived IIDs, be they duplicated or not. A clarification on this would IMHO be useful.

I have a problem with any assumption that u=1 => global uniqueness, or
u=1 => IEEE EUI64 with IEEE administered OUI.

Carefully reading RFC4291 I come up with the following:

Quote: "Modified EUI-64 format-based interface identifiers may have
universal
   scope when derived from a universal token (e.g., IEEE 802 48-bit MAC
   or IEEE EUI-64 identifiers [EUI64])"

Note the "may" and note the "e.g."

Quote: "EUI64 *format*"

Note the complete absence of text like "when u=1, the IID SHOULD/MUST be
formed from an IEEE EUI64, including a globally unique OUI portion
administered by the IEEE."

I therefore openly question any assumptions regarding the IEEE as being
defined as the sole and exclusive source of "universal tokens" in the
IPv6 addressing architecture.

If another standards body built a link technology based on EUI64
*format* identifiers, but with their own OUI administration, that should
never be a problem for IPv6, because RFC4291 only requires IID's to be
"unique within a subnet prefix." They are not required to be globally
unique across all link technologies. This is backed up by another quote
from RFC4291: "The details of forming interface identifiers are defined
in the appropriate "IPv6 over <link>" specification"

Even the IEEE definition of EUI64 in
http://standards.ieee.org/develop/regauth/tut/eui64.pdf states

Quote "When an EUI-64 is used within the context of an IEEE standard,
the standard shall be reviewed by the IEEE RAC for correctness and
clarity. When an EUI-64 is referenced within non-IEEE standards, there
shall not be any reference to IEEE unless approved by the IEEE RAC."

Was this coupling of standards ever reviewed by the IEEE?

Because it seems to me that the lack of universally clear handling of
the u=1 g=1 case in IETF documents would not fit with the existing IEEE
definition of EUI64, where u=1 g=1 is clearly a globally administered
multicast address, and is not available for any other use.

So my conclusion is that any coupling between IEEE and IETF standards
should be weak at most, and also limited to individual links.
 
> AFAIK, it means that *if u= the structure of other bits has to be universally specified. This is used so far for IEEE-derived IIDs. It can advantageously be used for other technologies, as foreseen in RFC4291 itself. 4rd is just the first proposed new use.
>
>
> - For all addresses subject to SLAAC, all IETF technologies are constrained by the u-bit meaning of RFC4291. If u= all other bits have no recognizable structure; if u if all other bits have a recognizable 

> The sentence of RFC 4291 about future technologies ((*) above) is, in my understanding and if taken rigorously, less open than it can be concerning future technologies. It is sufficient that IIDs of new technologies using u=have a universally recognizable structure. There IID scopes can have a non-universal scope without breaking anything. Your draft can be a place to clarify this.
>
> All currently specified randomizations concern IIDs that have u= None can conflict with formats  specified for u=1 IIDs.
>
> Regards,
> RD
>
>
>
>> Thanks!
>>
>> Cheers,
>> -- 
>> Fernando Gont
>> SI6 Networks

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 02 Feb 2013 14:17:13 +0000

> at an identifier derived from a hardware-based identifier (e.g., IEEE).

Yes, even if it make no sense.

Or of course that we are looking at an arbitrarily invented IID that means
nothing in particular. Who's to say?

    Brian

---

From: Fernando Gont <[email-masked]>
Date: Sat, 02 Feb 2013 11:50:19 -0300

Hi, Brian,

> address, which is the point being made at that point in the document.

Agreed. (My apologies for how my phrase was worded.. "English as second
language"+"24hs working" didn't help much in me crafting my response
nicely).

> in the documents.

Agreed, but the text notes that "that is so that it is easier for
manually-configured addresses" -- i.e.,  the text notes that the idea is
that manually-configured addresses don't "overap" with the
automatically-configured ones..

> In any case, as soon as you admit a non-zero probability

I fully agree. That's the point I was trying to make.

> Yes, I believe it was a faulty assumption from the start (and I am one

I guess the current "MUST" could be changed to "MAY" -- i.e., setting
the bit to zero might still help to reduce collisions with IEEE-derived
IIDs.

HOwever, this discussion raises yet another (more) interesting question:
considering the predictability properties of IEEE-derived IIDs, and the
fact that you cannot even assume that such identifiers are unique, why
are we using that scheme as the default mechanism for generating SLAAC
addresses in the first place? :-)

Thanks!

Best regards,

---

From: Rémi Després <[email-masked]>
Date: Sat, 2 Feb 2013 16:10:20 +0100

2013-02-02  12:46, Brian E Carpenter <[email-masked]> :
...
> Maybe, but every little helps.

I support that IIDs that have u=1 MAY be used to extract some meaningful information, doing it or not remaining a vendor choice.

Pending any new IID reservations, what is possible is AFAIK the following: 
- At an Ethernet interface, if an assigned IID has  u=1, u=0, bits 24-39 = 0xFE, and OUI bits 0-24 aren't 00-00-5E  (the IANA OUI, ref https://tools.ietf.org/html/rfc5342#section-1.2.1), then the MAC address should be that of IID bits 0-23 followed by  bits 40-127.

If the 4rd reserved IID prefix is confirmed to be 0x0300, this is complemented with the following:
- At a customer site entry that is assigned an IPv6 prefix up to /64, if an destination IID starts with 0x0300, then IID bits 16-47 should be those of a global IPv4 address usable in this site, exclusively or shared depending on which 4rd CE mapping rule applies to the site. In addition, IID bits 48-64 should be the opposite of the one's complement sum of the five 16-bit fields from address bits 0-79.  

Regards,
RD

---

From: Fernando Gont <[email-masked]>
Date: Sat, 02 Feb 2013 12:15:27 -0300

> in the appropriate "IPv6 over <link>" specification"

How could you possible ensure such uniqueness without coordination?
(i.e., how can you ensure uniqueness if several non-cooperating
organizations are generating OUIS with u=1?)

Cheers,

---

From: Rémi Després <[email-masked]>
Date: Sat, 2 Feb 2013 16:52:11 +0100

Le 2013-02-02 à 14:45, Ray Hunter <[email-masked]> a écrit :
...
> Note the "may" and note the "e.g."

This is OK because RFC 4291 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" (upper-cases added). 
This implies that IIDs that have u=0 belong to those that have the "Modified EUI-64 format".

> administered by the IEEE."

The point is that it is the opposite that is said: EUI-64 derived IIDs are  NOT the only ones having the "Modified EUI-64 format" (see above). 

> IPv6 addressing architecture.

Agreement on this.

> in the appropriate "IPv6 over <link>" specification"

Yes, but nay other link technology (none is defined so far AFAIK) would have to comply with  what RFC 4291 says "Modified EUI-64 format-based interface identifiers may have universal scope when derived from a universal token (e.g., IEEE 802 48-bit MAC or IEEE EUI-64 identifiers".
The "e.g." in this sentence implies that significance of the u bit isn't limited to EUI-64 derived IIDs.

> Was this coupling of standards ever reviewed by the IEEE?

This has no implication on universally reserved IID structures of the future, provided they have u=1 and are unambiguously distinguishable from that EUI-64 derived IIDs.

> multicast address, and is not available for any other use.

Misunderstanding.
U=g=1 does remain AVAILABLE for new IID structures because multicast addresses you refer to aren't concerned with the Modified EUI-64 format. 
They have 112-bit Group IDs as opposed to 64-bit Interface IDs (refs. https://tools.ietf.org/html/rfc4291#section-2.7) and https://tools.ietf.org/html/rfc4291#section-2.5). 

> should be weak at most, and also limited to individual links.

Limited to links, YES.
Weak, NO REASON.

Regards,
RD

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 02 Feb 2013 12:17:47 -0500

I a not clear what aspect of the semantics of u==1 and the relationship 
to EUI-64 is a dead duck.  Currently, if you see something with u==1, 
you know it was made from an EUI-64.  Under your proposal, you would not 
know that.
Yous tae below tat the presence of ==1 doesn't mean that.  to the best 
of my knowledge, currently, it does mean that.  It may not be derived 
from the EUI-64 of the interface yo want to reach, but it is derived 
from an EUI-64.  Otherwise, u would be set to 0.

You are proposing to change this rule.

Aside from anything else, I do not see a motivation for changing the rule.
I have no problem with clarifying under-specified corner cases.
But why change the rule we have?  Is there a problem with the current 
rule that I am missing?

Yours,
Joel

---

From: Ray Hunter <[email-masked]>
Date: Sat, 02 Feb 2013 18:48:02 +0100

> Fernando Gont <mailto:[email-masked]>
> 2 February 2013 16:15
>
You can't at a global/ multi-link level. But for IPv6, why should the
IETF care? All RFC4291 really cares about AFAIK is that the IID acts as
a tie breaker per link. It's not as though any competing LAN/Link
standards are going to be sharing a single L2 network.

If VMware come up with a virtual "Wizzinet" to connect virtual routers
and virtual end nodes, and they coordinate the IID's to be "unique
enough" per link, and they use EUI64 format addressing, but not OUI's
administered by the IEEE, what's the problem? You're not going to plug a
physical Ethernet cable into a virtual link.

Speaking with an operational hat on, I'd rather have access to tools and
protocols that can perform mapping/registration of e.g. DUID <=> L3 <=>
L2 bindings, such as
http://datatracker.ietf.org/doc/draft-ietf-dhc-addr-registration, rather
than any fixed transformations or encoding.  Although it's not problem
free, at least we could then concentrate on ensuring DUID uniqueness in
whatever scope we were concerned about. And it covers self-generated
privacy addresses too. And potentially MAC spoofing/ locally
administered addresses. Rather than relying on static addressing
administered by some other standards body and which is reliant on good
behaviour by all participants. As I'm sure you're aware, operations are
rapidly moving to virtual machines and devices, and dedicated network
hardware with a burned-in interface ID is disappearing.

> Ray Hunter <mailto:[email-masked]>
> 2 February 2013 14:45
> Inline
>
> Rémi Després wrote:
>> Brian,
>>
> ------------------------------------------------------------------------

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 03 Feb 2013 08:24:53 +0000

On 02/02/2013 17:48, Ray Hunter wrote:
> a tie breaker per link. 

Only because it's supported by DAD, surely? There is no piece of magic
that absolutely prevents two hosts claiming the same IID.

   Brian

> It's not as though any competing LAN/Link

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 03 Feb 2013 08:41:14 +0000

On 02/02/2013 17:17, Joel M. Halpern wrote:
> you know it was made from an EUI-64.  

Actually, you don't. You know that it looks as if it was made in
Modified EUI-64 format, but you don't know that there is a genuine
MAC address behind it. You can apply heuristics (like "Is 0xFFFE
present?" and "Is the OUI an IEEE-assigned value?") but that's all.

Also, u==0 does not imply that it is not Modified EUI-64. The examples
in RFC 4291 all use EUI-64 with u==0, i.e. Modified EUI-64 with u==1,
but those are only examples.

In the end all you have is 64 meaningless bits, as far as I can tell.

   Brian

> Under your proposal, you would not
> know that.

---

From: Randy Bush <[email-masked]>
Date: Sun, 03 Feb 2013 18:46:01 +0900

>> I am not clear what aspect of the semantics of u==1 and the
>> relationship to EUI-64 is a dead duck.  Currently, if you see
>> something with u==1, you know it was made from an EUI-64.
> 
> Modified EUI-64 format, but you don't know that there is a genuine MAC
> address behind it. You can apply heuristics (like "Is 0xFFFE present?"
> and "Is the OUI an IEEE-assigned value?") but that's all.
> 

well, not entirely meaningless, eh? :)  we do line packets to go back and
forth.

i hate to sound like a broken record, but magic bits are almost never
worth the pain.

randy

---

From: Rémi Després <[email-masked]>
Date: Sun, 3 Feb 2013 11:57:41 +0100

Le 2013-02-02 à 18:17, Joel M. Halpern <[email-masked]> a écrit :

> I a not clear what aspect of the semantics of u==1 and the relationship to EUI-64 is a dead duck.  Currently, if you see something with u==1, you know it was made from an EUI-64.  Under your proposal, you would not know that.
> Yous tae below tat the presence of ==1 doesn't mean that.  to the best of my knowledge, currently, it does mean that.  It may not be derived from the EUI-64 of the interface yo want to reach, but it is derived from an EUI-64.  Otherwise, u would be set to 0.
> 

Same understanding.
u=1 has a meaning that shouldn't be negated now.

> Aside from anything else, I do not see a motivation for changing the rule.

The rule concerning the u=1 can advantageously be completed with new uses (provided they don't conflict wit previous uses).

Regards,
RD

> But why change the rule we have?  Is there a problem with the current rule that I am missing?
> 
> Yours,
> Joel
>

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 03 Feb 2013 11:43:56 +0000

>> Aside from anything else, I do not see a motivation for changing the rule.

Actually, I don't think that is what the draft proposes. What it proposes
is that we delete the fiction that the bit has any meaning after it arrives
in an IID. It seems to be that fiction that causes confusion, not the
rule about how to generate Modified EUI-64 format from a MAC address.

Quoting a wise colleague, "magic bits are almost never worth the pain."

To say it again in different words, u==1 does not prove that an IID is
universally unique and u==0 does not prove that an IID is locally unique.
So it's fine to specify methods for generating the u bit, but it is
incorrect to draw firm conclusions based on its value.

    Brian

---

From: Ray Hunter <[email-masked]>
Date: Sun, 03 Feb 2013 14:55:32 +0100

Brian E Carpenter wrote:
>>> organizations are generating OUIS with u=)
>>>
>>> Cheers,
What "uniqueness" is strictly required for correct operation of IPv6?
If the competing technologies can never share an L2 link, what's the
problem?

IMVHO We should be careful what semantics we import from other standards
bodies, and only do this explicitly.

Looking at various alternatives for the semantics of IETF defined flags:

u = deprecated. EUI64 MAY be used in generation of IIDs. DAD SHOULD be
performed for all unicast addresses.
A distinct possibility in my book. Reasoning: IIDs are only tie breakers
per link. Collisions happen. Deal with it.

u==1 => derived from one (of potentially many) mapping schemes based on
a universal token, and therefore nodes MAY skip performing DAD on all
link types.
Also seems reasonable. Some might even think useful.

u==1 && g==0  => IEEE EUI64 with IEEE registered OUI on all link technology
Is probably too much (and unnecessary for correct functioning of IPv6 AFAIK)
Do we really want to tell everyone who wants to produce links that
supports IPv6 that they should obtain an OUI from the IEEE, or force
them to use u=0 when generating addresses? What value does this
restriction add for the IETF?

u == 1 && g==0 => IEEE EUI64 with IEEE registered OUI, but only for IPv6
unicast addresses and only on IEEE-defined link technology.
Would be fine by me, and current practice AFAIK

u==1 && g==1 => reserved for future use by the IETF for generating
addresses on all technologies for both unicast and multicast
Is currently a possibility. I wouldn't object.

Beyond that, if you want a Universally Unique Identifier you should
probably be looking at rfc4122, rather than abusing/re-using IID's for
this function.
>> protocols that can perform mapping/registration of e.g. DUID <=L3 <=>
>> L2 bindings, such as
>>>> In any case, and more important in my understanding, this doesn't change that any IID having u=can never conflict with IEEE-derived IIDs, be they duplicated or not. A clarification on this would IMHO be useful.
>>> I have a problem with any assumption that u==> global uniqueness, or
>>> u==> IEEE EUI64 with IEEE administered OUI.
>>>
>>> Note the complete absence of text like "when u= the IID SHOULD/MUST be
>>> the u=g=1 case in IETF documents would not fit with the existing IEEE
>>> definition of EUI64, where u=g=1 is clearly a globally administered
>>>> AFAIK, it means that *if u=he structure of other bits has to be universally specified. This is used so far for IEEE-derived IIDs. It can advantageously be used for other technologies, as foreseen in RFC4291 itself. 4rd is just the first proposed new use.
>>>>
>>>>
>>>> - For all addresses subject to SLAAC, all IETF technologies are constrained by the u-bit meaning of RFC4291. If u=ll other bits have no recognizable structure; if u if all other bits have a recognizable 
>>>> The sentence of RFC 4291 about future technologies ((*) above) is, in my understanding and if taken rigorously, less open than it can be concerning future technologies. It is sufficient that IIDs of new technologies using u=ve a universally recognizable structure. There IID scopes can have a non-universal scope without breaking anything. Your draft can be a place to clarify this.
>>>>
>>>> All currently specified randomizations concern IIDs that have u=one can conflict with formats  specified for u=1 IIDs.
>>>>
>>>> Regards,
>>>> RD
>>>>
>>>>
>>>>
>>>>> Thanks!
>>>>>
>>>>> Cheers,
>>>>> -- 
>>>>> Fernando Gont
>>>>> SI6 Networks

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 03 Feb 2013 11:07:20 -0500

I presume I am misunderstanding you Brian.
You seem to be saying that because some liet coul violate the spec, and 
set u==1 on something that did not come from an EUI-64 on that device, 
then it ollows that the spec is meaningless.
It is true for almost all our specs tat they can be ignored, bent, or 
violated, and mostly, things still work.
That does not make the specs or their requirements meaningless.

The fact that you can make a u==0 IID from anything you want is 
irrelevant to the question of what u==1 means.

Is there an implementation in the real world that is violating the spec 
by generating u==1 from something other than EUI values?  I wuld be very 
surprised, but if you know of such, and there is a reason they di it, 
that would e useful information.

As far as I can tell, all of the confusion regarding the spec has been 
in what else we are allowed to specify.  So having a clearer spec would 
help us.  But that, by itself, even with pithy quotes, is not a reason 
to change an existing IETF agreement.

Is there a problem with the current rules?

Yours,
Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 03 Feb 2013 12:26:43 -0500

To a significant degree Randy, I agree with you in your comment about 
magic bits.  If I were designing IPv6 from scratch (counter-factual in 
so may ways at once) I would not do it that way.

But, unless there is an actual problem with the design the IETF has 
adopted, I am reluctant to change it "just because".

Yours,
Joel

On 2/3/2013 4:46 AM, Randy Bush wrote:
...

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 03 Feb 2013 19:36:02 +0000

> adopted, I am reluctant to change it "just because".

Which is why the draft actually proposes nothing that would change
any running code.

    Brian

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 03 Feb 2013 14:39:33 -0500

> Which is why the draft actually proposes nothing that would change

But it does propose to change the spec.  Why?  What problem does 
changing the spec solve?

Yours,
Joel

---

From: Mark Smith <[email-masked]>
Date: Sun, 3 Feb 2013 12:25:14 -0800 (PST)

----- Original Message -----
> From: Ray Hunter <[email-masked]>
> To: Brian E Carpenter <[email-masked]>
> Cc: Fernando Gont <[email-masked]>; 6man 6man-wg <[email-masked]>
> Sent: Monday, 4 February 2013 12:55 AM
> Subject: Re: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt]
> 
> Brian E Carpenter wrote:

> per link. Collisions happen. Deal with it.

Other than the "u = deprecated" I think this is already the status quo.

Perhaps the confusion is because in RFC4291 it refers to the IID being in "Modified EUI-64 format", which implies that IID must be derived from an EUI-64. That then implies the the IID then also inherits the properties of an EUI-64 i.e. the IID is globally unique if the EUI-64 is assumed to be.

In the past I've found this confusing because IPX and XNS also derived the layer 3 interface identifier from the layer 2 interface identifier, and tightly coupled them together such that there was no ARP/ND protocol - at the last hop the layer 3 interface identifier was copied into the layer 2 header destination address for delivery. So the question at the time I had was if IPv6 IIDs are derived from EUI-64s, which were usually derived from EUI-48s, why bother with a layer 3 to layer 2 address resolution protocol (and then think maybe it'd fix the ND DoS Attack problem, but it doesn't, it just shifts it to layer 2)? I then realised that deriving the IID from an EUI-64 was just an IID generation algorithm, nothing more. DAD is necessary because even though the IID might appear to be unique because the EUI-64 should be unique, it may not be (https://speakerdeck.com/hdm/derbycon-2012-the-wild-west)

> Also seems reasonable. Some might even think useful.

I've had the unfortunate experience in the distance past of troubleshooting 5 duplicate IPv4 addresses on a link when some software developers decided to duplicate their TCP/IP network configuration settings on their PCs. This was before RFC1918, so the addresses were globally unique, and before DAD was implemented in desktop PCs. It's was very confusing because the only symptom, other than things randomly failing, was constantly changing MAC addresses in the ARP table of the router. DAD would have saved a huge amount of time in this scenario.

So what I don't understand is why people seem to want to skip performing DAD? It's only a few multicast packets, and ensures that if there are duplicate addresses, the cause is immediately obvious, and also doesn't disrupt the host that is already using that address. The savings of avoiding DAD don't seem to be worth the benefits to me.

> restriction add for the IETF?

I don't think we should, as it would too tightly couple layer 3 with a particular layer 2 addressing scheme.

> Would be fine by me, and current practice AFAIK

That would seem to make the u == 1 bit really the IEEE Address == 1 bit. Going down that path would suggest also giving other parties who allocate addresses their own bits if they want them e.g. an E.164 == 1 bit.

> probably be looking at rfc4122, rather than abusing/re-using IID's for

I think this would be a better option than tying layer 3 IID uniqueness to one layer 2 address uniqueness scheme. Even then I'd argue that DAD needs to be performed.

>>>>>  I agree that this is a good time to clarify uses of u and g 
> bits, and support the initiative Sheng and yourself has taken.
>>>>>  It completely eliminates collisions for all devices that comply 
> with IEEE specifications, and dramatically reduces it where some vendors have 
> reused some IEEE MAC addresses.
>>>>>  If two devices have the same IEEE MAC address on a link, they 
> have a problem at the link layer, even before having one at the IP layer, and 
> has to be fixed. 
>>>>> 
>>>>>  In any case, and more important in my understanding, this 
> doesn't change that any IID having u=can never conflict with IEEE-derived 
> IIDs, be they duplicated or not. A clarification on this would IMHO be useful.
>>>>>  AFAIK, it means that *if u=he structure of other bits has to be 
> universally specified. This is used so far for IEEE-derived IIDs. It can 
> advantageously be used for other technologies, as foreseen in RFC4291 itself. 
> 4rd is just the first proposed new use.
>>>>> 
>>>>> 
>>>>>  - For all addresses subject to SLAAC, all IETF technologies are 
> constrained by the u-bit meaning of RFC4291. If u=ll other bits have no 
> recognizable structure; if u if all other bits have a recognizable 
>>>>>  - For addresses that aren't subject to SLAAC like, for 
> instance, those of inter-router links of RFC6164, the RFC4291 structure of /64 
> IIDs isn't applicable. A clarification on this would IMHO be useful.
>>>>> 
>>>>> 
>>>>>  Now, a new point:
>>>>>  The sentence of RFC 4291 about future technologies ((*) above) 
> is, in my understanding and if taken rigorously, less open than it can be 
> concerning future technologies. It is sufficient that IIDs of new technologies 
> using u=ve a universally recognizable structure. There IID scopes can have a 
> non-universal scope without breaking anything. Your draft can be a place to 
> clarify this.
>>>>> 
>>>>>  Note that this point is made in general, as a contribution to 
> clarify the u/g issue, not because it would concern 4rd. IIDs of 4rd are  
> universally unique (each one contains a globally unique IPv4 address, plus a CNP 
> field which has different values for all CEs that share this address).
>>>>>   
>>>>> 
>>>>>>  Section 3:
>>>>>  All currently specified randomizations concern IIDs that have 
> u=one can conflict with formats  specified for u=1 IIDs.
>>>>> 
>>>>>  Regards,
>>>>>  RD
>>>>> 
>>>>> 
>>>>> 
>>>>>>  Thanks!
>>>>>> 
>>>>>>  Cheers,
>>>>>>  -- 
>>>>>>  Fernando Gont
>>>>>>  SI6 Networks
>>>>>>  Administrative Requests: 
> https://www.ietf.org/mailman/listinfo/ipv6
>>>>>>

---

From: joel jaeggli <[email-masked]>
Date: Sun, 03 Feb 2013 12:56:55 -0800

> But it does propose to change the spec.  Why?  What problem does 
If it prevents someone from ascribing new utility to these bit(s) in the 
future that seems like a worthwhile goal. While I'm sure that we can 
come up with new and different was to apply meaning to global unicast 
addresses I think the world is a simpler place when we don't.

joelja

---

From: Roger Jørgensen <[email-masked]>
Date: Sun, 3 Feb 2013 22:40:31 +0100

On Sun, Feb 3, 2013 at 9:56 PM, joel jaeggli <[email-masked]> wrote:
>> But it does propose to change the spec.  Why?  What problem does changing
>> the spec solve?
>
> future that seems like a worthwhile goal. While I'm sure that we can come up
> with new and different was to apply meaning to global unicast addresses I
> think the world is a simpler place when we don't.

KISS is always a good approach - Keep It Stupid Simple, or Simple Stupid.

(or in short, special meaning attached to bits seems to cause more
confusion than good)

And on the topic of DAD vs assume uniqueness - I learned this from an
earlier colleague
"To Assume is to make an Ass out of you and Me"

-- 

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

---

From: Randy Bush <[email-masked]>
Date: Mon, 04 Feb 2013 09:41:43 +0900

> adopted, I am reluctant to change it "just because".

i know.  ipv6 is perfect, widely deployed, and unchangable.  i hope we
all like v4 nat.

randy

---

From: Christian Huitema <[email-masked]>
Date: Mon, 4 Feb 2013 02:00:35 +0000

> i know.  ipv6 is perfect, widely deployed, and unchangable.  i hope we all like v4 nat.

I can find many reasons to remove the magic from the U and G bits. I personally ran into the U/G bit issues in RFC 4380 (Teredo) and  RFC 6052 (IPv4-embedded IPv6 addresses). In both cases, the design would have been simpler if we had not try to maintain the fiction of the U and G bits. And CGA could definitely benefit from 2 additional bits of entropy. So this is not a change "just because." 

-- Christian Huitema

---

From: Randy Bush <[email-masked]>
Date: Mon, 04 Feb 2013 11:18:29 +0900

> I can find many reasons to remove the magic from the U and G bits. I
> personally ran into the U/G bit issues in RFC 4380 (Teredo) and RFC
> 6052 (IPv4-embedded IPv6 addresses). In both cases, the design would
> have been simpler if we had not try to maintain the fiction of the U
> and G bits. And CGA could definitely benefit from 2 additional bits of
> entropy. So this is not a change "just because."

a prospective implementor looks at ipv6 and sees a whole bunch of twisty
passages of useless second system syndrome.  there are more damn options
than the chicago mercantile exchange.  and as there is no *strong* pull
from the market, all our pleas do not transform income you can sell to
your management.

when multiple layers of ipv4 nat is financially more attractive than our
product, we have a very serious problem.  we need to wipe the lipstick
off the pig and start selling straightforward port chops.

except i fear it is far too late.

randy

---

From: Hesham Soliman <[email-masked]>
Date: Mon, 04 Feb 2013 15:12:54 +1100

>personally ran into the U/G bit issues in RFC 4380 (Teredo) and  RFC 6052
>(IPv4-embedded IPv6 addresses). In both cases, the design would have been
>simpler if we had not try to maintain the fiction of the U and G bits.
>And CGA could definitely benefit from 2 additional bits of entropy. So
>this is not a change "just because."

=> +1 on CGA and Teredo. I never agreed/understood the need for u/g bits.
The concept was flawed IMHO. I respect the questioning of timing but on
principle those two flags are a bad idea.

Hesham

---

From: [email-masked]
Date: Mon, 04 Feb 2013 08:52:41 +0100 (CET)

> I can find many reasons to remove the magic from the U and G bits. I personally ran into the U/G bit issues in RFC 4380 (Teredo) and  RFC 6052 (IPv4-embedded IPv6 addresses). In both cases, the des…

Fully agreed.

Another point in favor of removing the magic: RFC 4291 explicitly 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."

but later in the same chapter 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."

And indeed, on the routers where I have tried, I am able to configure
static IPv6 addresses with no regard to the u/g bits.

In other words, any special meaning of the u/g bits is just fiction -
there is no enforcement or guarantee of any kind.

Steinar Haug, AS 2116

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 04 Feb 2013 08:16:49 +0000

> there is no enforcement or guarantee of any kind.

Right. The draft may be clumsily expressed so far, but that is the point.

I think we know how we have to improve the draft to make these things
more clear. Please give us a little time, since my co-author is on vacation
for the Chinese New Year holidays.

     Brian

---

From: Rémi Després <[email-masked]>
Date: Mon, 4 Feb 2013 09:38:38 +0100

Brian, Bob,

 2013-02-03  12:43, Brian E Carpenter <[email-masked]> :

> is that we delete

> the fiction that the bit has any meaning after it arrives
> in an IID.

Serious disagreement with the extreme view that, today, the u bit has no meaning.
See (*) and (**) below.

> It seems to be that fiction that causes confusion, not the

Agreed.

But the u bit isn't "magic". 
It is just a bit whose function has been specified (and used, see (*) below).

> universally unique

Agreed.

(*) It remains that IIDs having u=1 SHOULD be unique, i.e. with rare enough exceptions. This is somewhat similar to the expectation that ULA collisions shouldn't be seen).

This theoretical unicity has been extensively used to assign stable IIDs, without administrative action, to hosts  that have no privacy constraints requiring the opposite.  

If our understanding differs on this, I suppose we should go further into it. 

> and u==0 does not prove that an IID is locally unique.

Agreed.

> incorrect to draw firm conclusions based on its value.

Disagreed.

Here is one "firm" conclusion, and a useful one AFAIK to "allow development of future technology that can take advantage of interface identifiers with universal scope":
(**) "All IIDs that comply with RFC 4291, that have u=1, and that are based on an IEEE MAC address, also have g=0 and bits 24-39 = 0xFE."
Disagreeing on this would need an explanation.

Conclusion: your ug draft, which is IMHO welcome to clarify what seems misunderstood, must be clear about issue (*) and (**) above, one way or another.

Steps backward without carefully checked justifications should be avoided.

Regards,
RD

---

From: Rémi Després <[email-masked]>
Date: Mon, 4 Feb 2013 09:46:58 +0100

2013-02-03 à 20:39, Joel M. Halpern <[email-masked]>  :

> But it does propose to change the spec.  Why?  What problem does changing the spec solve?

Same question.

RD

---

From: Rémi Després <[email-masked]>
Date: Mon, 4 Feb 2013 10:11:29 +0100

Hi, Roger,

Please see inline.

>> think the world is a simpler place when we don't.

It depends on what is done with the new design, especially if it is backward compatible and optional.

The question that started this discussion is whether reserving a currently unused IID range having u=1  is compatible with the IPv6 addressing architecture (i.e. RFC 4291). 
AFAICT, the answer is YES.
Changing RFC 4291 to make it become a NO would have consequences well beyond this new request. 

Agreed.

> (or in short, special meaning attached to bits seems to cause more

- Not a consequence of KISS.
- Changing a specification without a pressing need, and although it has been used, isn't a way to increase confidence in any design. IPv6 needs confidence.

> And on the topic of DAD vs assume uniqueness - I learned this from an

No one proposes to abandon DAD!
The point is that, while a specification *clarification* on u/g appears to be useful, specification *change* would be harmful.

Regards,
RD

---

From: Rémi Després <[email-masked]>
Date: Mon, 4 Feb 2013 10:42:01 +0100

Randy, 

We have in common, as you know, the objective of IPv6 promotion, and that of NATs elimination as much as possible.

In this respect, changing now the IPv6 specification for hosts that configure IIDs having u=1, although no serious need has been identified, and this specification has ben used, would be in my understanding very counterproductive: stability of already used specifications is important for their success.

=> Concerning u/g bits:
- OK to clarify what can easily be misunderstood
- NOK to change the substance of the specification
Hope you can agree.

Regards,
RD

---

From: Fernando Gont <[email-masked]>
Date: Mon, 04 Feb 2013 06:41:18 -0300

> AFAICT, the answer is YES.

I believe that the original question really was "whether it makes sense
to reserve an unused IID range for 4rd".

As noted by Ran Atkinson, since 4rd is an experimental document, it
seems more appropriate to separate a *shared* range for this kind of
experiment, rather than assign an IID range to 4rd.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Mon, 04 Feb 2013 05:13:40 -0300

> per link. Collisions happen. Deal with it.

We currently do not deal with them.

With start with the (fictional) assumption that we can get unique
addresses if we based our IIDs on (allegedly) unique MAC addresses.

But e.g. virtualization software can generate duplicate mac addresses.

And in the presence of such failures, SLAAC/DAD fails (in some
implementations, when DAD fails for link-local address, you need to reboot)

> Also seems reasonable. Some might even think useful.

Reality indicates that even when deemed as "unique", those tokens are
not really universal. So if you skip that, you might end up in a slaac
failure.

Therefore, in practice you cannot really skip that. And if DAD fails,
you must have some algorithm in place to solve the problem. Most likely,
such algorithm is going to generate some random ID of some sort... in
which case we should probably ask ourselves: why are we generating the
addresses with an embedded IEEE identifier for the first try, and with a
completely different scheme if DAD fails?

Agreed.

> Would be fine by me, and current practice AFAIK

But... is there any value in continuing with this?

Cheers,

---

From: Fernando Gont <[email-masked]>
Date: Mon, 04 Feb 2013 06:54:46 -0300

On 02/04/2013 05:38 AM, Rémi Després wrote:
> 
> (*) It remains that IIDs having u=1 SHOULD be unique, i.e. with rare
> enough exceptions. This is somewhat similar to the expectation that
> ULA collisions shouldn't be seen).
> 
> This theoretical unicity has been extensively used to assign stable
> IIDs, without administrative action, to hosts  that have no privacy
> constraints requiring the opposite.

If anything, privacy should be an "opt out", rather as an "opt in".

In scenarios where privacy matters a lot, if our default policy is "no
privacy", those users "opting in" for privacy would be flagged as
"suspicious" just for the act of "opting in".

Cheers,

---

From: Rémi Després <[email-masked]>
Date: Mon, 4 Feb 2013 10:56:39 +0100

> to reserve an unused IID range for 4rd".

A 4rd reserved range, for 4rd activation to never require IPv6 renumbering, has been for long in the specification studied in Softwire.

Here is what Suresh said in the question to 6man:
"There were some concerns raised in softwire about whether such addresses are actually compatible with the IPv6 addressing architecture. Whether this is actually compatible with the IPv6 addressing architecture is outside the scope of the softwire wg. Hence we would like to hear the 6man wg's perspective on this."

> experiment, rather than assign an IID range to 4rd.

As already answered to Ran:
"Making the reservation for one design, experimental or not, is a guarantee that no future design with conflict with it, experimental or not."
If you disagree, please explain.

In any case, this comment isn't about compatibility of the 4rd range with the IPv6 addressing architecture. 

Regards,
RD

---

From: Rémi Després <[email-masked]>
Date: Mon, 4 Feb 2013 11:06:06 +0100

> If anything, privacy should be an "opt out", rather as an "opt in".

Same view.
IIDs derived by default from IEEE assigned MAC addresses is a good to have.

RD

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 04 Feb 2013 13:08:47 +0000

Rémi,

> Changing RFC 4291 to make it become a NO would have consequences well beyond this new request. 

Indeed. That is not in any way proposed by the draft. Rather to the contrary,
in fact, since one of the co-authors of 4rd is my co-author.

   Brian

---

From: Fernando Gont <[email-masked]>
Date: Mon, 04 Feb 2013 07:37:01 -0300

On 02/04/2013 06:56 AM, Rémi Després wrote:
>
>> I believe that the original question really was "whether it makes
>> sense to reserve an unused IID range for 4rd".
> 
> A 4rd reserved range, for 4rd activation to never require IPv6
> renumbering, has been for long in the specification studied in
> Softwire.

But my understanding is that softwires didn't adopt 4rd?

If 4rd is published as "experimental", then it doesn't make sense to
permanently assign an address range to it.

>> As noted by Ran Atkinson, since 4rd is an experimental document,
>> it seems more appropriate to separate a *shared* range for this
>> kind of experiment, rather than assign an IID range to 4rd.
> 
> As already answered to Ran: "Making the reservation for one design,
> experimental or not, is a guarantee that no future design with
> conflict with it, experimental or not." If you disagree, please
> explain.

We have several shared resources (ICMPv6 types, etc.) for experiments.
Why should this be an exception?

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Mon, 04 Feb 2013 07:39:38 -0300

> IIDs derived by default from IEEE assigned MAC addresses is a good to have.

Such IIDs do not preserve privacy, so... are you suggesting that they
should not be the default algorithm for selecting IIDs with SLAAC?

Cheers,

---

From: Fernando Gont <[email-masked]>
Date: Mon, 04 Feb 2013 07:32:27 -0300

On 02/04/2013 06:42 AM, Rémi Després wrote:
> In this respect, changing now the IPv6 specification for hosts that
> configure IIDs having u=1, although no serious need has been
> identified, and this specification has ben used, would be in my
> understanding very counterproductive: stability of already used
> specifications is important for their success.

I strongly disagree. For many reasons, including:

1) What's broken, is broken. And if it's known to be broken, it should
be fixed.

2) We do maintenance of widely-implemented, widely-deployed protocols.
So I'm not sure why we should be scared about changing stuff in v6
(particularly when we're still at a point in which the v6 traffic is
very small)

3) Whatever changes are needed should be done soon. The more we wait,
the more expensive they'll become.

Thanks,

---

From: Jouni Korhonen <[email-masked]>
Date: Mon, 4 Feb 2013 17:45:34 +0200

> 1) What's broken, is broken. And if it's known to be broken, it should

It is awkward but not broken imho, so in this respect I would think twice
changing RFC4291. However, I do agree Randy about magic bits and the pain
involved. Actually, a lot IPv6 business recently has been around adding
magic to IPv6 addressing, which I kind of find uncomfortable..

My personal take on this is that we keep things as they are now. It would
be cool to have all IIDs as a binary blob but.. that does not give a reason
to start changing the addressing architecture at this point.

Brian's document could be a good place to hash out the "confusing" points
of the magic bits - as a plain discussion document without a recommendation
about next steps.

- Jouni

(hmm.. where this conservative me came from ;-)

---

From: Rémi Després <[email-masked]>
Date: Mon, 4 Feb 2013 17:38:04 +0100

> But my understanding is that softwires didn't adopt 4rd?

4rd is adopted (on experimental track) under the only condition that 6man confirms that it doesn't conflict with the IPv6 addressing architecture.

> permanently assign an address range to it.

See (*) below.

If 4rd is eventually deprecated, the range will be freed.
If it isn't deprecated, the range will remain reserved (which, as you know, is only 1/16384 of available IIDs having u=g=1, i.e. nothing to be alarmed by).

If and when IPv4 is deprecated, the reservation will become meaningless.
As long as IPv4 isn't deprecated, any solution that has distinctive properties for IPv4 service across IPv6-only clouds, is relevant. 

(*)
> Why should this be an exception?

All other experiment, I suppose, had enough with what has been reserved so far.
As far as 4rd is concerned, it needs an IID range that cannot conflict with any host address that complies with RFC 4291. 

Regards,
RD

---

From: Rémi Després <[email-masked]>
Date: Mon, 4 Feb 2013 18:00:14 +0100

> 1) What's broken, is broken. And if it's known to be broken, it should

One has to come with a proof that reserving u=1 for universally specified IID formats is harmful.

None has been seen.
OTPH, 4rd is the first instance that shows it can be beneficial beyond its current application to IEEE derived IIDs.  

> (particularly when we're still at a point in which the v6 traffic is

Different understanding.
To me, standard modifications need serious reasons, and much caution.

RD

---

From: Doug Barton <[email-masked]>
Date: Mon, 04 Feb 2013 09:37:52 -0800

On 02/04/2013 12:38 AM, Rémi Després wrote:
> It remains that IIDs having u=1 SHOULD be unique, i.e. with rare enough exceptions. This is somewhat similar to the expectation that ULA collisions shouldn't be seen).
>

What software exists that makes determinations based on the u bit?

How would that software be impacted if the u bit were suddenly be devoid 
of meaning?

I am of course assuming that DAD would still be in play for dynamically 
assigned addresses, which it seems we are all in agreement on.

Doug

---

From: Fernando Gont <[email-masked]>
Date: Mon, 04 Feb 2013 14:48:46 -0300

> It is awkward but not broken imho, so in this respect I would think twice

FWIW, my comment was in response of the general statement "stability of
already used specifications is important for their success".

Actually, I'm not opposed to "stable specifications", but about
resistance to change/fix/improve those things just because to maintain
the status quo.

> magic to IPv6 addressing, which I kind of find uncomfortable..

Not sure what you mean. For instance,
draft-ietf-6man-stable-privacy-addresses doesn't change the
architecture, but simply is an alternative algorithm that fits in the
existing architecture.

Cheers,

---

From: Ole Troan <[email-masked]>
Date: Mon, 4 Feb 2013 19:49:47 +0100

Remi,

> 4rd is adopted (on experimental track) under the only condition that 6man confirms that it doesn't conflict with the IPv6 addressing architecture.

that of course doesn't mean that softwire will not publish 4rd if the authors were to accept the advice from 6man.

cheers,
Ole

---

From: Jouni Korhonen <[email-masked]>
Date: Mon, 4 Feb 2013 22:50:30 +0200

> Actually, I'm not opposed to "stable specifications", but about

Good.

> resistance to change/fix/improve those things just because to maintain

Understand. But within this specific ug topic I am still not convinced
myself that what we have now is broken or would even need a facelift..

> draft-ietf-6man-stable-privacy-addresses doesn't change the

Your draft is just fine since it is by the RFC4291 rules. I should have
been more precise with my above comment, which was a generic comment about
the desire to specify something that ends up to a special IPv6 address
handling or configuration just because we have 'so many bits to play with'.

- Jouni

---

From: Randy Bush <[email-masked]>
Date: Tue, 05 Feb 2013 12:12:38 +0900

> In scenarios where privacy matters a lot, if our default policy is
> "no privacy", those users "opting in" for privacy would be flagged
> as "suspicious" just for the act of "opting in".

and 82.3% would not realize they needed to opt out.

i would think that, in general, across the ietf protocols, privacy
preservation would be the desired default.

randy

---

From: Doug Barton <[email-masked]>
Date: Mon, 04 Feb 2013 20:50:25 -0800

> preservation would be the desired default.

Agreed. I have never understood why the default for this has always been 
"off." Given that most implementations have ignored the RFC(s) and 
enabled it by default anyway, I think it's time that we acknowledged 
reality (both in the sense of what people are doing, and in the sense 
that it's clearly working).

---

From: Rémi Després <[email-masked]>
Date: Tue, 5 Feb 2013 14:57:24 +0100

Hi, Doug,

Please see inline.

> What software exists that makes determinations based on the u bit?

(*) Major OSes can assign IIDs derived from IEEE MAC addresses of their LAN adapters (if not by default, at least as a possibility). They do it because of what IEEE and IETF have specified, each one for its own domain, concerning their respective u bits. 

With these specifications, it is impossible on a SLAAC link that two hosts that have universal-scope addresses (necessarily different if they communicate at the MAC layer), would have conflicting IIDs at the IP layer if they derive them from MAC addresses.

> 
> How would that software be impacted if the u bit were suddenly be devoid of meaning?

Hosts would become free to assign arbitrary IIDs having u=1, breaking applicability of (*) above.

> 
> I am of course assuming that DAD would still be in play for dynamically assigned addresses, which it seems we are all in agreement on.

Sure (agreement confirmed).

Hope it clarifies.
RD

---

From: [email-masked]
Date: Tue, 05 Feb 2013 15:01:56 +0100 (CET)

> With these specifications, it is impossible on a SLAAC link that two hosts that have universal-scope addresses (necessarily different if they communicate at the MAC layer), would have conflicting I…

Impossible if the MAC addresses are indeed unique. That is correct for
*almost* all cases. But not 100%.

Steinar Haug, AS 2116

---

From: Rémi Després <[email-masked]>
Date: Tue, 5 Feb 2013 15:11:28 +0100

> *almost* all cases. But not 100%.

They are different 100% of cases at the IP layer if they are different at the MAC layer (which is needed for communication at this layer).
OK?

RD

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 05 Feb 2013 14:36:33 +0000

> They are different 100% of cases at the IP layer if they are different at the MAC layer (which is needed for communication at this layer).

Not if the same MAC address appears on two different subnets in the same
site. This would work from a conventional IPv6 point of view, but it would
immediately demonstrate that the u bit does not mathematically guarantee
uniqueness.

There has been discussion recently in MIF of scenarios where the same
IID would appear intentionally on different interfaces of the same device.

It is not the process of generating IIDs that is a problem - that is
well defined. It is assuming after they have been generated that the
u/g bits have meaning that is problematic. (Which is also why the
solution of a reserved range makes sense for 4rd.)

   Brian

---

From: Warren Kumari <[email-masked]>
Date: Tue, 5 Feb 2013 09:56:04 -0500

> *almost* all cases. But not 100%.

Yup, there have been multiple instances where NIC vendors have accidentally (or possibly intentionally) recycled MACs. 

And, unfortunately with the increase in virtulization (and cloning of virtual machines) the chances of identical MACs increases dramatically… 

W

-- 
"I think it would be a good idea." 
- Mahatma Ghandi, when asked what he thought of Western civilization

---

From: Rémi Després <[email-masked]>
Date: Tue, 5 Feb 2013 16:51:17 +0100

Bob,

It seems the general discussion on u/g-bits clarification is going to be long.

Fortunately it also appears, for instance in the following, that compatibility of the 4rd IID-range with the IPv6 addressing architecture doesn't depend on this work being completed.

2013-02-05  15:36, Brian E Carpenter <[email-masked]> :
...
> u/g bits have meaning that is problematic. (Which is also why

> the

Unless I missed something conclusions that the 4rd IID range DOES NOT conflict with the IPv6 addressing architecture have been expressed by Brian Carpenter, Joel Halpern, Sheng Jiang, Gang Chen, and myself.

Several opinions against a 4rd-range reservation have also been expressed, but they concern the purpose of 4rd, or its experimental status, or personal feelings against one more specification. They are not about technical compatibility with the IPv6 addressing architecture. 

Keeping the 4rd answer separate from the general u/g bit discussion will permit, I hope, to now finalize this answer asap. 

Best regards,
RD

---

From: joel jaeggli <[email-masked]>
Date: Tue, 05 Feb 2013 08:02:09 -0800

> And, unfortunately with the increase in virtulization (and cloning of virtual machines) the chances of identical MACs increases dramatically…
or because you recycled your vrrp6 interface config.

---

From: joel jaeggli <[email-masked]>
Date: Tue, 05 Feb 2013 08:10:38 -0800

> immediately demonstrate that the u bit does not mathematically guarantee
that describes vlans on most ethernet switches...

e.g.

Vlan1729 is up, line protocol is up (connected)
   Hardware is Vlan, address is 001c.7310.8864 (bia 001c.7310.8864)
   MTU 1500 bytes
   Up 217 days, 16 hours, 52 minutes, 58 seconds
Vlan1730 is up, line protocol is up (connected)
   Hardware is Vlan, address is 001c.7310.8864 (bia 001c.7310.8864)
   MTU 1500 bytes
   Up 217 days, 16 hours, 52 minutes, 58 seconds
Vlan1731 is up, line protocol is up (connected)
   Hardware is Vlan, address is 001c.7310.8864 (bia 001c.7310.8864)
   MTU 1500 bytes
   Up 217 days, 16 hours, 52 minutes, 58 seconds
Vlan1732 is up, line protocol is up (connected)
   Hardware is Vlan, address is 001c.7310.8864 (bia 001c.7310.8864)
   MTU 1500 bytes
   Up 217 days, 16 hours, 52 minutes, 58 seconds
Vlan1792 is up, line protocol is up (connected)
   Hardware is Vlan, address is 001c.7310.8864 (bia 001c.7310.8864)
   MTU 1500 bytes
   Up 217 days, 16 hours, 52 minutes, 58 seconds
Vlan1793 is up, line protocol is up (connected)
   Hardware is Vlan, address is 001c.7310.8864 (bia 001c.7310.8864)
   MTU 1500 bytes
   Up 217 days, 16 hours, 52 minutes, 58 seconds
Vlan4094 is up, line protocol is up (connected)
   Hardware is Vlan, address is 001c.7310.8864 (bia 001c.7310.8864)
   MTU 1500 bytes
   Up 336 days, 15 hours, 53 minutes, 49 seconds

---

From: Rémi Després <[email-masked]>
Date: Tue, 5 Feb 2013 17:51:24 +0100

Brian,

(a) The fact that IEEE MAC addresses are recycled by some vendors is well understood.
Please be sure I don't ignore it.

(b) I am also well convinced that u=1 isn't a "mathematical guarantee" of uniqueness. 

To me, what is important is agreeing that the 4rd IID range makes sense. 
(Despite my understanding that the point I had made below isn't contradictory with (a) and (b) above, I see no point in arguing more about it.)

Thanks,
RD

Le 2013-02-05 à 15:36, Brian E Carpenter <[email-masked]> a écrit :

> site.
> This would work from a conventional IPv6 point of view, but it would

---

From: "Bless, Roland (TM)" <[email-masked]>
Date: Tue, 05 Feb 2013 18:07:42 +0100

Hi all,

On 05.02.2013 16:51, Rémi Després wrote:
> Several opinions against a 4rd-range reservation have also been
> expressed, but they concern the purpose of 4rd, or its experimental
> status, or personal feelings against one more specification. They are
> not about technical compatibility with the IPv6 addressing
> architecture.
> 
> Keeping the 4rd answer separate from the general u/g bit discussion
> will permit, I hope, to now finalize this answer asap.

My personal summary is as follows:
- The u/g bits have no real meaning in an IID (though the original
  intention  of mapping EUI-64/48 addresses as modified EUI-64 into the
  IID may have been to preserve their meaning), so using them as
  indicator for the presence of a particular "IID format" seems to
  be not a good idea (see Brian's draft as well as Randy's "magic bits
  are almost never worth the pain").

- I feel uncomfortable with reserving another range in the IID space
  for 4rd, since it is not clear what implementations should do with
  it - building exceptions into implementations (e.g., martian IIDs)
  is error prone and may cause conflicts with future IID uses,
  even if 4rd is experimental.
  So I'm also sharing Ole's concerns here:
  http://www.ietf.org/mail-archive/web/ipv6/current/msg16976.html

- without knowing too many details of the 4rd solution I'd rather
  propose to use configured 4rd subnet-IDs as indicator that the
  IID has a special format: this would be IMHO far more reliable
  and consistent than relying on this "reserved IID range". Since 4rd
  will require configuration anyway, one can configure the right 4rd
  /64s. I'm aware of the counter arguments (j)(m) in
  http://www.ietf.org/mail-archive/web/ipv6/current/msg16949.html,
  i.e., "free choice of subnet prefixes at CE sites" and
  "IID assignments made before 4rd activation".
  But it is not clear to me how often this will be _actually_ the case
  in practice and whether it's worth to "sacrifice" IID space and IPv6
  flexibility for keeping these requirements. IPv6 is flexible enough
  to automatically reassign subnet prefixes or IIDs, thus I'm still
  not buying the arguments yet...

Regards,
 Roland

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Tue, 5 Feb 2013 14:55:22 -0600

+1

If a better alternative is devised for 4rd, as Roland proposes here, then can we deprecate the u/g bit usage? Seems to me that privacy addresses are preferable anyway, if not DHCP or statically assigned ones, so any importance assigned to u/g surely becomes a historical artifact?

Bert

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Bless, Roland (TM)
> Sent: Tuesday, February 05, 2013 12:08 PM
> To: [email-masked]
> Subject: Re: Keeping the 4rd-range issue separate from the general u/g
> discussion
> 
> Hi all,
>

---

From: Ole Troan <[email-masked]>
Date: Tue, 5 Feb 2013 22:42:55 +0100

> If a better alternative is devised for 4rd, as Roland proposes here, then can we deprecate the u/g bit usage? Seems to me that privacy addresses are preferable anyway, if not DHCP or statically ass…

indeed.
4rd tries to solve the problem of having a 4rd CE located behind the CPE (that receives the IPv6 delegated prefix).
the current  4rd solution is to try to share the on-link /64 that is also used by native hosts.

for a single shared IPv4 address, I believe a 4rd CE would require 2^16 addresses. (the last 16 bits are used for the CNP).
i.e. a /112.

the problematic assumption 4rd makes, is that it requires these addresses without having a mechanism to do duplicate address
detection.

what are the alternatives to a fixed reservation of the interface-id space proposed?

1) pick a separate /64 for the purpose of the 4rd function. an automated mechanism for prefix assignment is being worked
   on in homenet. (draft-arkko-homenet-prefix-assignment-03) 

2) defend the 4rd CE address space using DAD. pick 64K addresses out ::0:a.b:c.d:CNP.
    chances of a conflict are small, and you would be able to detect and defend those for nodes trying to take that address
    after the 4rd CE comes up. I wouldn't recommend doing DAD on every address first. so you may end up in a situation
    where you encounter a conflict while in operation. that should be possible to handle though.

3) remove the CNP feature that makes 4rd require so many addresses to function.
    
either of these are 
cheers,
Ole

---

From: Doug Barton <[email-masked]>
Date: Tue, 05 Feb 2013 15:45:07 -0800

> (*) Major OSes can assign IIDs derived from IEEE MAC addresses of their LAN adapters (if not by default, at least as a possibility). They do it because of what IEEE and IETF have specified, each on…

Yes, you've described reality. You haven't answered my questions.

> With these specifications, it is impossible on a SLAAC link that two hosts that have universal-scope addresses (necessarily different if they communicate at the MAC layer), would have conflicting I…

What makes the addresses unique are the unique MACs, not the u bit.

> Hosts would become free to assign arbitrary IIDs having u=1, breaking applicability of (*) above.

Faulty premise -> faulty conclusion.

> Sure (agreement confirmed).

To me, it clarifies that you don't have answers to my questions. Given 
that you cannot demonstrate any negative impact to un-defining the u 
bit, I wonder what the basis of your objection is.

Doug

---

From: Mark Smith <[email-masked]>
Date: Tue, 5 Feb 2013 19:28:53 -0800 (PST)

----- Original Message -----
> From: "[email-masked]" <[email-masked]>
> To: [email-masked]
> Cc: [email-masked]
> Sent: Wednesday, 6 February 2013 1:01 AM
> Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt]
> 
>>  With these specifications, it is impossible on a SLAAC link that two hosts 
> that have universal-scope addresses (necessarily different if they communicate 
> at the MAC layer), would have conflicting IIDs at the IP layer if they derive 
> them from MAC addresses.
> 

So I emailed HD Moore, who did the research which produced this slide, showing volumes of duplicate MAC addresses by vendor.

I asked him if he would be able sent me some info on the number of occurrences of duplication by MAC address. He sent me quite a bit of information, which I'll need to ask him how much he is willing for me to publish publicly. However, I'm confident that he'd be ok with the following.

Here is the top 10 list of occurrences of individual MAC addresses:

- 6987574
-  829787
-  787661
-  347282
-  292288
-  112580
-    95484
-    60295
-    60254
-    60125

Yes, that first number is 6 million.

This information was gleaned from NetBIOS Name Service information accessible over the Internet, so it is a subset of the possible actual numbers of duplicate MAC addresses.

---

From: Rémi Després <[email-masked]>
Date: Wed, 6 Feb 2013 11:01:20 +0100

> Yes, you've described reality. You haven't answered my questions.

Fair enough.
My answer is that no software that I know makes determination based on the u bit.

My point is that it isn't sufficient for the IETF u bit to have no meaning.
(a) It has what is specified in RFC 4291.
(b) No software I know creates IIDs having u = 1 without an IEEE-based OUI. 
    QUESTION: Do you know one?

> What makes the addresses unique are the unique MACs, not the u bit.

No disagreement on this.

> Faulty premise -> faulty conclusion.

This gets too subtle for my ability to understand which premises and which conclusion you talk about.

Let's go to basics. Are you suggesting to CHANGE the u bit significance?
- If no, no disagreement is IMHO worth debating
- If yes, we have indeed different opinions. See below.  

> To me, it clarifies that you don't have answers to my questions.

I have now answered the ONLY remaining question from you I have noticed.
Your turn to answer mine.

> Given that you cannot demonstrate any negative impact to un-defining the u bit, I wonder what the basis of your objection is.

The logic is the reverse. Before changing a standard, one needs to demonstrate it is indispensable.

QUESTIONS:  
(a) Which sentences of RFC 4291 you think MUST be changed?
(b) Why?

Please give your personal answers (not by reference to comments made by someone else).

Thanks,
RD

---

From: Mark Smith <[email-masked]>
Date: Wed, 6 Feb 2013 02:12:41 -0800 (PST)

Hi,

I was asked off list to clarify if the MAC addresses in the following list had the Locally Assigned bit switched off, i.e. don't have 0x02 in their first octet.

I've flagged the supposed globally unique ones below with a *. I've also flagged the same OUI /vendor with a & or + symbol when they appear at least twice. Finally, I've flagged ones where the OUI resolves to a name via the IEEE OUI PUBLIC LISTING web page with '='.

> - 6987574 *
> -  787661 *=
> -  347282 *
> -  292288 *
> -  112580 *&
> -    95484 *&
> -    60295 *+=
> -    60254 *+=
> -    60125 *+=

Regards,
Mark.

---

From: Rémi Després <[email-masked]>
Date: Wed, 6 Feb 2013 11:13:53 +0100

Bob,

This is, in my understanding,  what should be avoided in 6man, a debate on new 4rd modifications:
- The 4rd design has been stabilized for long in Softwire.
- The question to 6man is ONLY whether the proposed reserved range is compatible with the IPv6 addressing architecture.

Thanks,
RD

> De : Ole Troan <[email-masked]>
> Objet : Rép : Keeping the 4rd-range issue separate from the general u/g discussion
> Date : 2013-02-05 22:42
> À : "Manfredi, Albert E" <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> 
>> +1
>>

---

From: Ole Troan <[email-masked]>
Date: Wed, 6 Feb 2013 12:46:12 +0100

Remi,

the point I'm trying to make is that the future of 4rd does not depend on 6man accepting the request for a reserved space.
4rd can function very well without it.

cheers,
Ole

---

From: "Bless, Roland (TM)" <[email-masked]>
Date: Wed, 06 Feb 2013 13:07:22 +0100

Dear Rémi,

> - The question to 6man is ONLY whether the proposed reserved range is compatible with the IPv6 addressing architecture.

This isn't totally decoupled:
- if someone asks to introduce a "new format"/magic bits
  into the IID, my answer is:
  "this is bad for the IPv6 addressing architecture"
- if someone asks to reserve a larger range in the IID space
  my answer is:
  "this is bad for the IPv6 addressing architecture", because
  it is unclear what implementations should do with these
  specially reserved IIDs and how conflicts are resolved.
  It may be "compatible" with the current IPv6 addressing
  architecture, but it's a bad idea.
- Furthermore, your solution should IMHO not solely rely on
  testing the "IID format" or range, as there are probably more
  robust and reliable solutions as I pointed out.

Regards,
 Roland

---

From: Rémi Després <[email-masked]>
Date: Wed, 6 Feb 2013 14:52:48 +0100

>  "this is bad for the IPv6 addressing architecture"

As already said, the 4rd range only makes a first use of an existing RFC4291 provision:
"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."

New, indeed, but nothing magic.

>  architecture, but it's a bad idea.

- Once more: existing implementations have NOTHING to do (as long as they don't add 4rd support).
Expressed doubts on this should be justified by a detailed technical justification.
If you have any, let's look at it.

- The reserved range is a tool to AVOID conflicts. It isn't, like DAD, a tool to RESOLVE them when they occur. 
 
>  robust and reliable solutions as I pointed out.

This doesn't concern "compatibility with the IPv6 addressing architecture".

Regards,
RD

---

From: Fernando Gont <[email-masked]>
Date: Wed, 06 Feb 2013 13:16:16 -0300

> - The reserved range is a tool to AVOID conflicts. It isn't, like DAD, a tool to RESOLVE them when they occur. 

DAD *detects* them, but does not resolve them (for instance, the last
"D" stands for detection). As a datapoint, all the v6 implementations I
know of support DAD, yet they do not resolve DAD failures when one is
encountered.

Cheers,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Ole Troan <[email-masked]>
Date: Wed, 6 Feb 2013 17:28:28 +0100

Fernando,

> know of support DAD, yet they do not resolve DAD failures when one is

unless you call the fact that the duplicate address is not assigned to the interface, as resolving the problem.
with Remi's proposal, a duplicate address will not even be detected.

cheers,
Ole

---

From: Rémi Després <[email-masked]>
Date: Wed, 6 Feb 2013 17:37:02 +0100

Le 2013-02-06 à 17:16, Fernando Gont <[email-masked]> a écrit :

> "D" stands for detection).

Right, thanks for noting I failed to be as rigorous as I should.

I should have said DETECT as far DAD is concerned (I do know what it means!), or have referred to RFC 4941 (privacy extension) as a tool to RESOLVE duplicates if "detected" by DAD.

> As a datapoint, all the v6 implementations I

Well, RFC 4941 says "If DAD indicates the address is already in use, the node MUST generate a new randomized interface identifier", and is widely implemented (as I am sure you know). 
Your turn, it seems, to be less rigorous than you could ;-).

Regards,
RD

---

From: "Bless, Roland (TM)" <[email-masked]>
Date: Wed, 06 Feb 2013 17:41:41 +0100

Hi,

Am 06.02.2013 14:52, schrieb Rémi Després:
> As already said, the 4rd range only makes a first use of an existing
> RFC4291 provision: "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."

As it turns out now, this assumption is probably no longer true.

> - Once more: existing implementations have NOTHING to do (as long as
> they don't add 4rd support). Expressed doubts on this should be
> justified by a detailed technical justification. If you have any,
> let's look at it.

I was talking more about implications on new/forthcoming/updated
implementations. Do they need to keep a list of reserved IIDs
and check against them? This seems to be a bad idea IMHO.
We have no clear rules for this yet.

> - The reserved range is a tool to AVOID conflicts. It isn't, like
> DAD, a tool to RESOLVE them when they occur.

That's exactly my point: what should future implementations
do in order to avoid such conflicts? In case that they are
not using 4rd, MUST they exclude this IID range?

Regards,
 Roland

---

From: "Bless, Roland (TM)" <[email-masked]>
Date: Wed, 06 Feb 2013 17:52:19 +0100

Hi Fernando,

> know of support DAD, yet they do not resolve DAD failures when one is

Partially true: it is "resolved" so that two hosts do not
use the same address at the same time in this subnet.
DAD does not specify how to get out of the DAD failure,
e.g., retry with a new address etc.
DAD resolves a conflict if one host has got already an
address and another host tries to configure the same address.
In this case the latter host will be usually left with
an unusable address in state tentative/dad conflict.
If two hosts try to configure the same address at the
same time, both will not get a working address after
detecting a duplicate address. I would say that the
conflict is resolved, but the systems are not left
in a state in which they can communicate thereafter.

Regards,
 Roland

---

From: Rémi Després <[email-masked]>
Date: Wed, 6 Feb 2013 17:55:02 +0100

> As it turns out now, this assumption is probably no longer true.

This isn't an "assumption", this is just a quote of RFC 4291.

> and check against them?

No, they don't.

> This seems to be a bad idea IMHO.

If it would be the case, yes, it would be a bad idea, but it isn't the case.

> do in order to avoid such conflicts?

Nothing new needs to be done in any implementation other than that of a 4rd-supporting devices (4rd CEs and BRs). 

> In case that they are

Because of RFC 4291 is as it is, softwares that assign IIDs NEVER do it with u=g=1 => they don't need any update to exclude the 4rd range.
(That's precisely why the 4rd range has been chosen with u=g=1).

Regards,
RD

---

From: Roland Bless <[email-masked]>
Date: Wed, 06 Feb 2013 22:12:15 +0100

Hi,

> This isn't an "assumption", this is just a quote of RFC 4291.

I meant the assumption within the RFC 4291...

> (That's precisely why the 4rd range has been chosen with u=g=1).

Then I don't see a compelling reason to reserve an IID range for 4rd,
since it should work without the reservation just fine.

Regards,
 Roland

---

From: Rémi Després <[email-masked]>
Date: Thu, 7 Feb 2013 09:32:29 +0100

Le 2013-02-06 à 22:12, Roland Bless <[email-masked]> a écrit :
...
> since it should work without the reservation just fine.

- As already pointed out, in particular to Ran Atkinson:
"Making the reservation for one design, experimental or not, is a guarantee that no future design with conflict with it, experimental or not. A central registry is the appropriate tool for this."

- 4rd needs only 1/16384 of the currently unused range, which is worth registering.

Regards,
RD

---

From: Rémi Després <[email-masked]>
Date: Thu, 7 Feb 2013 14:36:50 +0100

...
> with Remi's proposal, a duplicate address will not even be detected.

Correct: even if software is available to detect collisions between 4rd addresses and RFC 4291-compatible host addresses, it won't detect any. (Such software, which isn't mandatory for 4rd, is of course not excluded either.) 

The simple reason for this non-detection is that these addresses have IIDs in disjoint sets. 

Regards,
RD

---

From: Ole Troan <[email-masked]>
Date: Thu, 7 Feb 2013 14:41:06 +0100

Remi,

> The simple reason for this non-detection is that these addresses have IIDs in disjoint sets. 

I think you have received quite a lot of pushback against creating disjoint sets of IIDs.

cheers,
Ole

---

From: Rémi Després <[email-masked]>
Date: Thu, 7 Feb 2013 15:01:41 +0100

> I think you have received quite a lot of pushback against creating disjoint sets of IIDs.

Different understanding. 
- Those who have supported haven't needed to repeat their support (see names in http://www.ietf.org/mail-archive/web/ipv6/current/msg17094, and one more in http://www.ietf.org/mail-archive/web/ipv6/current/msg16972)
- Those who have objected continue to receive answers to their concerns (the above being one instance).

Besides, these remaining concerns are aside from the question asked by Softwire (whether reserving a subset of an IID range unused by RFC 4291 is compatible with the IPv6 addressing architecture).

Regards,
RD

---

From: Ole Troan <[email-masked]>
Date: Thu, 7 Feb 2013 15:04:42 +0100

Remi,

> Besides, these remaining concerns are aside from the question asked by Softwire (whether reserving a subset of an IID range unused by RFC 4291 is compatible with the IPv6 addressing architecture).

I think our understanding of the IPv6 addressing architecture is incompatible.
there are no unused subset or unused ranges of interface-ids in IPv6.

cheers,
Ole

---

From: Rémi Després <[email-masked]>
Date: Thu, 7 Feb 2013 16:29:45 +0100

> there are no unused subset or unused ranges of interface-ids in IPv6.

1. If you interpret RFC 4291 as already permitting to set u=1 in some IIDs other than derived from IEEE MAC addresses, yes, we differ.

Note that, concerning the u/g bit significance, RFC 4291 is not the only RFC that avoids u=1 in IIDs that aren't IEEE derived, and to avoid u=1 in IEEE derived addresses that are unicast:

- RFC 3972 requires, in CGA IIDs, "setting bits 6 and 7 (i.e., the "u" and "g" bits) to zero".

- RFC 4941 requires, for privacy-extension IIDs, "set bit 6 (the leftmost bit is numbered 0) to zero.  This creates an interface identifier with the universal/local bit indicating local significance only." 
 
- RFC 6740 requires that "ILNP Identifiers have the same syntax as IPv6 interface identifiers [RFC4291], based on the EUI-64 format [IEEE-EUI]... If they have global scope, they SHOULD be globally unique... For both ILNP node Identifiers and also IPv6 interface identifiers, this Group bit is set to 0."

2. In http://www.ietf.org/mail-archive/web/ipv6/current/msg16982 you mentioned a particular use you know of a local-scope IID having u=g=1, namely ffff:0:0:1. Reason why its u bit isn't 0 is so far unclear but, assuming there is a reason, this IID can be reserved too in the IID-range registry, or one of its prefixes. 

As already noted, there isn't conflict between this IID and the 4rd range. No need to change either one.  

Conclusion: if you need some IIDs having u=g=1 for some identified use, let's document this use. 
We will thus avoid an unnecessary controversy. 

Regards,
RD

---

From: Ray Hunter <[email-masked]>
Date: Thu, 07 Feb 2013 16:34:03 +0100

> there are no unused subset or unused ranges of interface-ids in IPv6.
FWIW I agree with Ole.

An IID currently only has relevance to the IPv6 addressing architecture
specified in RFC4291 only when concatenated behind a /64 unicast address
prefix, and only on an individual link.

draft-ietf-softwire-4rd proposes breaking that tight coupling.

I'm not per se against breaking the tight coupling, because RFC4291
states "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." But it is a
change to current specification.

But in addition IMVHO.....

RFC 4291 states "Modified EUI-64 format-based interface identifiers may
have universal
   scope when derived from a universal token (e.g., IEEE 802 48-bit MAC
   or IEEE EUI-64 identifiers [EUI64]) or may have local scope where a
   global token is not available (e.g., serial links, tunnel end-points)
   or where global tokens are undesirable (e.g., temporary tokens for
   privacy [PRIV])."

The intention here to me is quite clear, even if it isn't written in
normative language.

u=1 should be used for generating an IID derived from universal  tokens.
The examples of universal tokens given in the document are those, which
by the nature of their distributed administration, can be assumed to
universally unique.

Appendix E of draft-ietf-softwire-4rd demonstrates how to generate an
IPv6 address for use with 4rd from an RFC 1918 address.

I do not consider an IPv4 RFC1918 address to be a global/universal token.

I don't see how generating an identifier that has to be unique way
beyond an individual link [by definition in 4rd], from an identifier or
token that clearly isn't globally unique [RFC1918], fits anywhere within
the spirit of any text contained in RFC4291.

To quote RFC1918 "As before, any enterprise that needs globally unique
address space is required to obtain such addresses from an Internet
registry." Use of magic beans to ensure global uniqueness would seem to
be excluded.

So as I have previously asserted, I think there certainly needs to be
some clarification of any possible transportation of 4rd across an AS
boundary, regardless of any other discussions.

Transporting RFC1918 addresses across an AS boundary (in a 4rd tunnel),
accidentally or otherwise, would to me be a clear violation of RFC1918,
and the IPv4 [sic] addressing architecture. Nothing I've read in the
meantime has changed this view.

Which is one reason why I continue to assert that a global IID
reservation is not necessary for experimental deployment of 4rd at this
time: IMVVHO 4rd as specified today in draft-ietf-softwire-4rd can only
safely be deployed within a single AS. Inter-AS 4rd would be potentially
harmful.

And for the record, Remi: The IETF is a meritocracy. I don't believe
it's your role to call consensus in this WG, or otherwise define or
limit what is, or is not, a valid discussion or stand point. It isn't
mine either for that matter. If the chairs wish to make a statement, I'm
sure they will do.

Respectfully yours,
RayH

---

From: Doug Barton <[email-masked]>
Date: Thu, 07 Feb 2013 08:55:37 -0800

On 02/07/2013 06:01 AM, Rémi Després wrote:
> Besides, these remaining concerns are aside from the question asked by Softwire

Rémi,

Do you admit to the possibility that the design coming from softwire 
might have flaws that should be addressed before it proceeds?

I'm not saying necessarily that it does, although people here a lot 
smarter than me have raised concerns that I would like to see addressed 
in a manner other than, "I don't want to talk about that."

Doug

---

From: Doug Barton <[email-masked]>
Date: Thu, 07 Feb 2013 09:02:50 -0800

Rémi,

I think you've misunderstood me. Please see below.

On 02/06/2013 02:01 AM, Rémi Després wrote:
>>>>> It remains that IIDs having u=1 SHOULD be unique, i.e. with
>>>>> rare enough exceptions. This is somewhat similar to the
>>>>> expectation that ULA collisions shouldn't be seen).
>>>>>
>>>>> This theoretical unicity has been extensively used to assign
>>>>> stable IIDs, without administrative action, to hosts  that
>>>>> have no privacy constraints requiring the opposite.
>>>>
>>> (*) Major OSes can assign IIDs derived from IEEE MAC addresses of
>>> their LAN adapters (if not by default, at least as a
>>> possibility). They do it because of what IEEE and IETF have
>>> specified, each one for its own domain, concerning their
>>> respective u bits.
>>
> Fair enough. My answer is that no software that I know makes
> determination based on the u bit.

Thanks, that matches my (admittedly imperfect) understanding as well.

> My point is that it isn't sufficient for the IETF u bit to have no
> meaning. (a) It has what is specified in RFC 4291. (b) No software I
> know creates IIDs having u = 1 without an IEEE-based OUI.

So my new question is, why do you care?

To amplify slightly, I am ambivalent about un-defining the u and g bits. 
Generally such a thing is difficult to do, since it's nearly impossible 
to get a complete survey of all software everywhere that may use those 
bits, and determine if it is safe to stop to just stop caring about them.

OTOH, I am not a fan of magic bits in general, and I have never seen an 
adequate explanation of why an implementor should care about these 2. So 
I'm sympathetic to the argument about un-defining them, but you seem to 
be vehemently opposed to it, so I'm trying to understand your objection. 
"It's important because it's important!" doesn't help me. :)

Doug

---

From: Rémi Després <[email-masked]>
Date: Thu, 7 Feb 2013 18:26:44 +0100

...
> prefix, and only on an individual link.

In RFC 4291;
- 2.5 is Unicast addresses
- 2.5.1 is Interface Identifiers.
- It says: "For all unicast addresses, except those that start with the binary value 000, Interface IDs are required to be 64 bits long"

> draft-ietf-softwire-4rd proposes breaking that tight coupling.

4rd only depends on the RFC-4291 constraint that all native IPv6 destinations that don't start with 000 and enter a 4rd-CE site comply with the above.  

> change to current specification.

No change of the current specification is needed, because of the above.

> the spirit of any text contained in RFC4291.

(a) As a matter of fact, a 4rd IID is UNIVERSALLY UNIQUE: it contains a global IPv4 address (see the definition of a 4rd IPv4 address), followed by a CNP which cannot have the same value for two CEs sharing the same IPv4 address. (16-bit prefixes of two CE prefixes that differ only by n consecutive bits, with 0 < n < 16, are necessarily different)

In view of your misinterpretation here, it may be useful to add a clarification on this in the 4rd draft itself. I can provide text if needed.

(b) Seeing your reference to RFC 1918, I looked at Appendix E, the only place where it is referenced. 
It contains an unfortunate typo. If it facilitated the misunderstanding, sorry for that. 

Where it says "the public IPv4 prefix to be used for shared addresses is supposed to be 192.16.0.0/16 (0xc610)", it should have had 198.16.0.0/16. (a usual example value for a global IPv4 prefix, and equal to 0xC610). 

In this Appendix E, 4rd is used *as usual* for GLOBAL IPv4 over IPv6. It only happens that the (global) IPv6 is deployed using 6rd on an RFC1918 ISP network. 

> registry." Use of magic beans to ensure global uniqueness would seem to

4rd doesn't work with RFC-1918 addresses.
(And there isn't any magic bean anyway.)

> safely be deployed within a single AS. Inter-AS 4rd would be potentially

No problem as 4rd IPv4 addresses are all global.

> mine either for that matter. If the chairs wish to make a statement, I'm

I have complete respect for the role of chairs, if for no other reason because I do know how difficult it is. (I a-have been long ago in such a position in another body.)
I only feel being in my role when expressing my understanding of where we are. 

Thanks for the opportunity to correct the Appendix E typo.
Regards,

RD

---

From: Rémi Després <[email-masked]>
Date: Thu, 7 Feb 2013 18:45:05 +0100

Le 2013-02-07 à 17:55, Doug Barton <[email-masked]> a écrit :

> Do you admit to the possibility that the design coming from softwire might have flaws that should be addressed before it proceeds?

Of course I do!

OTOH, the place to discuss efficiently potential design flaws is the WG where experts of the design are present.

> 
> I'm not saying necessarily that it does, although people here a lot smarter than me have raised concerns that I would like to see addressed in a manner other than, "I don't want to talk about that."

OK, please quote the exchange(s) you are referring to, and I will try to answer more.

Note that preferring to discuss in a better forum isn't "I don't want to talk about that".
Anyway, sorry if I gave this impression.

Regards,
RD

---

From: Rémi Després <[email-masked]>
Date: Thu, 7 Feb 2013 19:21:58 +0100

...
> So my new question is, why do you care?

See below.

> Generally such a thing is difficult to do, since it's nearly impossible to get a complete survey of all software everywhere that may use those bits, and determine if it is safe to stop to just stop caring about them.

Since it is at least risky, one would need a good reason to take that risk.

> OTOH, I am not a fan of magic bits in general, and I have never seen an adequate explanation of why an implementor should care about these 2. So I'm sympathetic to the argument about un-defining them, but you seem to be vehemently opposed to it, so I'm trying to understand your objection. "It's important because it's important!" doesn't help me. :)

Let me clarify where I stand:

(a) Whether changing RFC4291 or not is not the issue for which I work so hard these days. I do think it isn't necessary and have argued in this direction, but my point is that I see a real benefit (point (b)) in using RFC 4291 as is. No modification should break anything, including this benefit.
   
(b) The benefit comes from the following, i.e. one of the 4rd objectives: 
- We want to statelessly establish automatic tunnels for residual IPv4 across IPv6-only domains.
- We don't want, when doing so, to impose any renumbering of IPv6 link and/or host.
- This is possible ONLY IF we use, for each CE tunnel endpoint, an IPv6 address that no host in the CE site may be using.
- Fortunately this happens to be feasible, with IPv6 as is: in a site that is delegated a prefix up to /64, no host that has a global unicast address conforming to RFC4291 may have an IID in which u=g=1.
- By reserving a small subset of this unused IID space, we reach our objective.

Hope it clarifies.

Regards,
RD

---

From: Roger Jørgensen <[email-masked]>
Date: Thu, 7 Feb 2013 19:35:34 +0100

sorry, but we can't all be nice all the time, see more inline,

On Thu, Feb 7, 2013 at 7:21 PM, Rémi Després <[email-masked]> wrote:
<snip>
> - We want to statelessly establish automatic tunnels for residual IPv4 across IPv6-only domains.

not a bad idea, but don't we have other options in this area?

> - We don't want, when doing so, to impose any renumbering of IPv6 link and/or host.

excellent, any protocol/idea that impose this is quite badly designed.

> - This is possible ONLY IF we use, for each CE tunnel endpoint, an IPv6 address that no host in the CE site may be using.

I have always thought any address I get on my host from dhcpv6/ra or
similar, mixed with DAD and other mechanism are as close to a guaranty
as we can get.
No need for some magic bits of any type.

> - Fortunately this happens to be feasible, with IPv6 as is: in a site that is delegated a prefix up to /64, no host that has a global unicast address conforming to RFC4291 may have an IID in which…

... You just ASSUME something I think we all understand is not
possible to guaranty. There will be collision, deal with it.

Someone will probably sooner than later, assign either auto (yes they
break the "rule") or manual an address that will cause two hosts on
the same link/site to have the same address no matter how much you
ASSUME the above (u=g=1...)

> - By reserving a small subset of this unused IID space, we reach our objective.

yes it clarifies to me that you suggest a quite broken way of using
IPv6 addresses. You ASSUME things, among that some magic bits (u and
g) will give you something close to an unique address.

--

---

From: Rémi Després <[email-masked]>
Date: Fri, 8 Feb 2013 09:31:40 +0100

> not a bad idea, but don't we have other options in this area?

In Softwire, conclusion has been this was a tool to have.

> excellent, any protocol/idea that impose this is quite badly designed.

(*) Good.

> similar, mixed with DAD and other mechanism are as close to a guaranty

Hosts of an IPv6 customer site can have IPv6 addresses assigned, with SLAAC or DHCPv6, BEFORE 4rd is activated. 

If  these addresses become in conflict with the CE 4rd address when 4rd is activated, renumbering becomes necessary. The objective (*) isn't satisfied.  
(Reason why the CE itself cannot take another address is because this address must be *algorithmically derived* from an a IPv4 destination by other CEs.)

> No need for some magic bits of any type.

Bits u and g haven't been invented for 4rd.
Using u=1 for future technologies, is anticipated in RFC4291 itself. 
No magic involved.

> possible to guaranty. There will be collision, deal with it.

Let me make the point again.
It is a fact (not an assumption) that RFC4291-conforming IIDs either have u=0, in which case other bits may have any values, or, if they have have g=1, have a specified structure. So far the only such structure is that of IEEE derived IIDs. With it, g=0 because these IIDs are those of unicast addresses.

If, in your understanding, RFC 4291 authorizes IIDs having u=g=1, PLEASE EXPLAIN.

> break the "rule")

Auto assignments that break the rules are bound to create problems anyway.
Their bugs need to be fixed.

> or manual an address that will cause two hosts on

Manual mistakes do occur, yes. They have to be fixed like other bugs. 

> g) will give you something close to an unique address.

I hope you will eventually understand that so much negativeness isn't justified. 

Fortunately for me, a number of highly experienced 6man contributors have already expressed their view that the proposed range reservation isn't a problem.

Regards,
RD

---

From: [email-masked]
Date: Fri, 08 Feb 2013 10:51:39 +0100 (CET)

> It is a fact (not an assumption) that RFC4291-conforming IIDs either have u=0, in which case other bits may have any values, or, if they have have g=1, have a specified structure. So far the only s…

However, there is nothing which enforces RFC4291-conforming IIDs for
(for instance) statically configured IPv6-addresses. So in what way do
well defined u/g values for RFC4291-conforming IIDs help you?

Steinar Haug, AS 2116

---

From: Rémi Després <[email-masked]>
Date: Fri, 8 Feb 2013 11:14:32 +0100

> well defined u/g values for RFC4291-conforming IIDs help you?

1.
Users that manually configure their IPv6 addresses should be knowledgeable about what they do.

If one configures an address has u=g=1, unless it is for an experiment, it is a human mistake (it conflicts with the IPv6 addressing architecture of RFC 4291). Depending on the context, this mistake will have no consequence or will eventually have to be corrected.
Note that, even if one does such a mistake in a 4rd site, the likelihood of using the 4rd IID prefix 0x0300 remains low.

2.
On my home network, I know nobody is doing manual configuration.

Regards,
RD

---

From: Havard Eidnes <[email-masked]>
Date: Fri, 08 Feb 2013 11:59:10 +0100 (CET)

> If one configures an address has u=g=1, unless it is for an
> experiment, it is a human mistake (it conflicts with the IPv6
> addressing architecture of RFC 4291). Depending on the context,
> this mistake will have no consequence or will eventually have
> to be corrected.

What's the operational failure mode?  Does it fail in a way which
would be obvious to the ones who has made this mistake, or will
simply some seemingly-random pairs of hosts fail to communicate?
I think it would be an engineering mistake to willfully create
hard-to-detect failure scenarios via a modification to already
fielded standards.

> Note that, even if one does such a mistake in a 4rd site, the
> likelihood of using the 4rd IID prefix 0x0300 remains low.

That's a nice handwave...

> On my home network, I know nobody is doing manual configuration.

That doesn't really prove anything.

Regards,

- Håvard

---

From: Roland Bless <[email-masked]>
Date: Fri, 08 Feb 2013 12:08:38 +0100

Hi,

On 08.02.2013 09:31, Rémi Després wrote:

> Hosts of an IPv6 customer site can have IPv6 addresses assigned, with
> SLAAC or DHCPv6, BEFORE 4rd is activated.

> If  these addresses become in conflict with the CE 4rd address when
> 4rd is activated, renumbering becomes necessary. The objective (*)
> isn't satisfied. (Reason why the CE itself cannot take another
> address is because this address must be *algorithmically derived*
> from an a IPv4 destination by other CEs.)

Maybe I don't get it, but it seems that mixed usage of non-4rd hosts
and 4rd hosts in the same subnet is not easily possible, since 4rd
cannot use different IIDs than the algorithmically derived ones.
So conflicts are hopefully detected, but cannot be resolved.

This seems to suggest that you better use a different 4rd subnet-prefix
when configuring 4rd use so that all nodes in this 4rd subnet-prefix
use the same method to derive their IID and you avoid conflicts
with other hosts. Wouldn't it be possible to use those two subnets in
parallel, then there would be no need to renumber existing hosts.

Regards,
 Roland

---

From: Rémi Després <[email-masked]>
Date: Fri, 8 Feb 2013 16:51:19 +0100

> hard-to-detect failure scenarios via a modification to already

FULL AGREEMENT that we don't want to modify any "already fielded standard".
If you believe such a change is needed for 4rd, PLEASE EXPLAIN. 

If one configures an address that doesn't follow configuration constraints, it may fail in various ways, but under its own responsibility.
For instance, if it has the wrong subnet prefix, it won't be reachable from across the Internet, like what may happen if it has a non-RFC4291-complying IID that happens to be in the 4rd reserved range in a site where 4rd is activated.

> That's a nice handwave...

This is a fact, worth noting IMHO, especially since the particular example of a non RFC4291-compliant address Ole gave didn't conflict with 4rd.

Your lack of interest for this point doesn't justify, IMHO, a so depreciating comment. 

> That doesn't really prove anything.

It doesn't prove anything, OK, and wasn't BTW claimed to prove anything in particular.

Yet, the risk of manual misconfigurations that may conflict with the RFC 4291, which is indeed a risk, is mitigated by the fact that manual address configuration is AFAIK more an exception than a general practice.

Regards,
RD

---

From: Rémi Després <[email-masked]>
Date: Fri, 8 Feb 2013 16:58:42 +0100

> So conflicts are hopefully detected, but cannot be resolved.

There isn't such thing than a 4rd host.
There are only 4rd CEs (customer-edge routers) in which IPv4-in-IPv6 tunnels are terminated.

> parallel, then there would be no need to renumber existing hosts.

Using a 4rd-specific subnet prefix may impose some renumbering when 4rd is activated, which is contrary to our objective. 
(This prefix, needing to be automatically configured, cannot depend on which subnet prefixes are have been used before 4rd activation.)

Regards,
RD

---

From: Randy Bush <[email-masked]>
Date: Fri, 08 Feb 2013 09:18:43 -0800

folk, can we stop beating the horse?  everyone but the horse knows it is
dead.  and the bits of spattered horse are consuming significant energy
better spent on productive work.

randy