[nvo3] Adam Roach's No Objection on draft-ietf-nvo3-geneve-14: (with COMMENT)

[Adam Roach via Datatracker <[e-mail]>]

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