Re: [v6ops] Happy eyeballs suggestions, was: Re: Apple and IPv6, a few clarifications

On Monday, June 22, 2015, james woodyatt <jhw@nestlabs.com> wrote:

> On Jun 22, 2015, at 14:47, Iljitsch van Beijnum <iljitsch@muada.com
> <javascript:;>> wrote:
> > On 22 Jun 2015, at 23:26, james woodyatt <jhw@nestlabs.com
> <javascript:;>> wrote:
> >
> >>> Hm, what kind of stuff would work through NAT64 that wouldn't work
> with real IPv6 connectivity?
> >
> >> An obvious example would be a UDP application that depends on a 1500
> octet path MTU to all the IPv6 destinations it cares about. The NAT64 will
> shave a 1500 octet packet down to 1480, which might make it everywhere you
> want to go over IPv4 without needing to handle ICMPv6 Packet Too Big
> Errors, leaving you to discover later that native IPv6 destinations require
> you to deal with paths that are 1492 octets and not 1500 octets.
> >
> > Sure. Except that the kernel will handle all your fragmentation needs
> invisibly to the application (well, save for a retransmission or two). And
> testing with native IPv6 won't catch this most of the time anyway, as 65%
> of all paths (in my very limited measurements, but still) are 1500-byte
> clean.
> >
> > Also, I certainly hope application writers aren't going to test their
> applications for compatibility with networks that filter ICMPv6 too bigs,
> that would be insanity.
>
> I think you might have overlooked where I wrote “UDP” above instead of
> “TCP” which on iOS and OS X doesn’t have any PMTUD support. The kernel will
> not do any fragmentation or retransmission of UDP packets. A lot of
> applications are coded never to process the error code at a socket if a Too
> Big error is received. They either ignore the error and fail because packet
> size are never reduced, or they fail inappropriately rather than reduce
> packet sizes. Developers who only use the NAT64 environment without testing
> on a native IPv6 network may never see the Too Big errors that would expose
> this problem, and they won’t see it until their application is deployed for
> reals.
>
>
> —james

For some subset of networks, devs can test the real production deal if
apple could surface the apn setting in dev builds. It is hard to see the
harm in this. Other OSs allow apn setting fiddling. Also, this allows an
escape hatch for the inevitable user who cannot deal with ipv6-only in
production... And opens the door for end user opt in trials of ipv6.

It's really not a hard problem to solve for many situations (like tmus)
but the some backwards place .... They may not have this luxury of proper
ipv6 in mobile :/

CB

> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org <javascript:;>
> https://www.ietf.org/mailman/listinfo/v6ops
>