Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient

[James Woodyatt <[e-mail]>]

On Mon, Apr 27, 2015 at 4:22 AM, Ted Lemon <[e-mail]> wrote:

> On Apr 26, 2015, at 9:37 PM, Lorenzo Colitti <[e-mail]> wrote:
> > So, assuming it isn't... what sort of questions do you see around
> 464xlat that cannot be immediately answered by just saying that "464xlat is
> an unnumbered IPv4-only point-to-point link"?
>

I'll provide the beginning of an answer to Lorenzo's specific question
below, but I think the topic would be better handled at the IETF 93 meeting.

Also, I'm not trying to stall the conversation. I'm actually trying to
provoke what I think would be a reasonable way to keep the conversation
going in a productive direction: by improving the situation for application
programmers and host operating systems maintainers who will be forced to
live with 464XLAT for the foreseeable future if the recommendation in this
proposed BCP is widely adopted.

You're right, that makes it trivial.   Most applications are used to
> dealing with unnumbered IPv4-only point-to-point tunnels, so there's no
> explanation needed!   ;)
>
> Seriously, I have to say that if I saw that explanation, I would have no
> idea what it meant.   My understanding, having never actually _used_
> 464xlat knowingly, is that you open a socket and send on it and it just
> works, and that since most applications don't try to figure out what their
> source address is this isn't a problem.   But that's not what I would take
> your proposed text to mean.
>

Most applications don't even really want to know they are using TCP/IP,
much less which version of it. The whole point of 464XLAT is to cover the
special category of applications that do not make the usual assumptions and
use the corner cases of the IPv4-only application programming interfaces in
the host operating system. There are a lot of corner cases. So, here are
some example questions.

1. What about MIF? It's not sufficient to simply say put an IPv4 address on
the point-to-network pseudo-link for each provider. How does an application
that cares about which interface it's using know which IPv4 address belongs
to which interface? Does the getifaddrs() [not POSIX, but commonly
implemented] return results showing them all on the same interface? Or
different interfaces? How does an application sending a packet from a UDP
socket without a source address bound use IP_PKTINFO to specify which
source interface to use if ipi_spec_dst is zero? What about dual-stack
applications that care about which IP addresses are attached at which
interfaces over time? How do they know what IPv4 addresses are associated
with which interface if all the CLAT IPv4 addresses are attached to a
point-to-network pseudo-link instead of the interface where the CLAT IPv6
address is attached?

2. Consider the interaction an IPv6 listener and an IPv4 listener binding
to the same UDP port without using either SO_REUSEADDR option [or the
non-standard SO_REUSEPORT option], where the IPv6 socket is binding to the
same interface address that the CLAT will translate for the interface
address bound by the IPv4 socket? Does only the first socket() call succeed
while the second one fails? Or is there a different semantic? If so, what
is it?

3. Suppose instead the applications in the example above (2) do use
SO_REUSEADDR [and SO_REUSEPORT], and there are now two sockets bound to the
same IPv6 address and port, one of them translated by the CLAT and the
other not. Can these two applications communicate over interface loopback
through the CLAT?

Just saying that the CLAT is "an unnumbered IPv4-only point-to-point link"
tells us nothing about what application programmers can expect in these
sorts of weird corner cases, but the whole point of 464XLAT is to support
applications that don't use the protocol-independent interfaces.

I can understand why one might not want to document the answers to these
questions. Doing so might expose precisely how 464XLAT doesn't actually
deliver IPv4-only equivalence to applications on IPv6-only networks, but I
contend it's important to describe precisely what the CLAT does and doesn't
enable. Explaining what remains broken even after deploying a CLAT in every
host operating system will go a long way toward retaining a sensible
argument for application developers to migrate away from IPv4-only
programming interfaces.


-- 
james woodyatt <[e-mail]>
Nest Labs, Communications Engineering