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

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

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

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

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

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

7. 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 in- flight when a routing change hits an MTU restriction: all packets are dropped flood of ICMPs returned to ITR resources wasted

8. How Does SEAL Solve the Problems? Classical path MTU discovery for packets > 2KB Compatible with end-to-end MTU determination (RFC4821) Carefully managed fragmentation for packets <= 2KB: 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

9. Why 2KB 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 2x 1KB segments) Reasonable minimum MRU for ETEs

10. Why Use Managed Fragmentation? Classical PATH MTU discovery ALWAYS drops pkts; managed fragmentation maximizes packet delivery Dampens IPv4 fragmentation (IPv4 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

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

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

13. 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 (~10kbps or slower) For smaller-than-256 MTUs, allow a small amount of IPv4 fragmentation to match the link MTU

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

15. Backups

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

17. 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)

18. 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 RFC1063) 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 – RFC1191 - Path MTU Discovery 1993 – IESG Advice on MTU Discovery (RFC1435) 1995/6 – Tunnel MTU Discovery (RFC1853; 2003) 1996 – RFC1981 – Path MTU Discovery for IPv6 1997 – IPv6 minimum MTU changed to 1280 from 576 2000 – MTU issues first documented (RFC2923) 2000 onward – tunnel MTU issues documented

19. Subnetwork Model Site

20. Why Not Drop and Send ICMP PTBs? Send PTBs only for packets > 2KB 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