1. IETF 651 Issues With Protocols Proposing Multilink Subnets draft-thaler-intarea-multilink-subnet-issues-00.txt Dave Thaler dthaler@microsoft.com

2. IETF 652 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

3. IETF 653 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).

4. IETF 654 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

5. IETF 655 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

6. IETF 656 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

7. IETF 657 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

8. IETF 658 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

9. IETF 659 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

10. IETF 6510 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