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

[Dan Wing <[e-mail]>]

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

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

-d

> Joe
> 
> 
> On 7/12/2017 4:08 PM, Dan Wing wrote:
>>> On Jul 12, 2017, at 12:37 PM, Linda Dunbar <[e-mail]> wrote:
>>> 
>>> Sami, et al,
>>> 
>>> 
>>> 
>>> The draft-ietf-nvo3-encap-00 is written very clear.
>>> 
>>> 
>>> 
>>> However, the Section 6 (Common Encapsulation Considerations) should add a sub-section on the consideration of traversing NAPT.  Encapsulated traffic could go to different data centers or WAN, which could go through Network Address Port Translation devices
>>> 
>>> 
>>> 
>>> Using VxLAN as an example: VxLAN specification [RFC 7348] uses a set of Port numbers to achieve better traffic distribution among multiple paths, which is fine within one data center, but causing trouble when traversing NAPT.
>> You're describing a problem with Geneve, which mimics VXLAN in that both of them suggest using a wide range of UDP ports to help underlay ECMP and to help receiver CPU load balancing, specifically this text of https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dnvo3-2Dgeneve-3A&d=DwIDaQ&c=uilaK90D4TOVoH58JNXRgQ&r=IMDU0f3LtPMQf5XkZ06fNg&m=uud2CHHWYVN8GxM5H4uIwsteqFFoakAhWdD8nCVDJKA&s=J0Hb0SpNIBjHmMAaoXKIM0W89HrWqzozPsq5n3qmD00&e= 
>> 
>>   Source port:  A source port selected by the originating tunnel
>>      endpoint.  This source port SHOULD be the same for all packets
>>      belonging to a single encapsulated flow to prevent reordering due
>>      to the use of different paths.  To encourage an even distribution
>>      of flows across multiple links, the source port SHOULD be
>>      calculated using a hash of the encapsulated packet headers using,
>>      for example, a traditional 5-tuple.  Since the port represents a
>>      flow identifier rather than a true UDP connection, the entire
>>      16-bit range MAY be used to maximize entropy.
>> 
>> If a reduced set of source ports is used instead, as you propose, the ECMP and CPU load balancing benefits are lost.  That seems problematic.
>> 
>>> NAPT use Port number to map back the source address. With a set of port numbers, NAPT can’t easily figure out the reverse direction traffic’s final IP addresses.
>> The reverse traffic doesn't use the inverted 5-tuple.  The reverse traffic is sent to the Geneve destination port (6081), and a firewall or NAT or NAPT mapping is necessary for UDP/6081 traffic -- on both datacenters, which both probably have their own underlay NAPTs.  Those firewalls (or NATs or NAPTs) need to have appropriate pinholes for UDP/6081.
>> 
>>> In addition, since the IP of packets change through NAPT device, it can mess up the learning of the peer NVE used in encapsulation.
>> The underlay did the NAPT, so I don't see a problem with the NVE overlay getting confused.  Could you explain in more detail?
>> 
>>> STUN can be used to get changed IP and port from NAPT device, but it requires NAPT device support STUN.
>> NAPT devices are not expected to implement STUN.  STUN is expected to be implemented in the hosts behind the NAT and on a server on the other side of the NAT (usually on a server on the Internet).  See Figure 1 on page 6 of https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc5389-23page-2D6&d=DwIDaQ&c=uilaK90D4TOVoH58JNXRgQ&r=IMDU0f3LtPMQf5XkZ06fNg&m=uud2CHHWYVN8GxM5H4uIwsteqFFoakAhWdD8nCVDJKA&s=TCHbljyS6SjK00_hvov-AWPmrDHVbyhVuV7ldIdWQoc&e= .
>> 
>>> That’s not available in some scenarios. Furthermore, it can’t solve the aforementioned five-tuple issue.
>>> 
>>> 
>>> 
>>> VXLAN over IPSec may be used to deal with the above problems,
>> Both Geneve and VXLAN run over UDP, and both use a fixed destination port (rather than inverted 5-tuple) for return traffic.  Not sure how VXLAN succeeds at dealing with the above problems, but I would love to learn.
>> 
>>> but IPSec brings up to 88 bytes of overhead plus the key distribution management, which can lower the efficiency.
>> Should be able to use IPsec transport mode, which is more around 40 bytes overhead.
>> 
>> -d
>> 
>> 
>>> 
>>> 
>>> 
>>> 
>>> Suggestion: Add Section 6.10 Traversing NAPT consideration.
>>> 
>>> I can help to provide the text if you all think the suggestion is acceptable.
>>> 
>>> 
>>> 
>>> We can discuss more in Prague.
>>> 
>>> 
>>> 
>>> Thanks, Linda Dunbar
>>> 
>>> 
>>> 
>>> Huawei USA IP Technology Lab
>>> 
>>> 5340 Legacy Drive,
>>> 
>>> Plano, TX 75024
>>> 
>>> Tel: [phone] - 5840
>>> 
>>> Fax: [phone] - 5900
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> nvo3 mailing list
>>> [e-mail]
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_nvo3&d=DwICAg&c=uilaK90D4TOVoH58JNXRgQ&r=IMDU0f3LtPMQf5XkZ06fNg&m=60T3yKN2I7oCxe8OH9mfZix-2ykSSjL-P-RoXCkZGdg&s=q7A_LzZuDp-yZnlA7Xw_N7yuLk4HO7K07jgl3Z78Ixg&e= 
>> _______________________________________________
>> nvo3 mailing list
>> [e-mail]
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_nvo3&d=DwIDaQ&c=uilaK90D4TOVoH58JNXRgQ&r=IMDU0f3LtPMQf5XkZ06fNg&m=uud2CHHWYVN8GxM5H4uIwsteqFFoakAhWdD8nCVDJKA&s=rLTq8CpFk2GwGniHCqktWbL0-O8O-nNXMIfE0k5iodw&e= 
>