Brian E Carpenter wrote :
On 2009-12-10 05:59, Rémi Després wrote:
Christian Huitema wrote :
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
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.
The important point is that AFAIK the third party doesn't need to know.
As long as the first part of the address referral can be routed, it can
use it as destination, and leave the target network decide what to do.
For example, it isn't necessary in a source host, and in a source
network, to recognize that a destination is an ISATAP address.
It is enough that the destination network, and destination host,
recognize it.
We know, of course, that the ISATAP address format does comply with the
"u" bit constraint, but AFAIK there is no *documented technical reason*
why, today, this couldn't have been dispensed from.
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.
Agreed, but in my understanding my proposal doesn't make it conditional.
It just restricts its scope.
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.
I don't mean unfortunate *when it was stated*, just unfortunate *now*
(i.e. in a different context where more and more address fields, to be
converted in some way to produce on-link addresses, are embedded in IPv6
addresses.)
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.
Thanks for this reference.
Note that:
o draft-odell-8+8-00 has its unique End System Designators (ESDs) in the
first 15 bits of the 9th and 10th address octets, and they provide "for
32768 distinct partitions in the Private Topology". They may therefore
have *any values* in "u" and "g" bits.
o draft-ietf-ipwng-gseaddr-00 distinguishes GSE addresses from others by
a GSE-specific mark in the first bits of addresses. There is no need for
any "u" bit to know that ESDs are globally unique.
Interesting, isn't it?
Today's derivative of 8+8, ILNP, does *not* require
globally unique IIDs.
Good to be confirmed!
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.
Full agreement on this.
That's the purpose of contributing here.
Best regards,
RD
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
