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

[Ted Hardie <[e-mail]>]

Hi Cameron,

My apologies for the delay in replying.  Some further discussion in-line.

On Mon, Dec 3, 2012 at 11:49 AM, Cameron Byrne <[e-mail]> wrote:

> Ted,
>
> On Mon, Dec 3, 2012 at 10:13 AM, Ted Hardie <[e-mail]> wrote:
> > 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.
> >
>
> This is case the where CLAT is just a function of an otherwise normal
> home gateway.  I believe normal IP routing and ethernet switching will
> occur for the LAN.  The CLAT function only occurs  WAN <-> LAN
>
>
If this is the case, then the peer-to-peer functionality is preserved within
the LAN as well.  So you get it in the LAN; you lose it in the WAN (and must
use ICE) and you get the standard behavior in the presence of NAT for
the Internet.  Is that your understanding?


> >
> >> 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.
> >
>
> I agree.  That is why we declared the topology to be hub and spoke in
> the draft.  We can add a reference to ICE providing an application
> level hub and spoke architecture above the network layer hub and spoke
> topology.
>
> does that make sense?
>
>
Yes,  I think adding the ICE reference and a more nuanced view of where
peer-to-peer will work is a better way forward.

In another message, you made the following comment on why you would
prefer not to include discussion of squat space:

"I'd rather not air my ephemeral dirty laundry in an long lived RFC  :)"

Understood, but the case you're dealing with--a network larger than the
IPv4 address space available in the private address range--is not exactly
dirty laundry, and the lack of new IPv4 allocations is well known.  Those
do help justify this work and might be included.

That said, I am afraid I still don't see this as a BCP, in part because
there is
more than one way to accomplish this.  DPI as a driver for this choice may
be
a 3GPP network-specific thumb on the scales, but I don't think this would
be preferred over encapsulation-based methods in all cases.

As for dirty laundry, I would personally welcome a presentation from you
or your colleagues at the upcoming IETF apps area meeting on what's
breaking here,
as we've been recommending other referral methods and IPv6-native
clients for quite some time.  If we can get people to see exactly how
much hoop jumping is going on in other parts of the stack to get Skype
to work on a perfectly valid v6 network, it would be good.

regards,

Ted


> CB
> > regards,
> >
> > Ted Hardie
>