Tunnel Issues Review

1
Tunnel Issues Review

• Joe Touch, USC/ISI
• Mark Townsley, Cisco

2
Overview

• Motivation
• Known issues
• State of 2003, 4301 tunnels
• Questions
• Ways forward
• NB this is not about solutions this not WG
  chartering thisis about whether these are INT
  issues

3
Motivation

• Tunnel use common
• tunnelMTUICMP in 100 RFCs
• IPsec, L2TP/PPTP
• Mobile IP
• L1,2,2.5,3,3.5VPNs
• SEAL, LISP
• Potential need for automation
• 1300-byte MTU vs. can/should we do better
• Potential need to revise/coordinate
• Fragmentation handling, ICMP handling

4
Observation

• Tunnels are L2
• We create them
• Still subject to link issues,e.g., MTU
  discovery, signalling
• Advantages vs. other L2s
• Arguably easier to change
• When L2 protocol matches L3, it MAY be easier to
  align L2 and L3 MTU discovery, signalling, etc.

5
Known Issues

• MTU issues
• MTU discovery
• Fragmentation outer or inner
• Other signalling
• ICMP
• Performance issues
• IP-ID exhaustion
• Fragment size
• Packing (ala GigE packet bursting)

6
MTU Discovery

• Mechanisms
• ICMP-based (RFC 1191)
• Probe-based (RFC 4821, SEAL)
• Impact on E2E MTU discovery
• Forwarding/recomputing/validating ICMPs
• Encapsulator sending advisory too-bigs
• Tunnel MTU discovery
• Is internal mechanism required?
• See RFC 4459

7
Fragmentation

• Outer implies reassembly at decapsulator
• Inner affects IPv4 DF, reassy at dst

8
Signalling ICMP, etc.

• Pop control out of tunnel?
• E.g., ICMP underliverables, MTU discovery
• Send tunnel status to the original src?
• Push control into tunnel (ever)?
• (listed for completeness)

9
State of 2003 Tunnels

• MTU discovery
• On ingress, enforce outer DF drop/ICMP if too
  big
• Internally, MUST support ICMP-pmtud
• Fragmentation
• Mostly inner-only, i.e., IPv4
• MAY fragment inner iff IPv4 and DF0
• MUST NOT fragment outer if DF1 is set

10
2003 Signalling

• MAY relay ICMPs from inner to outer
• SHOULD relay net/host unreach
• MUST NOT relay port unreach
• MUST relay too big
• MUST NOT relay, SHOULD handle locally route
  error, source quench
• SHOULD keep soft state to assist relay

11
State of 4301 Tunnels

• MTU discovery
• IPv4/DF1, SHOULD discard and send ICMP
• IPv4/DF0, SHOULD fragment outer, and SHOULD NOT
  send ICMP
• IPv6 SHOULD discard and send ICMP
• DF may be copy, clear, set
• Fragmentation
• Fragments outer only
• MAY have diff SAs for inner fragments

12
4301 Signalling

• Relay and recompute too-big
• Each type/code may be blocked, as per SA
• Others are relayed after validation

13
Fundamental Questions

• Which tunnel model?
• Opaque/emulation at least as good as path
• Visible as if a new link
• Which parties participate?
• Only tunnel endpoints (encap/decap)
• Architecturally simpler
• Encap/decap/dest host
• Distributes work by delaying it
• Assumes work can be distributed when delayed

14
Ways Forward

• Document this overview?
• Fix existing standards
• RFCs 791, 2003, et al.
• Develop new solutions
• MTU discovery issues/solutions
• SEAL, DF/IPv6 rules for too-big
• Fragmentation solutions
• E.g., SEAL, LISP, etc.
• Signalling issues
• Esp. unreach, etc.
• Optimization issues
• Esp. IP-ID fix

15
Extras -------------------------------------
16
IP-ID Exhaustion

• Tunnel aggregation
• Increases packet rate
• Decreases source/dest IP addr variability
• IPv4 problem
• Src/dst/proto/IP_ID uniqueness within 2MSL
• Proto is constant (4), src/dst addrs are limited
• Limits BW to 2.5Mbps (576B), 6.5Mbps (1500B), or
  286Mbps (64KB)

17
Fragment Size

• Divide by N may reduce further frag., but
  increase packet size variation
• Fill and leftover is reference code

18
Packing

• Increases MTU over tunnel, which may increase
  efficiency over high-speed aggregate paths
• Are packets split across frames?