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

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

Hi Remi, 

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Rémi Després
> Sent: Wednesday, October 13, 2010 8:43 AM
> To: Templin, Fred L
> Cc: Softwires; [e-mail]
> Subject: Re: [Softwires] [v4tov6transition] 6a44 MTU issues
> 
> 
> 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?

The fact of life is that we have the ISP managed network
domain and the end user network unmanaged network domain,
whether the ISP controls the CPE or not. The managed domain
should be well-behaved, but any manner of MTU irregularities
is possible within the unmanaged domain. For example, I can
login to my Linksys home router and manually set the MTU to
any value I want.

Anything that can be configured can be mis-configured, and
the ISP has no control of any misconfigurations that might
occur in the end user network. As far as the ISP can tell,
the end user network is just a black hole that silently
consumes packets. 
 
> >> 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.

Right, and whatever size the encapsulation header it makes
the underlying 1280 MTU insufficient for efficient operation.

> >> 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).

That could become onerous. Let's say that an IPv6 tunnel
is configured over an IPv6-in-IPv4 tunnel with MTU=1280.
Then, the IPv6 packets would be fragmented into packet
pairs with the first being 1280 and the second being
80 bytes. That means that there would be a long/short
packet pair sent whereas a single long packet could be
sent if the IPv6-in-IPv4 tunnel had a slightly larger MTU.

One of the benefits of keeping a small amount of state is
that black hole detection is made possible such that a
larger tunnel MTU can be configured. This would lead to
more efficient handling of packets that are just slightly
larger than 1280.

> >> 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.

Well, reordering and duplication are always possible within
the network. But, I'm not sure here whether you are referring
to IPv6 reassembly in the end system or IPv4 reassembly in
the network. The former should work, while the latter has
known issues at high data rates (RFC4459). Both are inefficeint.

Thanks - Fred
[e-mail]

> >> 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
> 
> 
> 
> 
> _______________________________________________
> Softwires mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/softwires
>