Hello, I'm now working on the rfc2462bis document, and I've done the work for most of the issues I raised in the previous draft and presented in Minneapolis with my own proposed resolutions (which should be discussed and agreed by the wg, of course). I've revised the rfc2462bis text with the resolutions, which will be posted before the I-D cutoff date for initial submissions (Feb 9th).
The attached below is a summary of the proposals. I believe most of them are trivial or based on the consensus of the wg (so I'm simply posting a summary), but I'll make separate threads for those that might be controversial. There are still some open issues, for which I'll make separate threads to hear opinions/comments. You can see detailed notes and specific changes at the rt.psg.com issue tracker: https://rt.psg.com/ user/password=ietf/ietf issue queue: ipv6-2462bis Please make comments if you find problems in the proposals by making a separate thread. If the comments can easily be addressed, I'll put the resolution to the new revision before submitting it. Thanks, JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. [EMAIL PROTECTED] Issues that have proposals (basically from draft-jinmei-ipv6-rfc2462bis-00.txt, and IDs at the issue tracker for reference): ID Issue/Proposed Resolution ------------------------------------------------------------------ 264 There is dead code in the DoS prevention algorithm in Section 5.5.3 => Proposed Resolution: simply remove the redundant code. 265 Unclear text about a corner case in the inbound Neighbor Advertisement processing. => Proposed Resolution: clarify that a unicasted NS/NA should be discarded. 266 Unclear text about StoredLifetime. => Proposed Resolution: clarify the text (no change in the behavior, but replace StoredLifetime with RemainingLifetime for clarification) 267 since the wg are going to deprecate SL addresses, it would also make sense to remove references to site-local from this document. => Proposed Resolution: remove references to site-local and revise wording around the keyword. 268 Source address selection issues with regards to deprecated addresses. E.g., which one should be preferred as a source address, between a deprecated address and a smaller-scope address? => Proposed Resolution: add a simple note on this and a reference to RFC3484. detailed description on this is out of scope of this document. 269 The semantics of "new communication" is not very clear; is a passively opened TCP connection a new communication? What if an application specifies a deprecated address as a source address? => Proposed Resolution: revise the first paragraph of Section 5.5.4 so that - it clearly says incoming TCP-SYN to a deprecated address must be accepted. - it clearly says if the application specifies to use a deprecated address explicitly, the protocol stack must accept that. 270 There was a question about the semantics where the on-link (L) flag is 0 and the autonomous (A) flag is 1. => Proposed Resolution: no change for this. 271 An implementation may want to use stable storage for autoconfigured addresses. => Proposed Resolution: add a subsection in Section 5 to mention this (without mandating anything). DAD must be run after rebooting. (Note: this resolution may be controversial) 272 This document may need to be aligned with the SEND requirement draft in its security consideration. => Proposed Resolution: revise the second paragraph of Security Considerations so that: - add an informative reference to send-psreq - note that the use of IPsec is not always feasible 273 802.11 specification requires a link-layer filtering that conflicts with the condition to make DAD work correctly. => Proposed Resolution: add a note in Appendix A about this issue. Also refer to the wlan-dad draft (or perhaps the 802.11 274 There is conflict with the Multicast Listener Discovery specification about random delay for the first packet. The address autoconfiguration requires a random delay for a DAD packet if it is the first packet from the node, but an MLD report packet should usually be sent before the DAD packet. => Proposed Resolution: add a workaround to impose a random delay for DAD NS even after the first MLD. (Note: this resolution may be controversial since it may affect exiting implementations) 276 There is a possible denial of service attack not discussed: What if a malicious node intentionally sends prefixes for other LANs? => Proposed Resolution: no change for this (this is actually covered by send-psreq) (Note: we may still have to note this because this points out the two-hour rule for DoS avoidance may cause another DoS) 278 Whether a router (not a host) can autoconfigure itself using the stateless autoconfiguration protocol may need to be discussed. => Proposed Resolution: do nothing (this was actually pretty clear) (Note: but we may have to clarify if the definition of "router" is per-interface basis) 279 Should this document define a 'not-yet-ready' status of an autoconfigured address to help renumbering operation? => Proposed Resolution: nope. 280 The requirement about the interface failure upon DAD failure may be too strong. Does it make sense to loosen it, e.g., allowing automatic recovery? => Proposed Resolution: add "An implementation MAY try an automatic recovery technique from this failure and re-enable the interface." (Note: this may not be enough, based on a discussion in last November) 321 Preferred lifetime and the 'two-hour' rule => Proposed Resolution: clearly say that the preferred lifetime should be set the advertised value unless the prefix information option is ignored in the "two-hour" rules. Issues that are still open 275 Many DAD related issues have been discussed, including if it is okay to omit DAD in some environments or if DAD can be replaced with DIID (duplicate interface ID detection). 277 The semantics of the M/O flags is not very clear. 281 It is not very clear if this document always require a 64-bit Interface ID. -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
