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.
There have been discussions in the past of changing that, but these
discussions always felled flat, since there is no obvious advantage
to subnet prefixes larger than 64 bits. More precisely, the
justification always seems to try avoid some administrative rule, but
the rules are not linked to the specific number 64. They derive from
tensions between users and providers, providers and regions, between
providers themselves. Changing the boundary would not reduce the
tensions, merely displace them. I would expect some very serious
pushback.
See above.
Once you accept that you have a fixed boundary, then you realize that
reusing an already existing allocation scheme is a very nice
feature. The cost appears to be 2 bits out of 64, leaving 62 bits for
innovative schemes. More than enough for any reasonable management
system.
The existing unnecessary complexity is for addresses that are never
subject to ND.
Although I do agree that, to conclude quickly on IPv6 Addressing of
IPv4/IPv6 Translators, the format of draft-ietf-behave-address-format-01
section 2 should be adopted, it has to be faced that this format has 6
sub-formats, because of the "u" bit constraint.
Without this constraint (unjustified so far) the format would have just
been "prefix.v4(32).suffix", the suffix having possibly length zero.
This would have been a cleaner specification.
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.
Regards,
RD
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
