Subnetwork Encapsulation and Adaptation Layer (SEAL) IETF 71 intarea session Fred L. Templin

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 End-to-End Final Destination (MRU=9KB) Tunnel MTU=9KB MTU=64KB Original Source (MTU=9KB) MTU=9KB Site B Egress Tunnel Endpoint MRU=4KB MTU=9KB MTU=4KB Ingress Tunnel Endpoint MTU=?? MTU=2KB Site A

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. ICV (2 Bytes) Payload Inner Headers (IP, IP/ESP, etc.) SEAL Header (4 Bytes) Outer Headers (IP, UDP/IP, etc.) Approach • Lightweight mid-layer encapsulation • New IP protocol (or embedded sublayer) • Updates existing IP tunnel mechanisms 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 Site Site Site Site Subnetwork Site Site Site Site 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