Re: [v4tov6transition] IPv6 VPNs configured over 1280 MTU tunnels

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

 

> -----Original Message-----
> From: Washam Fan [mailto:[e-mail]] 
> Sent: Friday, October 08, 2010 8:02 PM
> To: Templin, Fred L
> Cc: Softwires; [e-mail]
> Subject: Re: [v4tov6transition] IPv6 VPNs configured over 
> 1280 MTU tunnels
> 
> Hi,
> 
> 2010/10/9 Templin, Fred L <[e-mail]>:
> > End systems in end user networks that connect to the
> > IPv6 Internet will likely want to configure IPv6 VPNs,
> > e.g., so that they can securely connect to their home
> > office networks. Those VPN links must present a 1280
> > minimum MTU to upper layers, but if they traverse a
> > link in the path with a too-small MTU then the end
> > system will see an MTU underrun and will need to use
> > IPv6 fragmentation.
> >
> > An IPv6-in-IPv4 tunnel with a fixed static 1280 MTU is
> 
> I assume you were refering 6a44.

No; I'm referring to any IPv6-in-IPv4 tunnel that sets
a static 1280 MTU. There are more than one of these.

> The reason why 6a44 restricts 1280
> MTU is IPv6 PMTU performance is not reliable practically, per Remi's
> reponse to me. If PMTU could (and I think it should) perform well,
> 6a44 would permit more larger MTU.

Its not about IPv6 PMTUD; its about IPv4 PMTUD. If a
tunnel router in an end user site sends an
IPv6-in-UDP-in-IPv4 packet out though its NAT and into
the ISP network, and if the ISP network needs to drop
the packet and send back an ICMPv4 PTB, then the NAT
could drop the PTB or the PTB might not contain enough
information for stateless translation into an ICMPv6
PTB. That's one profile for an MTU-related black hole. 

> For this bullet in sec5, draft-despres-softwire-6a44-00
> 
>    o  6a44 Server functions refuse packets received from their IPv6
>       pseudo interfaces if their sizes exceed 1280 octets, with ICMPv6
>       Packet Too Big messages returned to sources as required by
>       [RFC2460].)
> 
> I think it could only apply to the case where the received IPv6
> packets forwarded to the external domain. In the case the 6a44 server
> does the hairpinning, the 6a44 server would refuse packets whose size
> exceed (IPv4 MTU - 28) octets, with ptb ICMPv6 msg.

The point is that if the tunnel router sets a static
1280 MTU on its tunnel virtual interface then VPN
tunnel endpoints behind the tunnel router will see
an MTU underflow. That is double-tunneling, but it
is a fact of life in common operational practice.

Fred
[e-mail] 

> Thanks,
> washam
> 
> > an example of a link in the path that could cause such
> > an MTU underrun for end system VPN links. So, should we
> > be concerned that tunnels with a fixed 1280 MTU would
> > make life difficult for the common operational practice
> > of end systems using VPNs?
> >
> > Thanks - Fred
> > [e-mail]
> >
> >> -----Original Message-----
> >> From: [e-mail]
> >> [mailto:[e-mail]] On Behalf Of
> >> Templin, Fred L
> >> Sent: Friday, October 08, 2010 7:52 AM
> >> To: Yiu L. Lee; Brian E Carpenter; Ole Troan
> >> Cc: Softwires; [e-mail]
> >> Subject: Re: [v4tov6transition] [Softwires] ISP support of
> >> NativeIPv6across NAT44 CPEs -Proposed 6a44 Specification
> >>
> >>
> >> > CPE. This double tunneling tech seems scary.
> >>
> >> More to this point about double-tunneling, how were
> >> folks thinking that IPv6 VPNs would be run over a
> >> 1280 MTU IPv6-in-IPv4 tunnel? That is double-tunneling,
> >> and seems like it would be a quite common case, but the
> >> MTU seems deficient. Should it use IPv6 fragmentation?
> >>
> >> Fred
> >> [e-mail]
> >> _______________________________________________
> >> v4tov6transition mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/v4tov6transition
> >>
> > _______________________________________________
> > v4tov6transition mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/v4tov6transition
> >
>