Hi Remi,
On Jul 27, 2009, at 4:27 PM, Rémi Després wrote:
Two constraints on IPv6 address formats appear to be unnecessary
while prohibiting some designs that are useful to enhance IPv6
benefits:
- One concerns addresses that never appear on any IPv6 link.
Since only purpose of these addresses is to derive from them some
local addresses subject to IID constraints, they shouldn't, be
themselves, be required to include 64-bit IID fields with their
restricted format (u and g bits specified values).
As I understand it, you are not (in the my terminology) talking about
addresses that will not appear on any IPv6 link... You are talking
about addresses, such as the global addresses in your SAM proposal,
that will be used as the source and destination addresses of routed IP
packets. Right?
You are suggesting that there may be ways to improve IPv6 that would
require modification to the current IPv6 unicast address format, so
that routing prefixes can be longer than 64-bits and IIDs can be
shorter than 64 bits. Right?
I am still not 100% sure where/when you are talking about using these
longer prefixes...
They would be used in IP packet headers that are routed across the
network. Would they also be used in RAs? Would they be assigned via
DHCP? Would hosts be expected to generate privacy addresses in these
prefixes?
Longer prefixes are supported in most of the IPv6 RFCs, but there are
some exceptions. There also may be restrictions in applications, such
as routers that are optimized to route on the first 64 bits of the
address, tools that won't let you enter more than a 64-bit prefix,
etc. So, personally, I think we would need a very compelling reason
to allow longer prefixes.
- The second one concerns a strict interpretation of RFC 4291 that
permits new IID formats ONLY for global-scope IIDs.
It happens that some new IID formats with local scope could also be
useful.
If I understand this request correctly, you are asking whether it
would be okay to use IIDs with the "u" bit set (indicating that they
are globally unique IIDs) that are _not_ based on a modified EUI-64
identifier. Is that correct?
This would undo some of the changes we made (as a results of the GSE/
8+8 discussions) to allow for nodes to have globally-unique IIDs. It
is not clear to me that we've realized any possible benefit from those
unique global IIDs, but we should understand what we are giving up
before we do so.
Margaret
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
