1 / 10

Dave Thaler dthaler@microsoft

Issues With Protocols Proposing Multilink Subnets draft-thaler-intarea-multilink-subnet-issues-00.txt. Dave Thaler dthaler@microsoft.com. Definitions. Link: topological area bounded by routers which decrement the IPv4 TTL or IPv6 Hop Limit when forwarding

barbaragjones
Download Presentation

Dave Thaler dthaler@microsoft

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. Issues With Protocols Proposing Multilink Subnetsdraft-thaler-intarea-multilink-subnet-issues-00.txt Dave Thaler dthaler@microsoft.com IETF 65

  2. Definitions • Link: topological area bounded by routers which decrement the IPv4 TTL or IPv6 Hop Limit when forwarding • Subnet: topological area that uses the same address prefix, where that prefix is not further subdivided except into individual addresses • Multilink subnet: subnet that spans multiple links IETF 65

  3. Current IP Model • RFC 1884, 2373, 3513 (IPv6 Addr Arch): "Currently IPv6 continues the IPv4 model that a subnet prefix is associated with one link. Multiple subnet prefixes may be assigned to the same link.” • RFC 3753 (Mobility Related Terminology) is consistent with this in defining home subnet prefix: “identifies a node’s home link” (singular). IETF 65

  4. Internet Area seems to be fragmenting • IPv6 WG considered supporting multilink subnets, and rejected it • Multiple variants of multilink subnets exist • MIPv6 WG uses multilink subnet for home address prefix • Some MANET/Autoconf WGs drafts assume multilink subnets • NetLMM • etc IETF 65

  5. Why did the IPv6 WG reject Multilink Subnets? • Affects an arbitrarily large set of upper-layer applications and protocols, due to: • Changes to IP Model break assumptions • DAD issues • TTL/Hop Limit issues • Security issues • Multicast/broadcast issues IETF 65

  6. Duplicate Address Detection • 2462 allowed for Duplicate Interface Identifier Detection: • Just test link-local address for uniqueness, skip DAD for other addresses with same identifier • No longer recommended but implementations already exist • Address conflicts could occur in a multilink subnet IETF 65

  7. TTL/Hop Limit issues • Application/protocol assumptions about relationship between TTL and being on same subnet • Send with TTL=1 • Send with TTL=255, checked on receipt • Many well-known sources have the assumption that link == subnet (TCP/IP Illus., Unix Net.Prog., Windows docs, Linux docs) • Hence this belief is widespread, and may appear in arbitrary applications • Neighbor Discovery relies on this assumption • Many other protocols/apps use TTL=1 or 255 without (documented) assumptions about relationship to prefix • MLDv2, Bonjour, LLMNR, MIPv4 reverse tunneling, etc. • Proxying per protocol/application doesn’t scale IETF 65

  8. Security issues • Secure Neighbor Discovery is only defined within a single link • Some work on supporting ND proxies, but how many variants? • Some applications and protocols mitigate against off-link spoofing attempts by requiring TTL/HopLimit=255 on receipt • If removed or proxied, would need some other mitigation IETF 65

  9. Link-scoped multicast/broadcast • Since link-scoped, generally not propagated across subnet • Lots of link-scoped protocols listed on IANA • Large number of other applications using all-hosts/broadcast • Most typically effect is just lack of operation across subnet, without proxying • Proxying per protocol doesn’t scale (and may hinder future use of link-scoped multicast) • Lack of multicast doesn’t inherently break the IP model (NBMA interfaces do exist) • Just limits applications/protocols that work IETF 65

  10. Discussion Should we: A) Stick to the classic IP model: update MIPv6 provide guidance to other WGs B) Change the IP model: update many upper-layer protocols update many applications update documentation etc C) Continue fragmenting IETF 65

More Related