>>>>> On Fri, 27 Feb 2004 13:47:35 -0800 (PST),
>>>>> Erik Nordmark <[EMAIL PROTECTED]> said:
>> 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 ..."
Oops, that's right. Thanks for the correction.
>> 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.
I tend to agree, though I know we have a different opinion.
The difficult point here is that this is actually not an RFC2462
issue, but a consistency issue about the definition of interface
identifiers in various documents. Currently I don't have a good idea
on how to resolve it without affecting other documents much.
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
