On 2009-12-10 05:59, Rémi Després wrote:
> Christian Huitema a écrit :
>>
>>> Christian, as you are one of those who have lived the early history
>>> of IPv6, do you know any *technical objection*, from any one, for
>>> the following which, as new address formats are and will be defined,
>>> should be more appropriate than the current text:
>>>
>>> "For all unicast addresses other than those that start with the
>>> binary value 000, and that are used as destinations on IPv6 links
>>> having /64 subnet prefixes, Interface IDs are required to be
>>> constructed in Modified EUI-64 format.
>>
>> First, let's have this discussion only in the 6MAN WG. The BEHAVE
>> working group is supposed to deal with the network rules that we have,
>> not try to change them.
>
> Agreed, that's better.
>
>>
>> The opening of the can of worms lies in your statement, "on IPv6 links
>> having /64 subnet prefixes." We gained a lot of simplicity from
>> having a simple subnet+host format.
>
> I appreciate this, in particular for the Neighbor Discovery protocol, a
> good design as far as I am concerned.
> I don't suggest in any way that ND should work with other than /64 IIDs.
> This sentence is IMO just a precise expression of the context in which
> the format constraint has been devised.
> I would however have no objection to replacing "links having /64 subnet
> prefixes" by "links subject to the neighbor discovery protocol".
> This, in my understanding, would avoid opening this can of worms.
Unfortunately, I don't think so. You have to consider the case of
address referrals. I don't know of any magic by which a third party
host (or application instance in a third party host, to be more precise)
would know by looking at an address that it belongs to a link subject
to the ND protocol. All it knows is that the address is, or is not,
a unicast address whose first three bits are 000.
So either we *do* keep the rule that in such addresses u/g is
valid, or we *don't* keep that rule. We can't make it conditional.
...
> Unless you can come up with a real technical reason preventing such
> simplification in the future, or someone else, it's time IMO to clean up
> this unfortunate detail of the spec.
It isn't unfortunate. It was actually intended to leave the door open
for 8+8 (as it was understood at the time), since 8+8 and GSE required
globally unique IIDs. Today's derivative of 8+8, ILNP, does *not* require
globally unique IIDs. But that decision in the ILNP design might itself
be contentious. I think we'd need some sort of community decision
about this whole topic before taking a decision about the u/g detail.
Brian
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
