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

[Washam Fan <[e-mail]>]

Hi Fred,

I might see your points.

Let H represents Host, N represents NAT, S represents the 6a44
servers. PMTU(H,S) stands for the PMTU between H and S. HOME_MTU
represents MTU within home LAN (i.e., unmanaged network), SP_MTU
represents MTU within SP network(i.e., managed network). We assume
both SP_MTU and SP_MTU should exceed or equal to 1308.

if HOME_MTU>=SP_MTU, PMTU(H,S)=SP_MTU, the H could configure SP_MTU-28
as the IPv6 virtual interface MTU.
H->S direction: if S received or trigger any ICMPv6 PTB messages, it
can forward ICMPv6-in-UDP-in-IPv4 to H.
S->H direction: S would reject any IPv6 packets exceeding SP_MTU-28
with ICMPv6 PTB.
I don't see problems here.

If HOME_MTU<SP_MTU,PMTU(H,S)=HOME_MTU, the H could configure
HOME_MTU-28 as IPv6 virtual interface MTU.
H->S direction: if S received or trigger any ICMPv6 PTB messages, it
can forward ICMPv6-in-UDP-in-IPv4 to H. I don't expect the size of the
encapsulated packet is too much.
S->H direction: if S forward some IPv6 packets whose size is between
HOME_MTU-28 and SP_MTU-28, N might trigger a ICMPv4 PTB or filtering
them. For the former, S might don't have enough info to infer which
IPv6 original packet it is related, for the latter, black hole might
occur. I see problems here.

Thanks,
washam

2010/10/12 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
>> >
>>