> On Sep 8, 2017, at 6:55 PM, Linda <[email protected]> wrote: > > Dan , > > The shorter description didn't really describe the problem associated with > VxLAN encapsulated traffic traversing NAT.
The problem occurs if an IT administrator assumes reverse traffic is going to use the inverted 5-tuple of the outbound traffic. I don't see value in complicating what the IT administrator needs to configure to allow that incoming traffic. -d > > 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 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
