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

[Washam Fan <[e-mail]>]

Hi Fred,

Please see inline. I did have some different assumptions. And those
assumptions might be wrong. It might be better at this stage we let
the tunneled IPv6 MTU be 1280 and tunneling IPv4 MTU not less than
1308.

2010/10/13 Templin, Fred L <[e-mail]>:
> Hi Washam,
>
>> -----Original Message-----
>> From: Washam Fan [mailto:[e-mail]]
>> Sent: Monday, October 11, 2010 10:48 PM
>> To: Templin, Fred L
>> Cc: Rémi Després; Softwires; [e-mail]
>> Subject: Re: [v4tov6transition] IPv6 VPNs configured over
>> 1280 MTU tunnels
>>
>> Hi Fred,
>>
>> I might see your points.
>
> Good.
>
>> 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.
>
> This is an incomplete characterization. PMTU is not
> necessarily symmetric, e.g., even just within the end
> user it could be different in the H->N direction than
> in the N->H direction. Also, there could be multiple N's
> in the path; each imparting their own MTU uncertainties.

I assume H->N->S PMTU can be probed, Ns in between should be capable
of translating ICMPv4 messages appropriately. As you said, S->N->H can
not be probed as Ss are stateless.

>> if HOME_MTU>=SP_MTU, PMTU(H,S)=SP_MTU, the H could configure SP_MTU-28
>> as the IPv6 virtual interface MTU.
>
> A couple of things here. First, you seem to be assuming a
> static S instead of a redundantly replicated S with anycast,
> where there may be many distinct paths with varing SP_MTUs to
> reach the multiple S's.

I assume all Ss shared the same MTUs since they are located in managed
networks. Or the MTU on their interfaces attaching SP networks can be
configured with the least IPv4 MTU value.

> Second, how does H discover SP_MTU;
> by engaging in an initial probing by sending large packets
> and getting a PTB message back?

I assume H can discover PMTU traversing Ns in between.

> Again, this won't give a
> deterministic SP_MTU value if  S is replicated across paths
> with varying PMTUs.

I assume all Ss configured with the same MTUs on their interfaces
attaching to SP networks.

>> H->S direction: if S received or trigger any ICMPv6 PTB messages, it
>> can forward ICMPv6-in-UDP-in-IPv4 to H.
>
> You keep saying this, and I keep saying that you are right
> but that this has never been a matter for concern. PMTUD
> *beyond* the tunnel is not in question; it is only PMTUD
> *within* the tunnel that bears further discussion.
>
>> S->H direction: S would reject any IPv6 packets exceeding SP_MTU-28
>> with ICMPv6 PTB.
>> I don't see problems here.
>
> Huh? Is S supposed to cache the SP_MTU to each and every
> potential host H? I assume the goal is for a completely
> stateless S - right?

I assume MTU is statically configured on Ss' interfaces attaching the
SP networks.

>> If HOME_MTU<SP_MTU,PMTU(H,S)=HOME_MTU, the H could configure
>> HOME_MTU-28 as IPv6 virtual interface MTU.
>
> So again, H could discover this only by sending probes?
> And again, any probing would be non-deterministic if S
> is an anycast (and not unicast) address.

See above.

Thanks,
washam

>> H->S direction: if S received or trigger any ICMPv6 PTB messages, it
>> can forward ICMPv6-in-UDP-in-IPv4 to H.
>
> Yes, we have confirmed this several times now; not
> a point in question.
>
>> I don't expect the size of the encapsulated packet is too much.
>
> Encapsulated PTB could be as big as 1280 + 20 + 8.
>
>> 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,
>
> Right.
>
>> for the latter, black hole might occur. I see problems here.
>
> Right.
>
> Fred
> [e-mail]
>
>> 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
>> >> >
>> >>
>>