1 / 18

Tunnel Issues Review

Tunnel Issues Review. Joe Touch, USC/ISI Mark Townsley, Cisco. Overview. Motivation Known issues State of 2003, 4301 tunnels Questions Ways forward NB: this is not about solutions; this not WG chartering; this is about whether these are INT issues. Motivation. Tunnel use common

jkeefer
Download Presentation

Tunnel Issues Review

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. 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 • 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

  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 DF=0 • MUST NOT fragment outer if DF=1 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/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

  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?

More Related