Adam Roach has entered the following ballot position for draft-ietf-nvo3-geneve-14: No Objection
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-nvo3-geneve/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for the work that went into consolidating network tunneling protocols into a single, unified design. I have one comment that I think is rather important to Geneve's success. In fact, I'm on the wall about whether this comment should be a DISCUSS, since I think the current design will render Geneve broadly unusable in a number of important use-cases. > Dest port: IANA has assigned port 6081 as the fixed well-known > destination port for Geneve. Although the well-known value should > be used by default, it is RECOMMENDED that implementations make > this configurable. The chosen port is used for identification of > Geneve packets and MUST NOT be reversed for different ends of a > connection as is done with TCP. This behavior -- using 6081 as the destination in both directions -- has the unfortunate property of violating NAT and Firewall assumptions about the nature of UDP traffic (see RFC 4748 for a discussion of UDP behavior in NATs). For example, while RTP was originally specified to typically work in the way described here (using two unrelated unidirectional flows when a bidirectional flow was desired), all (or nearly all) modern implementations use a technique known as "symmetric RTP" (see RFC 4961), which uses port numbers in the same way as TCP does. I can't find any discussion of NAT traversal in this document. One might assume that such responsibility is delegated to the control plane, but it should be noted that this specific requirement is going to frustrate every NAT traversal technique that I'm aware of (save for the mostly undeployed NAT-PMP and similar approaches), regardless of how well-designed the control plane is. If the working group has already considered NAT/Firewall traversal and decided to use the specified design anyway [1], please add text laying out the rationale in this document. If this point has not yet been discussed, I urge the working group to withdraw its request for publication and to carefully reconsider the implications of this specific normative requirement. (I take the point about the design being applicable to "controlled networks," but that doesn't necessarily imply the absence of a NAT or a non-NAT Firewall; and, as Roman notes in his DISCUSS, the applicability statement appears to be overstated anyway: if crossing public networks -- as this document clearly anticipates -- using IPv4, the presence of a CG-NAT device will become increasingly likely as time goes on.) ____ [1] I searched mailarchive.ietf.org and found no such discussion, but did not search meeting minutes _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
