1 / 6

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

IPv6 DAD Optimization Goals and Requirements <draft-park-dna-ipv6dadopt-requirement-01.txt>. Soohong Daniel Park / Youn-Hee Han / Greg Daley Soohong.Park@SAMSUNG.COM 58 th IETF / DNA BOF in Minneapolis. Motivation. Latency when performing IPv6 DAD

falala
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. IPv6 DAD Optimization Goals and Requirements<draft-park-dna-ipv6dadopt-requirement-01.txt> Soohong Daniel Park / Youn-Hee Han / Greg Daley Soohong.Park@SAMSUNG.COM 58th IETF / DNA BOF in Minneapolis

  2. Motivation • Latency when performing IPv6 DAD • Not efficient in mobile environment (mobileip WG) • Proposed some mechanisms • Optimistic DAD • Advance DAD • Etc… • 57th IETF decided IPv6 DAD Optimization as one of the items in DNA BoF • Requires clarification of problem statements and requirements

  3. Goals • Problem Statements • Time consumed by random delay • Time consumed by Autoconfiguration-related variables • Goals • To support 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

  4. Requirements 1/2 • RQ 1: Backward compatibility with Original DAD • When an original DAD is performed to verify address duplication, there happened to be some delays (is defined in [RFC 2462]) in this case. In order to reduce delays, optimized DAD should be required to provide faster handover in the IPv6 mobility. Though, at the same time, it should be noted that the DAD Optimization MUST NOT break the original DAD mechanism. • RQ 2: IPv6 Neighbor Cache • Changes to peers’ NC which 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 bahavior. • RQ 3: Host Modifications • The DAD Optimization SHOULD allow for the use of original DAD and NDP (Neighbor Discovery Protocol) 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 not interfere with hosts operating correctly. In particular, a router has to interoperate with both the host modification for DAD Optimization as well as unmodified nodes.

  5. Requirements 2/2 • 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. • 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.

  6. Moving Forward • More clarifications and requirements if we need • Either IPv6 WG or DNA BOF ?

More Related