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

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

Hi Washam, 

> -----Original Message-----
> From: Washam Fan [mailto:[e-mail]] 
> Sent: Monday, October 11, 2010 7:38 PM
> To: Templin, Fred L
> Cc: Rémi Després; Softwires; [e-mail]
> Subject: Re: [v4tov6transition] IPv6 VPNs configured over 
> 1280 MTU tunnels
> 
> Hi,
> 
> If 6a44 deployed in a managed ISP network, the 6a44 client could be
> configured with IPv4_MTU-28 for its IPv6 MTU.

My understanding is that the 6a44 server is in the managed
ISP network, and the 6a44 client is in the UNmanaged end
user network.

> For inbound direction,
> 6a44 server would reject any IPv6 packets whose size exceeds
> IPv4_MTU-28 with a ICMPv6 PTB message, so no ICMPv6-ICMPv4 translation
> needed.

Huh? How does the server have any idea what MTU the client
set on its tunnel interface? The client is behind a NAT in
an unmanaged end user network. Are you expecting the server
to probe the path MTU to the client and maintain state? (An
IRON server might be in position to do something like that,
but I was assuming the 6a44 server would be stateless, right?) 

> For outbound direction, 6a44 server would encapsulate any
> ICMPv6 PTB messages it received in UDP in IPv4, and then forward to
> the 6a44 client, so no NAT filtering worried.

Correct, but no one has suggested an MTU problem for what
happens to IPv6 packets *beyond* the tunnel; we are only
discussing the case of MTU issues *within* the tunnel.

Fred
[e-mail]

> Thanks,
> washam
> 
> 2010/10/12 Templin, Fred L <[e-mail]>:
> > Remi,
> >
> >> -----Original Message-----
> >> From: Rémi Després [mailto:[e-mail]]
> >> Sent: Monday, October 11, 2010 10:05 AM
> >> To: Templin, Fred L
> >> Cc: Washam Fan; Softwires; [e-mail]
> >> Subject: Re: [v4tov6transition] IPv6 VPNs configured over
> >> 1280 MTU tunnels
> >>
> >>
> >> Le 11 oct. 2010 à 18:42, Templin, Fred L a écrit :
> >>
> >> >> ...
> >> >> Actually, the 6a44 specification should, instead of 1280,
> >> >> require IPv4 MTU - 28 octets, both for hairpinning and
> >> >> traversal cases.
> >> >
> >> > How can you be sure that IPv4 PMTUD will work in
> >> > the traversal case?
> >>
> >> 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.
> >
> >> In the from host direction, one can't be sure, but doesnt' need to.
> >> If a smaller PMTU is encountered further downstream, a PTB
> >> ICMPv6 error message will be returned from there.
> >
> > In the from-host direction, any ICMPv4 returned from
> > the ISP network might not be delivered to the tunnel
> > endpoint due to NAT filtering, and might not have
> > enough information for stateless translation to ICMPv6.
> >
> > Fred
> > [e-mail]
> >
> >> RD
> >
>