Subject: a summary of proposals for rfc2462bis

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Thu, 05 Feb 2004 23:38:45 +0900

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-masked]

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-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------