1 / 7

Uniqueness Properties of Interface Identifers (IIDs), and DAD vs. DIID

Uniqueness Properties of Interface Identifers (IIDs), and DAD vs. DIID. IPv6 address architecture spec (RFC 2373, draft-ietf-ipngwg-addr-arch-v3-08.txt) says that IIDs of unicast addresses must be unique on a link, independent of subnet prefix i.e., this is illegal:. link-local::1.

aria
Download Presentation

Uniqueness Properties of Interface Identifers (IIDs), and DAD vs. DIID

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. Uniqueness Properties of Interface Identifers (IIDs), and DAD vs. DIID IPv6 address architecture spec (RFC 2373, draft-ietf-ipngwg-addr-arch-v3-08.txt) says that IIDs of unicast addresses must be unique on a link, independent of subnet prefix i.e., this is illegal: link-local::1 subnet-prefix-X::1 subnet-prefix-Y::1

  2. Pros / Cons • the alternative would be to require only that unicast addresses be unique on a link, so previous example would become “legal” • advantages of current requirement: • if DAD succeeds on link-local address, can omit doing DAD on other addresses with same IID => less overhead on link • when managing/diagnosing networks, convenient to have each IID identify a different node, regardless of prefix • disadvantages of current requirement : • more restrictive than necessary for “correctness” • misunderstanding of requirement has lead to inconsistencyin our specs

  3. Document Inconsistencies • Addr Arch (RFC 2373) requires uniqueness of unicast IIDs • Stateless Addr Conf (RFC 2462) allows DAD on link-local alone, but only for statelessly autoconf’ed IIDs • Temporary/Privacy Addr spec (RFC 3041) requires DAD only for generated (global) addrs • DHCPv6 draft spec doesn’t say anything about uniqueness requirements of assigned IIDs (?)

  4. Issues to Resolve • what do we want the uniqueness properties to be? • what do we want to “enforce” via DAD (or DIID), which may be different than what we require? • what document changes are needed to clean this up? • what implementation changes are needed to clean this up?

  5. One Proposal from the Chairs omit DAD for any address containing an IID derived from IEEE 802 or EUI-64 MAC, or generated at random al la RFC 3041 • probability for collision is already very low • yes, probability is non-zero, but DAD isn’t 100% reliable anyway • in our opinion, main reason for DAD is to defend against duplicates from manual configuration or small DHCP pools

  6. Consequences of Proposal • would require text updates to: • stateless addr conf • privacy addr spec • basic addr arch (maybe, depends on choice of uniqueness model) • DHCPv6 spec? but, doesn’t require any implementation changes • would eliminate delay and overhead of DAD on links where IEEE-802/EUI-64 derived addresses or random addresses are used

  7. Discussion?

More Related