Re: [v4tov6transition] [Softwires] 6a44 MTU issues

[Rémi Després <[e-mail]>]

Le 13 oct. 2010 à 17:17, Templin, Fred L a écrit :

> Hi Remi, 
> 
>> -----Original Message-----
>> From: [e-mail] 
>> [mailto:[e-mail]] On Behalf Of Rémi Després
>> Sent: Tuesday, October 12, 2010 12:26 AM
>> To: Templin, Fred L; Washam Fan
>> Cc: Softwires; [e-mail]
>> Subject: Re: [Softwires] [v4tov6transition] 6a44 MTU issues
>> 
>> Fred and Washam,
>> 
>> I reacted too fast to previous remarks when I proposed to 
>> modify the accepted IPv6 MTU in 6a44 draft.
>> If IPv6 packets longer than 1280 would be accepted by 6a44 
>> servers, hosts could receive them in fragmented IPv4 datagrams.
> 
> Or they might be reassembled in the NAT(s) in front of
> the host.
They would indeed.
But they would then be forwarded across the customer network.
There, they may somewhere be fragmented to fit into fragments shorter than the ISP MTU + 28.
This happens for example if the ISP IPv6 MTU would be 1500-28 and that of some link in the customer site would be 1500-40 (say, for an IPv4 in IPv6 tunnel). 
Right?

> 
>> This would be contrary to the objective of simplicity 
>> (datagram reassembly would have to be include in 6a44 
>> clients) and to the objective of security (a new door would 
>> be open to dos attacks).
>> No change on this point will therefore appear in the next 
>> version of the draft. 
>> Some additional explanations may be appropriate, but 
>> preferably after a consensus on what has to be said.
>> 
>> Then the MTU issue of IPv6 in IPv6 tunnels that Fred 
>> underlines remains as is.
> 
> Right.
> 
>> If the PMTU of such a tunnel is unknown, or known to be less 
>> than 1280+40,
> 
> Actually, 1280+40+IPsec headers and trailers in the case
> of VPN.

I was only discussing the direct IPv6 in IPv6 case.
But, yes, it is in general 1280 + the encapsulation header, whatever its size.

>> tunnel endpoints have to tunnel 1280-octets 
>> external packets in two pieces, using a fragmented IPv6 
>> datagram for this.
> 
> OK, so steady-state IPv6 fragmentation and reassembly between
> VPN tunnel endpoints is expected as normal operation in this
> model.

Yes.
(A consequence of privileging connectivity and stateless operation).

>> Reassembly at the other end is then necessary. 
>> It can be facilitated if the tunnel is treated as only one 
>> flow,
> 
> Can you say more about what you mean by this?

I mean that, because packets are almost always kept in sequence for a flow (otherwise TCP efficiency would be in general very poor) reassembly can be limited to consecutive fragments of only one datagram (the one being currently reassembled).
A packet permutation that interleaves fragments of two different datagrams leads in this case to a loss (but with low enough a frequency for it to be acceptable). 
This is significantly simpler than in the case where fragments of many datagrams my be interleaved.
 
> 
>> with packets in general kept in sequential order.
> 
> In-order delivery is not a strict requirement for
> correct IPv6 reassembly - but the fact that steady-state
> IPv6 frag/reass is required seems onerous.

See just above.

Regards,
RD