2013-02-06 00:45, Doug Barton <do...@dougbarton.us> :
> On 02/05/2013 05:57 AM, Rémi Després wrote:
>> Hi, Doug,
>>
>> Please see inline.
>>
>>
>> 2013-02-04 à 18:37, Doug Barton <do...@dougbarton.us> :
>>
>>> 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).
>>>>
>>>> This theoretical unicity has been extensively used to assign stable IIDs,
>>>> without administrative action, to hosts that have no privacy constraints
>>>> requiring the opposite.
>>>
>>> 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.
>
> 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?
>> 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.
>
> What makes the addresses unique are the unique MACs, not the u bit.
No disagreement on this.
>
>>> 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.
>
> 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.
>
>>> 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.
>
> 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
>
> Doug
>
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
