> > => I'd rather use IPv6 if that's ok with everyone since > this doc is only applicable > > to IPv6. > > Hmm, I actually don't have a strong preference as long as the result > is consistent, but just "IP" seems to be more aligned with the sense > of Section 2.1: > > IP - Internet Protocol Version 6. The terms IPv4 and > IPv6 are used only in contexts where > necessary to avoid > ambiguity. => ok, I'll take a look at the specific instances and see which ones make sense to keep as IP and which ones need to be IPv6. > > So do you mean RFC3484 here? Then I guess we should be more generic, > e.g.: > > Note that this specification does not strictly comply with the > default address selection rules described in [RFC3484]. In > particular, it is possible in some cases for hosts to use a source > address of a larger scope than the destination address in the IPv6 > header, even if [RFC3484] would not prefer that combination. => Looks good. > >> 11. Section 6.3.4. (Processing Received Router Advertisements) > >> > >> Stateless address autoconfiguration [ADDRCONF] may in some > >> circumstances increase the Valid Lifetime of a prefix or ignore it > >> completely in order to prevent a particular denial of > >> service attack. > >> > >> "the Valid Lifetime of a prefix" is not really correct in > the context > >> of [ADDRCONF]; the lifetime is associated with addresses, not > >> prefixes. And [ADDRCONF] does not directly manipulate prefix > >> lifetimes. So, I think it's better to say, e.g.: > >> > >> Stateless address autoconfiguration [ADDRCONF] may in some > >> circumstances use a larger Valid Lifetime of a prefix or > >> ignore the > >> Valid Lifetime completely in order to prevent a particular denial > >> of service attack. > > > => I don't see how this is different from the above > though. Using a larger LT means > > you've increased it. > > My point was that there's a no notion of "Valid Lifetime of a > **prefix**" in [ADDRCONF]. It only has "Valid (and Preferred) > Lifetime of an address". That's why I suggested using "use". I > believe it clarifies the things a bit and is more accurate, but the > original text would not confuse the reader. So, I'd leave the > decision to you. => ok, point taken. I'll take another look while updating. > > => Since we removed all reference to IPsec except on its > limitations, I don't > > think we should add this one last bit because it might > confuse people. Realistically, > > IPsec is not going to be used with ND in a large network. > > Hmm...I agree with the "realistic" view itself, but unless > we prohibit > the use of IPsec, I believe it is overkilling to remove requirements > (using RFC2119 keywords) when it is used. > > Is it so harmful to revise the paragraph to, e.g., the following? > > In some cases, it may be acceptable to use statically configured > security associations with either [IPv6-AH] or [IPv6-ESP] > to secure > Neighbor Discovery messages. However, it is important to note that > statically configured security associations are not scalable > (especially when considering multicast links) and are therefore > limited to small networks with known hosts. In any case, when > [IPv6-AH] is used, received Authentication Headers in Neighbor > Discovery packets MUST be verified for correctness and > packets with > incorrect authentication MUST be ignored. => ok, fine with me, but I guess there is no reason to exclude [IPv6-ESP] from the second last sentence, and as a consequence modify the last sentence accordingly. If that's ok I'll update the last two sentences. Hesham > > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, > Toshiba Corp. > [EMAIL PROTECTED] > =========================================================== This email may contain confidential and privileged material for the sole use of the intended recipient. Any review or distribution by others is strictly prohibited. If you are not the intended recipient please contact the sender and delete all copies. =========================================================== -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
