IPv6 DAD Optimization Goals and Requirements <draft-park-dna-ipv6dadopt-requirement-02.txt> IPv6 WG

1
IPv6 DAD Optimization Goals and
Requirementsltdraft-park-dna-ipv6dadopt-requiremen
t-02.txtgtIPv6 WG 59th IETF, Seoul

• Soohong Daniel Park
• Soohong.Park_at_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 MUST NOT 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 ?