i object to publish this document as a standard track document.
experimental would be more preferable.
I don't agree. I think this is appropriate for standards track.
unique local IPv6 unicast address avoids some problems of site-local,
but not all; there are major problem still remains.
- it is not expected to be routable, however, it will be treated
as if it is a global address. therefore it is likely to be leak out.
1.0 asserts that "even if it leaks out there's no conflict", but
"no conflict" is not enough - we do need to be 100% sure there's no
leak out, otherwise it is unacceptable.
I don't think we have to be 100% sure. Overall I think it is much better to have a well known non-ambiguous prefix that we can have a reasonable likely hood that it is filtered.
- operationally, there's a much easier way to get a block of address
which has the features unique local IPv6 unicast address has;
it is to use 6to4 address prefix (2002:v4v4:v4v4::/48). as long as
you do not renumber IPv4 address and IPv6 address at the same time,
6to4 address will give you enough address for the suggested use of
unique local IPv6 unicast address. moreover, 6to4 address are
routable (though there's tunnelling overhead if outsiders are to
contact 6to4 address accidentally). there is no need to define
unique local IPv6 unicast address.
This approach doesn't work well for disconnected sites who may not have a global IPv4 address. I suspect they would use Net 10 IPv4 addresses. This would, of course, result in ambiguous prefixes like site-local. Something we are trying to move away from.
Bob
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
