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

From: "Dan Wing" <[email-masked]>
Date: Thu, 5 May 2011 17:42:57 -0700

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-masked] 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

---

From: "Lee, Yiu" <[email-masked]>
Date: Wed, 11 May 2011 21:44:31 +0000

Hi Dan,

Thanks very much for spending the time to review it. Comments inline:

>Unless there is a citation that SIP ALG is necessary, please strike it.

[YL] When we wrote this section, we anticipated the class rfc3261 SIP
without ICE and SBC. I will take your advice to strike it.
 
>   current practice, currently documented in [RFC4787], [RFC5382], and

[YL] Agreed and will update the text to reflect this in next revision.

>it requires an ALG!  It has been surpassed by passive-mode FTP.)

[YL] I think this is worth to mention some protocols may not work (such as
active ftp). I will work on the text to bring it up but not give any
recommendation.

We will release the next revision very soon.

/Yiu

---

From: "Lee, Yiu" <[email-masked]>
Date: Fri, 13 May 2011 01:52:50 +0000

Hi Dan,

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

Thanks,
Yiu

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 13 May 2011 15:59:31 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Lee, Yiu
> Sent: Thursday, May 12, 2011 6:53 PM
> To: Dan Wing; 'David Harrington'; 'Transport Directorate'; tsv-
> [email-masked]
> Subject: Re: TSVDIR review, draft-ietf-softwire-dual-stack-lite-08
> 
> Hi Dan,
> 
> We just released a new revision of the ds-lite draft. Did we address
> all your comments?

Yes, all my comments were addressed.

Thank you,
-d

> > * draft-ietf-sipping-nat-scenarios describes how all of this stuff
> works
> >in
> >implement ALGs in NATs.  If the IETF were to make such a
> recommendation,
> >it
> >considered a "layer 3.5", because it is not normally used for
> transport
> >but
> >I suggest striking the mention of RFC5508 from the ALG section and
> adding
> >it