Dan,
Thanks for pointing out the Geneve's processing for traversing VxLAN.
First of all I wasn't proposing using reduced set of source ports. I think that
the general document needs to add the consideration for traversing NAT because
it is an issue for IPv4. Joe Touch suggested adding the entropy in the IPv6
flow ID as a solution for IPv6.
As for your suggested approach in Geneve:
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.
Does it mean all reverse traffic only use UDP port 6081?
Or all the NAT device convert the NVE’s UDP port 6081 to multiple port numbers?
Thanks,
Linda
-----Original Message-----
From: Dan Wing [mailto:[email protected]]
Sent: Wednesday, July 12, 2017 6:09 PM
To: Linda Dunbar <[email protected]>
Cc: NVO3 <[email protected]>; [email protected]
Subject: Re: [nvo3] draft-ietf-nvo3-encap-00 should add considerations of
traversing NAPT
> On Jul 12, 2017, at 12:37 PM, Linda Dunbar
> <[email protected]<mailto:[email protected]>> 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://tools.ietf.org/html/draft-ietf-nvo3-geneve:
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://tools.ietf.org/html/rfc5389#page-6.
> 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: +1 469-277 - 5840
>
> Fax: +1 469 -277 - 5900
>
>
>
> _______________________________________________
> nvo3 mailing list
> [email protected]<mailto:[email protected]>
> 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
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
