RE: Tunnel MTU

["Templin, Fred L" <Fred.L.Templin@boeing.com>]

Janos,

> -----Original Message-----
> From: Mohacsi Janos [mailto:mohacsi@niif.hu]
> Sent: Wednesday, July 29, 2009 12:42 AM
> To: Iljitsch van Beijnum
> Cc: Mark Townsley; Templin, Fred L; IPv6 Operations
> Subject: Re: Tunnel MTU
> 
> 
> 
> 
> On Tue, 28 Jul 2009, Iljitsch van Beijnum wrote:
> 
> > On 28 jul 2009, at 19:44, Mark Townsley wrote:
> >
> >> I'd like to clarify of course that some of the MTU issues we
discussed were
> >> not specific to tunneling, but to mismatched MTUs on a home LAN vs.
WAN
> >> interface in general.
> >
> > In IPv6 you can easily broadcast your WAN MTU in RAs on the LAN. So
if your
> > WAN has 1337 you simply have an MTU option with "1337" in RAs that
are sent
> > out on the LAN side.
> >
> >> The extra 20 bytes of a 6rd or 6to4
> >
> > With 6to4 most implementations simply use 1280.
> >
> >> encapsulation isn't significant when trying to solve support of 9K
jumbo
> >> frames and standard 1500 byte ethernet MTUs in the same network.
> >
> > I have an expired draft that solves exactly that issue:
> >
> > http://tools.ietf.org/html/draft-van-beijnum-multi-mtu-02
> >
> > I intend to bring it back to life in a much improved incarnation at
some
> > point, didn't get that done before this meeting.
> 
> I somehow lost the in the discusion:
> 
> According the path-MTU discovery process should work this way: the CPE
> (and subsequent routers) should notifiy the sender (with ICMPv6 packet
too
> big message) to reduce MTU if the sender wants to send something over
the
> WAN links (including tunnels).
> 
> So actual path-MTU may differ by destinations.
> 
> Actually the problem can be find out the sensible MTU for tunnels? Are
we
> discussing the this value?
> 
> Or we are discussing something better than PMTUD?

In the case of SEAL, I am talking about something better
than PMTUD.

Fred
fred.l.templin@boeing.com

> 
> Best Regards,
>  		Janos