Re: [apps-discuss] Review of draft-ietf-v6ops-464xlat-08

[Ted Hardie <[e-mail]>]

On Sun, Dec 2, 2012 at 7:56 PM, Cameron Byrne <[e-mail]> wrote:
> Ted,
>
> i have revision to my previous statements
>

In-line.

> On Fri, Nov 30, 2012 at 7:26 PM, Byrne, Cameron
<snip>
>
> I believe you are right that ICE would work at the app level.
>
> Our statement about hub-and-spoke in the I-D was driven by wording set
> in http://tools.ietf.org/html/draft-mdt-softwire-map-translation-01#section-8.2
>
> In this way, the NAT64 is a hub for IPv4 communications and IPv4 nodes
> via the NAT64 can communicate with other IPv4 nodes.  That is the
> basic architecture, if you need IPv4 access, send it via the CLAT and
> PLAT where CLAT is the spoke and PLAT is the hub
>
> Our claim that p2p does not work is based on the topological case that
> if you are address 2001:DB8:9999::10.1.1.1 and i am address
> 2001:DB8:8888::10.1.1.1  our ipv4-only nodes behind the CLAT cannot
> send packets to each other without something like ICE to force them
> via the NAT64 or TURN.
>

There are two cases.  In the first case, the CLAT is node resident.  There, the
CLAT-internal RFC 1918 addresses used by different nodes are
functionally in different
RFC 1918 instances.  That's the same case we get now when different
networks use RFC 1918, just
much smaller.  In the case where two home networks both use RFC 1918,
in other words,
you get the same situation--they must go out to an ICE server to have
p2p communications even
if they are, say, behind the same cable head end.

In the second case, the CLAT is not node resident, but it is not
running an IPv4 routing domain
in the traditional sense; in other words, itt does not offer local
routing among the IPv4 nodes, just
translation to v6.  Here the situations is mildly different from the
two-home-networks-each-using-RFC1918,
but the result from the point of the application is the same--they
must use an ICE server to communicate.


> If our addresses were different on the LAN like
> 2001:DB8:9999::10.1.9.9 and   2001:DB8:8888::10.1.1.1 we could send
> IPv4 packets to each other without the need for the hub (PLAT) since
> each CLAT would do RFC 6145 translation and remove the first 96 bits
> on the  LAN side.  This is great if there is a high chance that the
> LAN side IPs are unique, but that is not the case and result would be
> ipv4 packets with src = 10.1.1.1 and dst 10.1.1.1
>
> The current wording in question is "The 464XLAT architecture only
> supports IPv4 in the
>    client server model, where the server has a global IPv4 address.
>    This means it is not fit for IPv4 peer-to-peer communication or
>    inbound IPv4 connections."
>
> The important term is "fit" vs "not fit".  Given that path would go
> via a hub and may require ICE in the apps and infrastructure, it would
> not really be direct p2p, and therefore the WG settle on this specific
> language to error on the side of caution to the reader that this is
> not a "fit" design if p2p is an important use-case in ipv4 supporting
> ipv4.  The current statement is a caution to the reader and that is
> the reason it appears in the introduction.
>
> Alternatively, we can strike this from the introduction all together
> and give a more in-depth discussion that reference ICE for the p2p
> case.  The WG decided it was best to just punt on p2p and say it does
> not work here in the introduction.
>

Speaking personally, I don't think this is the right choice, because it
makes it appear you are creating a new semantic for RFC 1918 addresses
(a limited case where the usual tools for providing peer to peer connectivity
for them do not work).  If you can't signal that new semantic, the app
has no way of knowing whether the RFC1918 address it has is "full service"
(for whatever that means in the modern NAT and double NAT world) or
"client/server only".  That's making a bad situation worse.

ICE is a complicated bear that no one loves much, but it is currently the
best toolkit we have.  A reference to it and a description of how this
works with
it seems like a better choice to me than creating a new, limited RFC
1918 addressing
semantic.

regards,

Ted Hardie