1 / 7

Ensuring MTU Assurance for IP-in-IP Tunnels Across Multiple L2 Segments

The IP-in-IP tunneling mechanism faces challenges in assuring the Maximum Transmission Unit (MTU) when spanning multiple Layer 2 segments. Existing methods rely on fixed MTU sizes or allow IPv4 fragmentation, which leads to performance issues and potential packet loss due to firewalls and NATs. This document outlines the requirements for a new mechanism that enables tunnel endpoint negotiation, backward compatibility with existing IPv4 fragmentation methods, and proactive MTU probing to effectively manage packet delivery and avoid black holes. The focus is on enhancing tunnel performance, particularly in environments with NATs and firewalls.

lindsey
Download Presentation

Ensuring MTU Assurance for IP-in-IP Tunnels Across Multiple L2 Segments

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. Requirements for IP-in-IP Tunnel MTU Assurance V6OPS Working Group - IETF 64 Fred L. Templin fred.l.templin@boeing.com

  2. Problem Statement • IP-in-IP tunnels span multiple L2 segments but are seen by L3 as ordinary links that must present an assured MTU • Common tunneling mechanisms set fixed MTU (e.g.,1280 bytes or larger for IPv6), but cannot assure delivery for packets of that size. Current approaches: • don’t set the DF bit and allow IPv4 fragmentation • set the DF bit and watch for ICMPv4 fragmentation needed msgs, i.e., use IPv4 Path MTU Discovery

  3. Problems with IPv4 Fragmentation • No mechanism for determining decapsulator’s MRU • Network-based IPv4 fragmentation has negative impact on performance • IPv4 fragmentation can result in black holes when firewalls/NATs in the path

  4. Problems with IPv4 PMTUD • ICMPv4 fragmentation needed messages can be spoofed by on/off-path adversaries; dropped or altered by on-path adversaries • ICMPv4 fragmentation needed messages can’t always be translated into ICMPv6 packet too big messages

  5. Requirements for New Mechanism • tunnel endpoint negotiation (means for encapsulator to determine whether decapsulator implements scheme) • Backwards compatibility with IPv4 fragmentation; IPv4 PMTUD • “Above-IPv4” host-based segmentation at the encapsulator • “Above-IPv4” reassembly at the decapsulator

  6. Requirements for New Mechanism • Packet splicing error detection • Accommodate out-of-order delivery • Means for encapsulator to probe PMTU • Means for decapsulator to send authenticated probe response • Proactive path probing to determine best MTU; detect MTU-related black holes • Means to discover decapsulator’s MRU

  7. Summary • Existing tunnel mechanisms have no means of assuring tunnel MTU • Most problematic for tunnels that traverse NATs; Firewalls • Tunnel MTU assurance needed for tunnels that span NATs; Firewalls

More Related