> Which one is correct? Is the length of IF IDs determined by the link > type, or the address format, or both? If the answer is "both", there > may be inconsistency in future specification. For example, what if a > future IPv6-over-FOO document specifies like this? > > An IPv6 address prefix used for stateless autoconfiguration [ACONF] > of a FOO interface must have a length of 80 bits. > > Will we then have to give up using stateless address autoconfiguration > with unicast prefixes beginning with "000" in this link?
I think you meant "unless the unicast prefix begins with 000 ..." > Technically, this is not necessary a contradiction. [IPv6-ETHER] only > requires 64-bit IF IDs for stateless address autoconfiguration, so the > above (imaginary) IPv6-over-FOO document and the addr-arch document > can coexist without conflicting each other if we give up stateless > autoconfiguration in this link. But is this a realistic option? I personally think we should hard-code the /64 boundary in as few places as possible to allow for future evolution. Your 80 bit interface ID on some new links is one example of possible future evolution. Another example is cases where 20 years from now having less than 64 bit interface IDs (or addresses allocated with DHCP from a >64 bit subnet prefix) might fill a useful role. Hard-coding the /64 address too me sounds like the original Arpanet design with 8 bit network numbers and 24 bit host numbers; which was revised/relaxed first with class A/B/C and later with CIDR. I don't know of a technical reason why /64 needs to be a hard limit. Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
