1 / 14

Addressing Tunnel Issues in Networking: A Comprehensive Overview

This document explores the critical issues surrounding the use of tunnels in networking, examining motivation, known challenges, and the state of tunnel standards as of 2003. It discusses the importance of MTU, ICMP handling, fragmentation, and signaling within tunnel protocols. The document highlights the need for coordinated approaches to tunnel automation and the complexities of tunnel management. With a focus on ensuring effective tunnel communication over diverse L2 networks, this overview aims to stimulate discussion on unresolved issues to improve tunneling practices in future networking standards.

tamas
Download Presentation

Addressing Tunnel Issues in Networking: A Comprehensive Overview

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. draft-ietf-intarea-tunnels 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. Status • Current version • draft-ietf-intarea-tunnels-00, March 2010 • Tunnel security issues remains separate, cross-linked • Current plan: • Present to SOFTWIRE WG at this IETF • Gather additional examples • Address multipoint tunnels • Address additional issues collected • Revise and issue WG last call Sept 2010

More Related