Subject: [Fwd: Re: [RRG] Re: [RAM] Tunneling overheads and fragmentation]

From: Brian E Carpenter <[email-masked]>
Date: Fri, 14 Sep 2007 07:54:17 +1200

For those who aren't following the routing & addressing
discussions, there's been some discussion on MTU size
issues and tunnel-based solutions. See below, but it did
strike me that 2460 doesn't *explicitly* say "don't send
more than 1280 bytes unless you determine that a larger
MTU will work." It's implied but not stated.

     Brian

-------- Original Message --------
Subject: Re: [RRG] Re: [RAM] Tunneling overheads and fragmentation
Date: Thu, 13 Sep 2007 10:23:06 -0700
From: Dino Farinacci <[email-masked]>
To: Brian E Carpenter <[email-masked]>
CC: Gert Doering <[email-masked]>, Robin Whittle <[email-masked]>,        RRG <[email-masked]>

> I just re-read RFC 2460 section 5. Admittedly things are less
> clear for IPv4, but it seems clear that IPv6 senders should not
> exceed 1280 bytes (pre-encapsulation) unless they have succeeded
> in discovering a larger path MTU.

Nice to hear some good news for a change.  ;-)

Thanks,
Dino

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 18 Sep 2007 13:43:30 -0700

Brian,

After having discussed with others, please see attached
for a proposal that addresses the MTU issues for tunnels.
It also addresses the multi-mtu subnet issue, since it
does not rely on ICMP "packet too big" messages from the
last-hop router. Elements of the proposal include:

  - trailing "footer" and data as part of encapsulation
  - tiny echo requests wrapped in encapsulation headers
    and trailing padding - used as probes to elicit tiny
    echo replies
  - tunnel endpoint discovers tunnel far end EMTU_R and
    reassemby timeout values in initial probes 
  - periodic probing to discover the tunnel path MTU,
    plus EMTU_R; reassembly timeout fluctuations
  - inner fragmentation to create inner packets no larger
    than EMTU_R
  - outer fragmentation to create outer packets no larger
    than the tunnel path MTU
  - coservative use of fragmentation to avoid packet loss
    within the tunnel
  - TE drops unfragmentable packets larger than EMTU_R
    and sends ICMP PTB w/o wasting tunnel resources
  - protection against fragment misassociations
  - protection against off-path attacks
  - protection against wrapped ip_id
  - backwards compatibility
  - incremental deployment
  - NAT traversal

The proposal updates existing tunneling mechanisms
(including IPv6/*/IPv4) and also offers a solution for
the RAM/RRG tunnel MTU problem space. Should this be
discussed here, or take it over to the ram/rrg lists?

Thanks - Fred
[email-masked]

> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]] 
> Sent: Thursday, September 13, 2007 12:54 PM
> To: IPv6
> Subject: [Fwd: Re: [RRG] Re: [RAM] Tunneling overheads and 
> fragmentation]
> 

Subject: I-D ACTION:draft-templin-inetmtu-00.txt
From: <[email-masked]>
To: <[email-masked]>
Date: Tue, 18 Sep 2007 12:15:01 -0700

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

	Title		: Packetization Layer Path MTU Discovery for 
                          IP/*/IPv4 Tunnels
	Author(s)	: F. Templin
	Filename	: draft-templin-inetmtu-00.txt
	Pages		: 20
	Date		: 2007-9-18
	
   The nominal Maximum Transmission Unit (MTU) MTU of the Internet has
   become 1500 bytes, but existing IP/*/IPv4 tunneling mechanisms impose
   an encapsulation overhead that can reduce the effective path MTU to
   smaller values.  Additionally, existing IP/*/IPv4 tunneling
   mechanisms are limited in their ability to discover and utilize
   larger MTUs.  This document specifies new mechanisms for conveying
   packets over IP/*/IPv4 tunnels that address these issues.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-templin-inetmtu-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-templin-inetmtu-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-templin-inetmtu-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Wed, 19 Sep 2007 17:31:02 +0300

Le Tuesday 18 September 2007 23:43:30 Templin, Fred L, vous avez écrit :
> last-hop router.

From a purely cosmetic standpoint, I think MRU (Max Receive Unit) is a lot 
more readable that EMTU_R.

From a technical perspective, this strikes me as:
- It requires knowledge of informations that is often hidden/not provided to 
the tunneling implementation, including path MTU and IP ID. That makes it 
possibly unimplementable without strong integration/dependency between the 
tunneling and the outer IPv4 stacks.

- It requires maintaining quite a bit of extra state per neighbor. I have 
received complaints that Teredo relays are having scalability issues already 
now due to the growing numbers of clients, and adding more per-client state 
would make matters worse.

-- 
Rémi Denis-Courmont
http://www.remlab.net/

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 19 Sep 2007 08:00:50 -0700

Hi Remi, 

> From: Rémi Denis-Courmont [mailto:[email-masked]] 
> Sent: Wednesday, September 19, 2007 7:31 AM
> To: [email-masked]
> Cc: Templin, Fred L; Brian E Carpenter
> Subject: Re: [Fwd: Re: [RRG] Re: [RAM] Tunneling overheads 
> and fragmentation]
> 

I agree about the cosmetics, however "EMTU_R" is precisely
defined in RFC1122 and is used in this document exactly
per its RFC1122 specification. I couldn't find a similar
reference for "MRU".

> the tunneling implementation, including path MTU

The tunnel endpoint (TE) doesn't need to look into the
IPv4 path MTU discovery cache, if that's what you mean.
The TE determines the tunnel MTU through its own probing
and does not rely on ICMPv4 "fragmentation needed"
messages.
 
> and IP ID. That makes it 

Well, the document is asking for the TE to take charge
of the ip_id it assigns in the outer IPv4 header. For
tunnels that have a NAT on the path to the TFE, that
requirement may be relaxed somewhat since the NAT can
just rewrite the ip_id anyway. 

> would make matters worse.

Well, its really just a few extra entries in a conceptual
neighbor cache. And, it is soft-state that can be managed
the same as for the RFC2461 neighbor cache. (In fact, the
state can just be added as an extension to the RFC2461 NC
for IPv6/*/IPv4 tunnels.) I will take a closer look at
Teredo relay, however.

Thanks for the comments,

Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 19 Sep 2007 08:28:31 -0700

> per its RFC1122 specification. I couldn't find a similar

Hmm, I may have spoken too soon; RFC4213 uses the term
MRU, but does not define it precisely. Perhaps this
document should define MRU in terms of how it relates
to RFC1122 EMTU_R, then use the term MRU thereafter?

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 19 Sep 2007 08:28:31 -0700

Thanks - Fred