Issues With Protocols Proposing Multilink Subnets draftthalerintareamultilinksubnetissues00'txt

1
Issues With Protocols Proposing Multilink
Subnetsdraft-thaler-intarea-multilink-subnet-issu
es-00.txt

• Dave Thaler
• dthaler_at_microsoft.com

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

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 nodes home link
  (singular).

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

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

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

7
TTL/Hop Limit issues

• Application/protocol assumptions about
  relationship between TTL and being on same subnet
• Send with TTL1
• Send with TTL255, 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 TTL1 or 255
  without (documented) assumptions about
  relationship to prefix
• MLDv2, Bonjour, LLMNR, MIPv4 reverse tunneling,
  etc.
• Proxying per protocol/application doesnt scale

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/HopLimit255 on receipt
• If removed or proxied, would need some other
  mitigation

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 doesnt scale (and may
  hinder future use of link-scoped multicast)
• Lack of multicast doesnt inherently break the IP
  model (NBMA interfaces do exist)
• Just limits applications/protocols that work

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