>>>>> On Tue, 8 Jun 2004 08:38:19 +0300 (EEST), >>>>> Pekka Savola <[EMAIL PROTECTED]> said:
>> Assuming I'm correct for both the questions, I'd like to propose to >> revise the logic in Section 5.5.3 as follows: >> >> a) Check for the Autonomous flag >> b) Ignore the link-local prefix >> c) Check for the case of preferred lifetime > valid lifetime >> d) Check if the prefix length is valid for the receiving interface. >> If it is not valid, ignore the prefix. > How do you check that the length is valid for the *receiving > interface*? I guess you make the assumption, based on IPv6 over Foo > documents, that for each interface, it's clear which kind of prefix > lengths for SLAAC are used? Yes, and this is the assumption in rfc2462bis for resolving issue 281 "Requirement for 64bit I/F ID". See https://rt.psg.com/Ticket/Display.html?id=281 for more details (user/passwd=ietf/ietf). The next revision of rfc2462bis will explicitly clarify this point. >> e) If the prefix advertised does not match the prefix of an address >> already in the list, make a new address from the prefix >> f) If the prefix advertised does match the prefix of an address >> already in the list, update the lifetimes of the address > Note that you can avoid the wording nit above if you just checked the > prefix and length explicitly both in e) and f) -- that is, don't > configure a new address if it doesn't have the right prefix length > (this already happens today), and don't update the prefix lifetimes > unless the prefix *and* the length matches an existing prefix > completely. That's right. This is another way to resolve this issue. > So, would a more straightforward change be a modification in f) above? > (The code might be a bit cleaner with a common rule before e or f > though.) I don't mind either resolution between 1. add a new check 'd' just for validating the prefix length (and renumber the succeeding items) 2. add the validation for prefix length in the original item 'e' (and do not touch the other items) I'm not sure which one is better...if the majority in this list prefers 2, I'll simply take this option. 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 --------------------------------------------------------------------
