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

[Brian E Carpenter <[e-mail]>]

Fred,

> All of your assumptions are lowest-common-denominator.

What else can an operator safely do but make such assumptions?

Regards
   Brian

On 2010-10-15 02:08, Templin, Fred L wrote:
> Hi Washam, 
> 
>> -----Original Message-----
>> From: Washam Fan [mailto:[e-mail]] 
>> Sent: Thursday, October 14, 2010 5:50 AM
>> To: Templin, Fred L
>> Cc: Rémi Després; Softwires; [e-mail]
>> Subject: Re: [v4tov6transition] IPv6 VPNs configured over 
>> 1280 MTU tunnels
>>
>> 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.
> 
> All of your assumptions are lowest-common-denominator.
> All end user networks are made to suffer because of the
> few that are poorly configured. GigE is a current day
> reality, and MTUs much larger than the lowest common
> denominator should be made available to the end user
> networks that paid good money for them when possible.
> 
> Fred
> [e-mail]
> 
>> 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
> _______________________________________________
> v4tov6transition mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v4tov6transition
>