Soohong Daniel Park Soohong.Park@SAMSUNG.COM

1. IPv6 DAD Optimization Goals and Requirements<draft-park-dna-ipv6dadopt-requirement-02.txt>IPv6 WG – 59th IETF, Seoul Soohong Daniel Park Soohong.Park@SAMSUNG.COM

2. Background • Latencies when performing IPv6 DAD • Not efficient in mobile environment (mobileip WG) • Required clarification of problem statements and requirements • Reviewed in DNA

3. The component pieces • Problem Statements • Time consuming by random delay • Time consuming by Autoconfiguration-related variables • Goals • To support for a node to send or receive packets immediately after attaching to a new link. • Solutions • Reducing and Reconfiguring existing variables (RetransTimer, Random Delay) • Stateless DAD Optimization • Stateful DAD Optimization • Requirements for the IPv6 DAD Optimization • RQ1 ~ RQ8

4. Requirements 1/3 • RQ 1: Backwards Compatibility with Original DAD • The optimized DAD mechanism MUST NOT break the RFC 2462 DAD mechanism, if used on the link by other nodes. • RQ 2: IPv6 Neighbor Cache • Changes to peers' Neighbor Caches which are due to DAD Optimization MUST be repaired in the case of a collision. Additionally, cache state created by DAD Optimization SHOULD be updated upon completion of DAD procedures if the created state could cause inconsistent neighbor discovery behavior. • RQ 3: Host Modifications • The DAD Optimization SHOULD allow for the use of original DAD and ND (Neighbor Discovery) to a host even if a host wants to be modified for DAD Optimization. For DAD Optimization, a host including neighbor MUST recognize modifications such as specific fields, flags, values, etc. • RQ 4: Router Modifications • A router which has been modified for DAD Optimization SHOULD interoperate with both the host modification for DAD Optimization as well as unmodified nodes.

5. Requirements 2/3 • RQ 5: Interoperability with SEND • The optimized DAD mechanism SHOULD work when SEND (Secure Neighbor Discovery) is used. It is desirable that the SEND and DAD Optimization work are closely coordinated so that it DAD Optimization could benefit from SEND and vice versa. • RQ 6: Simultaneous Operation with DNA • It SHOULD be possible to use optimized DAD addresses even before the DNA process has been completed. In other words, the hosts SHOULD be allowed to send packets to a newly attached link with the assumption that the link may be the same one that was previously used, without needing to wait for the DAD and/or DNA procedures to complete. Such practice MAY result in packet loss, and it MUSTNOT cause packet storms or excessive traffic in the case the newly attached link is not the previously used one and steal service from another node in the case that there is a collision, in a way which is not recoverable using [RFC 2462] DAD defense.

6. Requirements 3/3 • RQ 7: Address Duplication Considerations • In the case that collision occurs, the configuring node MUST inform the owner (or simultaneously configuring node) that the configuration attempt has occurred. In [RFC 2462], this occurs through the sending of the original Neighbor Solicitation packet. Additionally, if intermediate neighbor cache state on peers has been created, it MUST be repaired in conformance to RQ2. • RQ 8: Layer 2 Considerations • Generally, address duplication is happened to the same Interface ID which is composed of 48bit/64bit MAC address. Therefore, when same MAC address is existed in the same link, one of these nodes can not make its IPv6 address using address autoconfiguration mechanism. At this case, all nodes MUST be allowed to generate new addresses by another mechanism. It should be clarified that the mechanisms should be more discussed in the near future.

7. Moving forward • More clarifications and requirements if we need • adopt as part of new charter ?