I've reviewed this document as part of the transport area directorate's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors for their information and to allow them to address any issues
raised. The authors should consider this review together with any other
last-call comments they receive. Please always CC [email protected] if you
reply to or forward this review.
This draft is basically ready for publication, but has nits that should be
fixed before publication:
In draft-ietf-softwire-dual-stack-lite-08, it says:
8.3. Application Level Gateways (ALG)
AFTR performs NAT-44 and inherits the limitations of NAT. Some
protocols require ALGs in the NAT device to traverse through the NAT.
For example: SIP and ICMP require ALGs to work properly.
Three comments on that "For example:"
1. I do not believe SIP requires an ALG.
Here are three citations that SIP ALG is unnecessary:
* ICE (RFC5245), which has the SIP endpoint do its own NAT traversal. With
this, a SIP ALG is unnecessary.
* Session Border Controllers routinely implement 'media latching'
(described
in draft-ietf-mmusic-media-path-middleboxes), which works with endpoints
that
don't implement ICE. With this, a SIP ALG is unnecessary.
* draft-ietf-sipping-nat-scenarios describes how all of this stuff works in
great detail, and its Section 3 says SIP ALG is not required.
I worry that the IETF is requiring / suggesting / recommending that vendors
implement ALGs in NATs. If the IETF were to make such a recommendation, it
needs to come from BEHAVE which is where the NAT work occurs, not SOFTWIRE.
Unless there is a citation that SIP ALG is necessary, please strike it.
2. "ALG" is an abbreviation for Application Layer Gateway, but ICMP is not
an application; it is a layer 4 protocol. If anything, it is traditionally
considered a "layer 3.5", because it is not normally used for transport but
rather to signal the IP layer. The term "ALG" is not appropriate when
discussing ICMP. RFC5508, which describes the behavior of ICMP for NAT,
does not use the term ALG (or Application) when describing ICMP. I suggest
simply striking "ICMP" from the example of protocols needing an ALG.
This also requires updating the text:
This specification only requires that the AFTR MUST
support [RFC5508].
by moving it out of the ALG section and to section 8.2 ("NAT Conformance")
where there are already citations for RFC4787 (UDP operation) and RFC5382
(TCP operation).
I suggest striking the mention of RFC5508 from the ALG section and adding it
to Section 8.2 ("NAT Conformance"), like this:
OLD:
A dual-stack lite AFTR MUST implement behavior conforming to the best
current practice, currently documented in [RFC4787] and [RFC5382].
NEW:
A dual-stack lite AFTR MUST implement behavior conforming to the best
current practice, currently documented in [RFC4787], [RFC5382], and
.................................................................^^^^^
[RFC5508].
...^^^^^^^^^
3. If the authors desire an example of a protocol that requires an ALG, a
good example is "active-mode FTP". (Which is seldom used anymore, because
it requires an ALG! It has been surpassed by passive-mode FTP.)
-d
