Re: [nvo3] draft-ietf-nvo3-encap-00 should add considerations of traversing NAPT

[Joe Touch <[e-mail]>]

On 7/13/2017 1:23 PM, Dan Wing wrote:
>> On Jul 13, 2017, at 12:59 PM, Joe Touch <[e-mail]> wrote:
>>
>>
>>
>> On 7/13/2017 12:39 PM, Dan Wing wrote:
>>>> On Jul 13, 2017, at 6:52 AM, Joe Touch <[e-mail]> wrote:
>>>>
>>>> FWIW, why not just add the entropy in the IPv6 flow ID rather than
>>>> expecting it at the transport layer? Intermediate network devices should
>>>> be relying only on the flow ID for that entropy anyway.
>>> I don't know if IPv6 routers do ECMP using flow ID, and I don't know if physical NICs do RSS CPU load balancing based on IPv6 flow ID.
>> I don't either, but *if* they (either one) does, they really should.
>>
>> RFC 6438 discusses this issue and implies that flow ID isn't used
>> because it's mostly zero, but I wouldn't be surprised if that were to
>> change over time.
>>
>>>> (and yes, that doesn't solve the problem for IPv4, but perhaps that's a
>>>> good reason to encourage use of IPv6)
>>> Yeah, for v4 we're stuck with using source UDP port to provide the ECMP and receiver benefit.
>>>
>>>
>>> What of NAT64?
>> Sure, that'd help, except we'd have to expect that an IPv4 router would
>> know to jump into the IPv6 flow ID to do ECMP. That seems more of a
>> stretch than the above, IMO.
> Sorry, I wasn't clear.  I'm not worried of the NAT64 device itself, but rather the IPv4 network beyond the NAT64, should we use IPv6 flow-id as proposed.
>
> If there are different ways of expressing ECMP and RSS (receiver side scaling) for IPv6 versus IPv4, my worry is what a NAT64 is supposed to do with the IPv6 packet (containing a flow-id) it translates to IPv4.  If traffic from IPv6 is using Flow-ID to provide ECMP and RSS and it hits a NAT64, is the NAT64 now needing to do NAPT64 (port translation) in an attempt to provide some Flow-ID-like functionality to the source UDP port number?  
Well, you're translating for a more capable protocol to a less-capable
one. Losing information is part of that game.

There's no way to do NAT64 translation without losing some of the info
in the IPv6 header, period.

It MIGHT try to use the flow ID to guide source UDP port generation, but
that assumes there's a UDP header to play with in addition to the IPv4
header. That's not NAT64 anymore.

> If so, that's new for NAT64, and can't work with stateless translation (IVI and related techniques).  If not, the IPv4 network suffers (no ECMP) and receiver suffers (because no RSS) because the sender was on IPv6 and the sender used flow-id.  In the other direction, IPv4 to IPv6, it seems easy for the NAT64 (stateless or stateful) to copy the UDP source port number into the IPv6 flow-id field, or do a cute 20-bit hash of the IPv4 5-tuple, or whatever.  If we spec'd that, NAT64 in the IPv4->IPv6 direction would align with RFC6438 and provide more ergs to IPv6 flow-id. 
>
> However, I remain troubled by the IPv6->IPv4 direction with NAT64, should we use only Flow-ID on the IPv6 side.

I don't think we should try to lobotomize an elegant IPv6 solution "just
in case" it hits NAT64.

IMO, that's NAT64's problem to deal with (or not).

Joe