Dan , The shorter description didn't really describe the problem associated with VxLAN encapsulated traffic traversing NAT.
Linda Sent from my iPhone > On Sep 8, 2017, at 7:34 PM, Dan Wing <[email protected]> wrote: > > >> On Sep 8, 2017, at 2:31 PM, Linda Dunbar <[email protected]> wrote: >> >> Sami, et al: >> >> Follow up the discussion during IETF 99, I took the stab putting together >> the wording to describe why it is an issue for VxLAN encapsulated data >> frames traversing NAT. I think this sub-section should be included in the >> Section 6 of the draft-ietf-nvo3-encap. >> >> Linda Dunbar >> >> ---------------------------------------------------------------------- >> >> 6.10 NAT Traversal consideration >> Here is an example of encapsulated traffic traversing NAT (Network Address >> Translation) or, to be precise, NAPT (Network Address and Port Translation): >> <ATT65120 1.jpg> >> Figure x – Scenario of Overlay Tunnel traversing NAT >> >> If the Overlay Tunnel uses VxLAN encapsulation [RFC7348], IANA assigned Port >> 4789 is used in the outer frames’ destination port field and hashed value of >> inner packet is used in the outer frames’ source port field [RFC 7348]. >> Using different source port numbers is for achieving better traffic >> distribution among multiple paths. This approach is fine within one data >> center, but can cause trouble when traversing NAT. >> Many NAT devices use Source Address and Port number of the data frames >> coming from private addresses to derive the source port number for the >> frames sent to the public network, as shown below (assuming VxLAN is used >> for encapsulation between the CPEs and the Gateway). The NAT Public Source >> Port H1/H2/H3/H4 can’t be the same, otherwise the NAT device can’t tell if >> the return data frames should be sent to CPE1 or CPE2. >> >> Private Source Address Private Source Port Private Destination Port >> NAT Public Source Addr NAT public Source Port NAT public >> Destination Port >> CPE1 A1 4789 Public A H1 4789 >> CPE1 A2 4789 Public A H2 4789 >> CPE2 A3 4789 Public A H3 4789 >> CPE2 A4 4789 Public A H4 4789 >> >> Per RFC 7348, the destination port number of the data frames returned from >> the Gateway should be 4789. When the NAT device receive the data frames >> (with the destination port = 4789) from the Public Network (i.e. from the >> Gateway in the figure above), the NAT device has to drop the data frames as >> the Destination Port 4789 is not one of H1/H2/H3/H4. >> Of course, we can always modify the NAT devices to accommodate the VxLAN >> encapsulated data frames. The problem is traversing the existing NAT devices >> already deployed. >> -------------------------------------- >> >> Sincerely hope the editors to draft-ietf-nvo3-encap can add those suggested >> text to the draft. > > > Ok. > > Does the text below say the same thing, only shorter? Or is there more > information being conveyed in your text. > > "Outbound traffic is encapsulated and sent to destination UDP port 4789. > The remote peer also encapsulates and sends its traffic to destination UDP > port 4789. Thus, to accept incoming Geneve traffic, on-path firewalls or > NATs MUST permit incoming UDP port 4789 traffic from their remote Geneve > peer." > > -d > > >> Linda Dunbar >> >> _____________________________________________ >> From: Linda Dunbar >> Sent: Thursday, July 13, 2017 2:31 PM >> To: 'Dan Wing' <[email protected]> >> Cc: NVO3 <[email protected]>; [email protected] >> Subject: RE: [nvo3] draft-ietf-nvo3-encap-00 should add considerations of >> traversing NAPT >> >> >> 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]> 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] >>> 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 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
