>>>>> On Tue, 13 Jul 2004 11:31:50 -0400 (EDT), >>>>> Suresh Krishnan <[EMAIL PROTECTED]> said:
>>> The following text makes no sense to me. Maybe I am reading this wrong but >>> isn't this self contradictory (snip) >> No, because "the other packet" is unicasted to the tentative address >> while DAD NA/NS are multicasted. I think this should be clarified in >> the following part: (snip) >> And I do not see the need for further clarification. > ==> I see your point but this is still fuzzy. > This is what it says > ==================== > "Note that the "other packets" include Neighbor Solicitation > and Advertisement messages to the tentative address containing the > tentative address in the Target Address field." > This is what it actually means > ============================== > "Note that the "other packets" include Neighbor Solicitation > and Advertisement messages with the tentative address as the IP > destination address and contain the tentative address in the > Target Address field." Okay, while I don't think the current wording is that fuzzy, I admit the text could be improved. I'll replace the current sentence with the latter one. >>> 5.5.3 Router Advertisement processing >> >>> Bullet points b) and c) are redundant as they belong in RFC2461/2461bis >>> and not here as they are not specific to autoconfiguration. Probably these >>> can be removed. >> >> I don't think the duplication is redundant in the first place, since >> the processes of ND and autoconf can be done separately. For example, >> RFC2461 says in Section 6.3.4 that: >> >> Note: Implementations can choose to process the on-link aspects of >> the prefixes separately from the address autoconfiguration aspects >> of the prefixes by, e.g., passing a copy of each valid Router >> Advertisement message to both an "on-link" and an "addrconf" >> function. Each function can then operate independently on the >> prefixes that have the appropriate flag set. >> > ==> I disagree. check out the following text in RFC2461bis in section > 4.6.2 under the definition of prefix information option. > "A router SHOULD NOT send a prefix > option for the link-local prefix and a host SHOULD > ignore such a prefix option" > Note that this is an unqualified statement. The processing of the prefix > information whether it is for on-link or addrconf functions must obey > this. I see the point, but I still strongly believe rfc2462bis should have the complete list of checks despite the duplication. Implementors will read rfc2462bis (or do read RFC2462) Section 5.5.2, and will implement the listed checks one by one. If we omit bullet (b) (check for the link-local prefix) just due to the duplicate description with RFC2461 (or rfc2461bis), they might miss implementing this part. In any event, as long as the duplicate part is consistent (and it actually is), it's a tradeoff issue and a matter of sense whether we should leave it in both the documents or we should only describe it once. In this particular case, I strongly believe it is much more helpful to have the check in rfc2462bis explicitly. I guess you can also live with this policy since you said the duplicate check "can" be removed. If so, please let me leave this bullet as is. If we can agree here, we'd not need to discuss more about bullet c, but I'll answer the following part just in case (and since this might affect the rfc2461bis work): >> Besides, bullet c) does not seem to be duplicate with RFC2461. >> rfc2461bis clarified this point (maily) from the sender (router) side, >> but it still does not contain the validity check at the receiver's >> side (and I think it's intentional). > ==> I don't think 2461bis differentiates between sending and receiving in > this regard. 2461bis specifies the format of the prefix information > option in section 4.6.2. The contents of this option field specify that > that preferred lifetime MUST NOT be greater than valid lifetime > "Preferred lifetime ... > Note that the value of this field MUST NOT exceed > the Valid Lifetime field to avoid preferring > addresses that are no longer valid." Believe me, I know rfc2461bis (or at least the original intent) differentiates these since it was me who originally raised this issue 1.5 years ago. See http://www.atm.tut.fi/list-archive/ipng/msg07250.html and its follow-ups for the past discussion. The consensus in the discussion was: - routers MUST NOT send a prefix with preferred lifetime > valid lifetime - it doesn't matter whether a host accepts or ignores such a prefix information option for on-link determination (i.e., in terms of RFC2461) - RFC2462 is already clear on the host's behavior in its scope: hosts should ignore such a prefix information option but...hmm, perhaps the description in Section 4.6.2 of rfc2461bis is overspecification in terms of the above consensus: the restriction for AdvPreferredLifetime (Section 6.2.1) is probably enough and the "MUST NOT" rule in Section 4.6.2 should probably be removed. >>> Bullet point e) references a DoS attack but there are no references to >>> it. Maybe it makes sense to add an informative reference to it. >> >> I don't think so. There is actually no appropriate difference since ^^^^^^^^^^oops...I meant "reference" here. >> this was discussed in the update work from RFC1971 to RFC2462. And, >> in fact, detailed explanation about the attack is provided in bullet >> e). > ==> OK. I was more interested about the rationale behind choosing the 2 > hour magic number sice the Max possible interval between router > advertisements is 30 minutes. I think the current text has enough information to be published (actually it was not changed from RFC2462), but I understand one may want to know the rationale. I don't quite remember the past discussion on this, but if someone can provide that information, I'm willing to add that to rfc2462bis. 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 --------------------------------------------------------------------
