----- Original Message -----
> From: Ray Hunter <v6...@globis.net>
> To: Brian E Carpenter <brian.e.carpen...@gmail.com>
> Cc: Fernando Gont <fg...@si6networks.com>; 6man 6man-wg <ipv6@ietf.org>
> 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:
>> On 02/02/2013 17:48, Ray Hunter wrote:
>>>> Fernando Gont <mailto:fg...@si6networks.com>
>>>> 2 February 2013 16:15
>>>>
>>>> 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=)
>>>>
>>>> Cheers,
>>> 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.
>>
>> Only because it's supported by DAD, surely? There is no piece of magic
>> that absolutely prevents two hosts claiming the same IID.
>>
>> Brian
> 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.
>
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)
> 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.
>
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.
> 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?
>
I don't think we should, as it would too tightly couple layer 3 with a
particular layer 2 addressing scheme.
> 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
>
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.
> 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.
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.
>>> 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:v6...@globis.net>
>>>> 2 February 2013 14:45
>>>> Inline
>>>>
>>>> Rémi Després wrote:
>>>>> 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.
>>>>>
>>>>> 2013-02-01 21:13, Fernando Gont <fg...@si6networks.com> :
>>>>>
>>>>>> Hi, Brian & Sheng,
>>>>>>
>>>>>> On 02/01/2013 05:13 AM, Brian E Carpenter wrote:
>>>>>>> We've put this together to address the general
> question of the
>>>>>>> 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:
>>>> Right. "Normal case." Not "exclusive case."
>>>>>>> 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).
>>>> This is also my interpretation.
>>>>> 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.
>>>> I have a problem with any assumption that u==> global
> uniqueness, or
>>>> u==> 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= 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=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
>>>> 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.
>>>>
>>>>>> 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.
>>>>> 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.
>>>>>
>>>>>
>>>>>> 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=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:
>>>>>>> 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?
>>>>> 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
>>>>>> e-mail: fg...@si6networks.com
>>>>>> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55
> 1D4E 7492
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
> --------------------------------------------------------------------
>>>>>> IETF IPv6 working group mailing list
>>>>>> ipv6@ietf.org
>>>>>> Administrative Requests:
> https://www.ietf.org/mailman/listinfo/ipv6
>>>>>>
> --------------------------------------------------------------------
>>>>
> ------------------------------------------------------------------------
>>> --------------------------------------------------------------------
>>> IETF IPv6 working group mailing list
>>> ipv6@ietf.org
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
>>>
>>
>>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
