Re: TSVDIR review, draft-ietf-softwire-dual-stack-lite-08

["Lee, Yiu" <[e-mail]>]

Hi Dan,

We just released a new revision of the ds-lite draft. Did we address all
your comments?

Thanks,
Yiu



On 5/5/11 8:42 PM, "Dan Wing" <[e-mail]> wrote:

>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  [e-mail] 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
>
>