>>>>> On Sat, 19 Feb 2005 10:28:55 +0200,
>>>>> Markku Savela <[EMAIL PROTECTED]> said:
>> On Sat, 19 Feb 2005, Markku Savela wrote:
>> > This would work just fine, if nodes on internal network take the RA
>> > prefix length as is, and just trunctate their ID-parts from higher
>> > ends (or they could just generate ID randomly). Throw away all this
>> > sillyness with fixed 64-bit ID etc..
>>
>> This would require changes to the hosts (and have other issues
>> besides) -- not good.
> Implementations might already work this way.
Some implementations *might*, but I suspect most implementations
ignore such an "invalid" prefix on the contrary. At least KAME/BSD
ignores it.
In fact, RFC2461 is already pretty clear that such a prefix MUST be
ignored:
If the sum of the prefix length and interface identifier length
does not equal 128 bits, the Prefix Information option MUST be
ignored. An implementation MAY wish to log a system management
(Section 5.5.3, bullet d).
rfc2462bis will even make this point clearer, with an attempt of
clarifying the consistency between the address architecture RFC and
link-specific RFCs wrt the appropriate prefix length.
Therefore,
> This should be specified
> in the RFC as a correct behaviour with longer prefix, instead of
> rejecting them.
I disagree. "The RFC" (I'm not 100% which RFC you meant here though)
is already pretty clear on the "correct" behavior, which is strict on
the prefix length, and I don't see any reason to change this
requirement at this stage.
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
--------------------------------------------------------------------
