Hi, My initial thought is also that we should not make RFC 2461bis (or 2462bis) include every extension specified since 1998. Those can stay very well in separate drafts. Of course, we should still consider whether we want to enable the base spec to give more flexibility (e.g., the solicitation timers etc.) for those extensions. There is a clear distinction between these two, IMHO.
Another thought: if we recycle RFC2461bis to DS, I think we should re-do the implementation reports if we changed the code (not sure whether new reports is _required_..). This may not be a bad thing, as the current implementation reports should (IMHO) be a bit more detailed than that.. However, there are some things which need addressing now. Inline about two IMHO important classes of issues.. On Fri, 24 Oct 2003, Bound, Jim wrote: [...] > > Issue 3: On-link assumptions in 2461 considered harmful. > > This issue was raised by Alain and documented in: > > draft-ietf-v6ops-onlinkassumption-00.txt > > draft-ietf-v6ops-v6onbydefault-00.txt > > Also see related issue in section 2.4 of: > > http://www.ctie.monash.edu.au/ipv6/draft-jinchoi-ipv6-cRA-00.txt > > This is nothing more than a note and should not be put into 2461. On the contrary, I believe this will of critical for the success of IPv6, and MUST BE dealt with. Whether the WG thinks it is just enough to explicitly state the tradeoffs here, or whether the spec needs to be changed is a different subject. > > SEND issues: > > > > Issue 7: All the security discussions (e.g. assuming that AH > > or ESP can be added to the ND messages) will need to > > be put in the context of SEND. > > > > Issue 8: Security considerations section needs to consider issues > > in: draft-ietf-send-psreq-04 > > > > Issue 9: The chicken and egg problem for ND security using IKE > > as specified in: > > draft-arkko-icmpv6-ike-effects-02 > > > > and manual SAs issues addressed in: > > draft-arkko-manual-icmpv6-sas-02 > > ND with IPsec is secure. Mobile creates new attacks. SEND should do > their own spec and add value to ND. ND should not be updated. I argue > and question the entire notion of SEND all the time. Not going there > again. It is simply not needed for non mobile environments. I think it may not have been clear what these issues imply. To me, it seems clear that we will not be creating a new "secure ND" out of RFC2461bis. However, now that we're identified the shortcomings of ND from the SEND work, we MUST include (some) discussion on these subjects in this spec. This may also result in some changes or optional toggles to make "plain ND" a bit more resistant to attacks, but that's not necessary as long as the issues are documented so the implementors and the users of ND are aware of them. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
