Re: [v4tov6transition] [Softwires] IPv6 VPNs configured over1280MTU tunnels

["Templin, Fred L" <[e-mail]>]

Hi Brian, 

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Brian E Carpenter
> Sent: Monday, October 11, 2010 2:26 PM
> To: Templin, Fred L
> Cc: Softwires; [e-mail]
> Subject: Re: [Softwires] [v4tov6transition] IPv6 VPNs 
> configured over1280MTU tunnels
> 
> Fred
> 
> On 2010-10-12 07:23, Templin, Fred L wrote:
> >>> In the to-host direction, because the ISP network is all what 
> >>> is left to traverse before reaching the CPE.
> >> In what you call the to-host direction, any ICMPv4
> >> returned from the ISP network might not have enough
> >> information for stateless translation to ICMPv6.
> > 
> > I should also say, any ICMPv4 returned from within
> > the end user network (where MTUs might not be so well
> > managed) might not be delivered to the tunnel endpoint
> > in the ISP network.
> 
> Well, yes, and there were several years when I frequently found myself
> in hotel rooms having to manually set the IPv4 MTU on my laptop to a
> low value, when connecting through broken dial-up ISPs. No doubt
> we'll also go through some years before all operators are providing
> an adequately large MTU to cope with IPv6-in-foo tunnels. I don't
> think any transition solution can hope to be 100% watertight
> on this.

IROM (vis-a-vis SEAL) is striving for a true tunnel MTU
solution and I think has made significant strides. The
SEAL approach is dissimilar from IPv4 PMTUD in that it
is the tunnel far end (and not a router on the path) that
returns the PTB message. SEAL relies on routers in the path
correctly implementing IPv4 fragmentation, which is a
required behavior even for tunnel paths that traverse
untrusted/unmanaged domains.

SEAL's only requirement is that the IPv4 first fragment of a
fragmented IPv4 datagram contain at least enough information
to include a tunnel identifier. The minimum size for a first
fragment is 8 bytes beyond the IP header, since the fragment
offset field counts the number of 8 byte blocks. Common
operational practices also suggest that routers tend to make
the first fragment be approximately MTU-sized since this may
be useful to allow the destination to measure the path MTU.
There is also enough uncertainty about tiny fragment attacks
(RFC1858, RFC3128, etc.) that it seems highly unlikely that
the first fragment of a multi-fragment IPv4 datagram would
contain less than 16 bytes (UDP header plus enough extra to
contain a tunnel ID). 

> We'll make the changes that Rémi mentioned, but
> you're correct that IPv6-in6a44 tunnels might have MTU issues.

Please have a look at my tunnel MTU guy when deciding how
to set the static MTU configuration knob:

http://www.ietf.org/mail-archive/web/softwires/current/msg01659.html

The term "configuration knob" came from RFC4213, which
also has an analysis of setting a static MTU that may
be helpful. But, remember that VPNs configured over
paths containing IPv6-in-IPv4 tunnels will need more
headroom, so 1280 seems insufficient.

Thanks - Fred
[e-mail]

>     Brian
> 
> _______________________________________________
> Softwires mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/softwires
>