Subject: [Softwires] MTU issues with tunneling

From: David Ward <[email-masked]>
Date: Mon, 27 Mar 2006 11:27:08 -0600

All -

    Fred Templin gave a presentation at the WG meeting in Dallas on MTU
issues and tunneling. The draft is here:

http://www.ietf.org/internet-drafts/draft-templin-mtuassurance-00.txt

We took a temperature of the room and some folks felt it was a real problem
and that we should take on the draft and resulting solution drafts as WG
items.

Please comment now if you feel this is a real problem and if the draft
should or should not become a WG document.

Many thanks

-Dward

_______________________________________________
Softwires mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/softwires

---

From: Francis Dupont <[email-masked]>
Date: Mon, 27 Mar 2006 22:51:16 +0200

In your previous mail you wrote:

=> this is a real problem. In fact the only concern I have it is
the narrow scope of Softwires when the problem is far more general.
But it is better to have it in the WG than nowhere of course.

Thanks

[email-masked]

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Mon, 27 Mar 2006 23:09:28 +0200

> But it is better to have it in the WG than nowhere of course.

Including such a mechanism within softwire-blessed tunneling solutions 
might be good as it might allow proper spec timing for eventual 
inclusion. To the countrary, I can hardly imagine wide usage of such an 
extension within already deployed tunneling protocols (ie. all the 
pseudo-tunnel stuff for IPv6-over-IPv4 including 6to4, TSP, Teredo and 
ISATAP), regardless of the “Tunnel Endpoint Negocation” backward 
compatibility, though not completely excluded.

-- 
Rémi Denis-Courmont
http://www.simphalempin.com/home/

---

From: "Laurent Toutain" <[email-masked]>
Date: Thu, 30 Mar 2006 16:57:51 +0200

This is a good problem. I don't know if we have to focus that much
on MTU probing. May be a simple rule such as 1500 - tunnel header size
is enough at the beginning.

As stated in the draft we have to select the behavior of the SC when
it receives a large packet.
- send a ICMPv6 too big to the source ? does this lead to scalability
  problem ?- do IPv4 fragmentation that may not cross the NAT as explained
- use IPv6 fragmentation, but I'm not sure a router can add
  extensions to packets.

There is the symetric case for the SI:
- The tunnel MTU can be annouced in the RA. This mean that all
communication will use  this value even between two equipments on the
same site.
- announce link MTU on the site and ICMPv6 Too Big reduce the size
when a packet leaves the site.

Laurent

--
-----------------------
Serveur web du Point6 => http://www.point6.net
Laurent Toutain
ENST Bretagne
tel +33 2 99 12 70 26 - Fax +33 2 99 12 70 30

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 30 Mar 2006 15:35:57 -0800

Laurent, 

> is enough at the beginning.

It is true that 1500bytes has more or less become the
de facto Internet cell size because of Ethernet. But simply
setting the tunnel MTU to 1500 bytes minus the size of the
encapsulation headers and then setting the DF bit in the IPv4
header to 0 allows any middlebox in the network to fragment
the packet in any manner it chooses, i.e., as long as the
behavior is consistent with RFC 791. Also, as links with
larger MTUs become widely deployed (e.g., GIG-E) it would
be desirable for the tunnel endpoints to discover and use
the larger MTUs.

Fred
[email-masked]

---

From: "Laurent Toutain" <[email-masked]>
Date: Fri, 31 Mar 2006 18:08:55 +0200

I don't know what we will get first : IPv6 or larger MTU :-). In my views
Softwire is a "temporary solution" and we have to cross equipments
like NATs than I think cannot handle packets larger than 1500 Bytes.
If there a simple solution to discover pMTU larger than 1500 why not
otherwise, in phase one, we should keep the 1500 limit.

Laurent

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 31 Mar 2006 09:35:52 -0800

Laurent,

Thanks for the follow-up note. The only assertion I would
question is whether we can be sure that softwire will be
a temporary solution. It could be that softwire tunneling
would work so well that the network will remain "stuck in
transition" for quite a long time.

I don't have a crystal ball that tells what the network
and applications will look like in the next 1, 5, 10 years,
but we have been waiting to see native IPv6 deployment take
off for quite a long time now. So, I agree with you that
its hard to tell whether we will see IPv6 or larger MTUs
come first.

Fred

> -----Original Message-----
> From: Laurent Toutain [mailto:[email-masked]] 
> Sent: Friday, March 31, 2006 8:09 AM
> To: Templin, Fred L
> Cc: Francis Dupont; David Ward; [email-masked]; Durand, Alain
> Subject: Re: [Softwires] MTU issues with tunneling
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 31 Mar 2006 16:14:44 -0800

FYI, this I-D documents some of the problems with IPv4 fragmentation:

http://www.ietf.org/internet-drafts/draft-heffner-frag-harmful-00.txt

Fred