Tunnel Issues Review
Joe Touch, USC/ISI
Mark Townsley, Cisco
7/28/2017 7:56 PM
1
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
7/28/2017 7:56 PM
2
Motivation
 Tunnel use common





tunnel+MTU+ICMP in ~100 RFCs
IPsec, L2TP/PPTP
Mobile IP
L[1,2,2.5,3,3.5]VPNs
SEAL, LISP
 Potential need for automation
 1300-byte MTU vs. can/should we do better
 Potential need to revise/coordinate
 Fragmentation handling, ICMP handling
7/28/2017 7:56 PM
3
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.
7/28/2017 7:56 PM
4
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)
7/28/2017 7:56 PM
5
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/28/2017 7:56 PM
6
Fragmentation
 Outer implies reassembly at decapsulator
 Inner affects IPv4 DF, reassy at dst
7/28/2017 7:56 PM
7
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)
7/28/2017 7:56 PM
8
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 DF=0
 MUST NOT fragment outer if DF=1 is set
7/28/2017 7:56 PM
9
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
7/28/2017 7:56 PM
10
State of 4301 Tunnels
 MTU discovery
 IPv4/DF=1, SHOULD discard and send ICMP
 IPv4/DF=0, 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
7/28/2017 7:56 PM
11
4301 Signalling
 Relay and recompute too-big
 Each type/code may be blocked, as per
SA
 Others are relayed after validation
7/28/2017 7:56 PM
12
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
7/28/2017 7:56 PM
13
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
7/28/2017 7:56 PM
14
Extras ------------------------------------
7/28/2017 7:56 PM
15
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)
7/28/2017 7:56 PM
16
Fragment Size
 Divide by N may reduce further frag., but
increase packet size variation
 Fill and leftover is reference code
7/28/2017 7:56 PM
17
Packing
 Increases MTU over tunnel, which may
increase efficiency over high-speed
aggregate paths
 Are packets split across frames?
7/28/2017 7:56 PM
18