Subnetwork Encapsulation and Adaptation Layer SEAL IETF 71

Subnetwork Encapsulation and Adaptation Layer (SEAL) IETF 71 intarea session Fred L. Templin fred. l. templin@boeing. com

Problem Statement • • Tunnels connect routers across routing regions with heterogeneous links In-the-network router-to-router tunneling presents issues for MTU determination

MTU for In-the-Network Tunnels End-to-End Final Destination (MRU=9 KB) Tunnel MTU=9 KB Original Source (MTU=9 KB) MTU=9 KB MTU=64 KB MTU=9 KB Site A Ingress Tunnel Endpoint MTU=? ? MTU=4 KB MTU=2 KB Egress Tunnel Endpoint MRU=4 KB Site B

Domains of Application • • • Global interdomain routing core (RRG problem space) Mobile Ad-hoc Networks (MANETs) Enterprise networks Unmanaged networks Mobile IP tunnels Any routing region bordered by ITRs/ETRs

Requirements • Detect and dampen in-the-network fragmentation Avoid reassembly misassociations Utilize larger MTUs when available Efficient use of resources Multi-protocol Operation Lightweight Duplicate Packet Detection • Generic convergence and adaptation layer • • •

Approach Lightweight mid-layer encapsulation New IP protocol (or embedded sublayer) Updates existing IP tunnel mechanisms • • • 0 1 2 ICV (2 Bytes) 3 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID Extension |M|C|I|CTL| Seg#| Next Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Payload ID Extension (16 bits) M - more segments C - congestion experienced I - integrity check vector included CTL – ’ 00’(non-probe), ’ 01’ (FRAGREP), ’ 1 x’ (probe) Seg# - segment number from 0 - 7 Next Header (8) – same as IP protocol/next header Inner Headers (IP, IP/ESP, etc. ) SEAL Header (4 Bytes) Outer Headers (IP, UDP/IP, etc. )

Problems with Classical Path MTU Discovery • • ICMPs may be lost, erroneous, fabricated ICMPs may have insufficient information for relaying ALWAYS drops packets when MTU insufficient In-the-network tunnels may have 1000’s of packets inflight when a routing change hits an MTU restriction: • • • all packets are dropped flood of ICMPs returned to ITR resources wasted

How Does SEAL Solve the Problems? • Classical path MTU discovery for packets > 2 KB • • Compatible with end-to-end MTU determination (RFC 4821) Carefully managed fragmentation for packets <= 2 KB: • • ITR sends with outer DF=0; listens for FRAGREPs ETR sends FRAGREPs if fragmentation detected ITR uses mid-layer segmentation to dampen IP fragmentation ETR reassembles using 32 -bit packet identification

Why 2 KB Fragmentation Limit? • • • Generous room for extra encapsulations added to original source’s 1500 byte packets on path to ITE Generous room for extra encapsulations on path to ETE (for 2 x 1 KB segments) Reasonable minimum MRU for ETEs

Why Use Managed Fragmentation? • • Classical PATH MTU discovery ALWAYS drops pkts; managed fragmentation maximizes packet delivery Dampens IPv 4 fragmentation (IPv 4 fragmentation as pain point to transition out of) Gracefully handles routing changes onto smaller MTU paths, as well as multipath routes with diverse MTUs Can search upwards to determine if larger MTUs possible w/o exposing data packets to loss

What About Inner Packets with DF=0? • • When necessary, ITE will use inner IP fragmentation final destination will reassemble

What About Inner Packets with DF=1? • • • When necessary, ITE will use SEAL segmentation ETE will reassemble It is OK to segment these AS LONG AS THE ETE PUTS THEM BACK TOGETHER AGAIN before forwarding

What About Links with Tiny MTUs? • • • Assume vast majority of links configure an MTU of 256 bytes or larger Assume that smaller-than-256 MTU links are also low bandwidth (~10 kbps or slower) For smaller-than-256 MTUs, allow a small amount of IPv 4 fragmentation to match the link MTU

What About Multicast? • Works exactly the same as for unicast (discovers lowest-common-denominator MTU thru FRAGREPs)

Backups

FFS - Loss Unit Smaller Than Retransmission Unit • • • “Fragmentation Considered Harmful” used congestion implications for lost fragments as condemnation of all fragmentation Solution – MANAGE CONGESTION ETE reports “congestion experienced”; ITE backs off

FFS - Integrity • • ITE includes ICV if packet might incur IP fragmentation ITE omits ICV if the next higher layer already has strong integrity checks (e. g. , IPsec/ESP) ETE verifies ICV only if packet requires reassembly (discards packets with incorrect ICV) ICV sums every N’th byte of the packet (light weight; splicing error detection)

Brief History of Path MTU Discovery • • • 1987 – Report Fragmentation scheme proposed in TCP -IP working group discussions 1987 - “Fragmentation Considered Harmful”; proposed IP MTU discovery options (later became RFC 1063) 1989 – Path MTU Working Group formed: • • • Report Fragmentation approach favored, but abandoned because “spare” IP header bit unavailable (the “evil” bit) Drop and send PTB approach adopted 1990 – RFC 1191 - Path MTU Discovery 1993 – IESG Advice on MTU Discovery (RFC 1435) 1995/6 – Tunnel MTU Discovery (RFC 1853; 2003) 1996 – RFC 1981 – Path MTU Discovery for IPv 6 1997 – IPv 6 minimum MTU changed to 1280 from 576 2000 – MTU issues first documented (RFC 2923) 2000 onward – tunnel MTU issues documented

Subnetwork Model Site Site Site

Why Not Drop and Send ICMP PTBs? • • • Send PTBs only for packets > 2 KB known to be too big – NO PTBs UNDER ANY OTHER CIRCUMSTANCES PTBs ALWAYS imply loss; source will retransmit Can’t send PTBs 1 -to-1 for dropped packets at high data rates (ICMP rate-limiting) Wastes resources (at least 3 transmissions for each dropped packet) Original sources might not get the PTBs anyway