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

Hi Remi, 

> -----Original Message-----
> From: softwires-bounces@ietf.org 
> [mailto:softwires-bounces@ietf.org] On Behalf Of Rémi Després
> Sent: Tuesday, October 12, 2010 12:26 AM
> To: Templin, Fred L; Washam Fan
> Cc: Softwires; v4tov6transition@ietf.org
> 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.

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

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

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

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

Fred
fred.l.templin@boeing.com

> Regards,
> RD
>   
> 
> >>>> 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.
> 
> 1. Could you be more specific?
> Do yout see a significant difference with what happens with 6to4,
> 
> 
> >> 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,
> 
> 2. Then the IPv6 service is somewhat damaged concerning fault 
> diagnosing, like the underlying IPv4 service.
> But at least packets that should be delivered are delivered.
> 
> 
> > and might not have
> > enough information for stateless translation to ICMPv6.
> 
> 3. Same as 1. above.
> 
> 
> >>> 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.
> > 
> > I should also say, any ICMPv4 returned from within
> > the end user network (where MTUs might not be so well
> > managed) might not be delivered to the tunnel endpoint
> > in the ISP network.
> 
> 4. Same as 2. above.
> (Since IPv4 fragments rather than returning packet-too-big 
> ICMP messages, this cannot concern MTUs).
> 
> Yet, there remains another problem with the replacement of 
> 1280 by "IPv4 MTU - 28" (I proposed it too quickly) because 
> it creates risks of fragmentation ...
>   
> 
> 
> 
> 
> 
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires
> 