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

[Cameron Byrne <[e-mail]>]

Ted,

On Fri, Dec 7, 2012 at 10:57 AM, Ted Hardie <[e-mail]> wrote:
> 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?
>

Yes, that is my 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.
>

Will do.

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

Yes, stating it as:  Many large and fast growing edge networks exceed
the size of the available private IPv4 address space, and thus must
choose between a variety technical comprises within IPv4 or an
immediate transition to IPv6 with an enabling technology such as
464XLAT.

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

Anything tunnels or DHCP based (including DS-lite and MAP) will not
work in 3GPP, that barriers are too high.  464XLAT navigates the
barriers and is running code with interests from many operators.  But
from a 10,000 foot view, 464XLAT is not a glorious, obvious, or
elegant creation, it is just the tool to get the job done.  It helps
us move IPv6 forward.

That said, the authors of 464XLAT accept whatever the IESG approves.


CB

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