Re: [Int-area] WG Adoption Call: IP Fragmentation Considered Fragile

Joe Touch <> Tue, 28 August 2018 13:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CE2C7130F1D; Tue, 28 Aug 2018 06:43:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.988
X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vIlBfbamKXov; Tue, 28 Aug 2018 06:43:30 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 491FF130F18; Tue, 28 Aug 2018 06:43:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=Message-ID:References:In-Reply-To:Subject:Cc: To:From:Date:Content-Type:MIME-Version:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=+4/PpZfSG+8KJ1nZAblAD/wKQsT2zxoiIiuSHsKvtII=; b=5qjwoz9H6Lf5c7Lr2JndY3VRi CK26ts57eienykKtqADyOjqGFj9Ju17jHgSlxkPyRWAmcRwKKLd/izThNwT0TomVTyya1dZgBdLKo q0aeL19x5DaYA96LFQjO7EGPQK9NnCZ3Og59AfM0UaB1qD4cffntEzbkisXPgVG8OV9oY7iqtJr3O ZwHYXQ3JLxazoM/aHjTUN9OVV5ykUHiSegsHkG+WuakyEMe3jTuLavJEGsKCeLGt/k2hzyIqetK3Q 1r8G9kYTUxCFpXPqyQIgFGdh0CnFJWEXfdcXIhy5zLe6h2tLeogHiE0cnkAPyECFGF4WhvDMjW7ve XjeeBtHKw==;
Received: from [::1] (port=50226 by with esmtpa (Exim 4.91) (envelope-from <>) id 1fueHG-0008hU-G8; Tue, 28 Aug 2018 09:43:27 -0400
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_4ac0b59f23943596d97a9dab8f15b3d7"
Date: Tue, 28 Aug 2018 06:43:26 -0700
From: Joe Touch <>
To: Ole Troan <>
Cc: Tom Herbert <>, int-area <>, Toerless Eckert <>,
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <A9F9EFD0-D246-4883-8462-0074280559> <> <> <> <>
Message-ID: <>
User-Agent: Roundcube Webmail/1.3.3
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-Get-Message-Sender-Via: authenticated_id:
X-From-Rewrite: unmodified, already matched
Archived-At: <>
Subject: Re: [Int-area] WG Adoption Call: IP Fragmentation Considered Fragile
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: IETF Internet Area Mailing List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 28 Aug 2018 13:43:33 -0000


On 2018-08-27 01:52, Ole Troan wrote:

> Joe, 
> ... 
> The principles are described and explained here: 
> Touch, J: Middlebox Models Compatible with the Internet [1]. USC/ISI (ISI-TR-711), 2016. ( 
> I don't want to dismiss this completely, but it hand waves over how applications are supposed to work in this new Internet architecture.  
> You can define your way out of breaking end-to-end, but that doesn't mean you can ignore all the issues of NAT traversal.

You've missed the point - if the middleboxes describe behave as
required, apps do not need to change. They work as they would in an
Internet without those boxes. 
Quite likely. 
Do you have a document describing how my SIP application works? 
Ore are you saying PCP, ICE, TURN etc is part of your architecture? 

This document provides the needed context in which to interpret apps and
network services. 

If you understand that the endpoints of the Internet SIP application are
the NAT and the server, not the host on the NAT's private side, you
understand most of what you need to know. I.e., the SIP client is trying
to trigger behavior in the NAT, but not knowing the source IP or source
port unless discovered or told directly. That's why in-band addresses
don't work without additional mechanisms such as PCP, ICE, and TURN. 

I'm not saying you don't need those mechanisms - but rather that the
model I propose explains what is needed and why directly. I.e., as long
as your app acts like it actually runs on the NAT box, it'll work just
fine; to the extent that you don't want to do that, the onus is on you
to support moving it to the hidden client host on the private side.