Draft: draft-ietf-sipping-nat-scenarios-07 Reviewer: Vijay K. Gurbani Review Date: Sept 4th, 2007 Review Deadline: Sept 10th, 2007 Status: pre-WGLC Summary: -------- This draft is a great survey paper on NAT traversal techniques. It discusses the various traversal techniques for both media and signaling to provide a complete overview to the reader. There has been some concern that we want to make sure that the draft is in the right direction. I believe it is. Comments: --------- A couple of general comments first: 1) S5 talks about IPv4-IPv6 transition. I would suggest adding a sentence at the beginning of the text allowing the reader to appreciate that this draft is more than NAT traversal techniques in the context of public and private networks (which is what the draft's current focus is on.) Some text that tells the reader of other uses can be added at the beginning: While the techniques discussed in this draft primarily contain examples of traversing NATs to allow communications between hosts in private and public networks, they are by no means limited to such scenarios. The same NAT traversal techniques can also be used to establish communication in a heterogeneous network environment -- e.g., communication between an IPv4 host and an IPv6 host. Example of such a case is depicted in Section Section 5. 2) S5.2 discusses ANAT in the context of grouping IPv4 and IPv6 addresses. We decided to deprecate ANAT in the Prague IETF. So discussions related to ANAT should now reflect ICE instead. 3) Some figure have titles and others don't. Would suggest consistency by providing titles on all figures. The rest of the comments are in section-order. First are the comments on contents of the draft, followed by editorial comments on the text and nits. - S2, Figure 1: I would suggest that you renumber the port 5650 in the figure to something more ephemeral, like 10923, for instance. 5650 visually is very close to the default SIP port (5060) and it took me a while to appreciate that you had 5650 written on the right-hand side of the figure and not 5060! - S2: the discussion around Figure 2 could refer to connect-reuse. Especially in the paragraph right under Figure 2 where it says "While this problem has been discussed in the context of connection-oriented protocols such as TCP, the problem exists of SIP signaling using any transport protocols." I would suggest adding the following sentence immediately after: "The impact of connection reuse of connection oriented transports (TCP, TLS, etc.) is discussed in more detail in connect-reuse [ref]." - S2, page 5, first paragraph (under Figure 2), last sentence: Section 3 of this document contains many approaches. Which specific one did you have in mind? Also, it may be better to reword the sentence to say that "the approach" instead of "the solution". This draft is a BCP draft, as such it demonstrates which one of the existing approaches (or solutions) is better; it does not propose a new solution. - S2, page 5, second paragraph, third sentence: it is stated that SIP signaling cannot be relied on to keep the NAT bindings open for a "number of reasons." And then, two reasons are given. Are there more? If not, I would suggest simply s/a number of reasons/the following two reasons:/ - S2, page 6, last paragraph of the section: I would suggest replacing the entire paragraph with the following text: "The connection addresses of the clients behind the NATs will nominally contain a private IPv4 or IPv6 address that is not routable across the public Internet. Exacerbating matters even more would be the tendency of Client A to send media to a destination address it received in the signaling confirmation message -- an address that may actually correspond to a host within the private network who is suddenly faced with incoming RTP packets (likewise, Client B may send media to a host within its private network who did not solicit these packets.) And finally, to complicate the problem even further, a number of different NAT topologies with different default behaviors increases the difficulty of arriving at a single approach." - S2, third paragraph: UDP expands to "User Datagram Protocol" not "Unicast Datagram Protocol" - S3.1.1, Figure 4: I do not believe that Figure 4 contributes much to the text. One way to make it more relevant would be to take the IP addresses and ports of the example in rfc3581 (S6 of that RFC) and turn those into Figure 4. - S3.1.2, last paragraph: If SIP outbound is not being used, people should be pointed out to connect-reuse as an alternative at least between proxies. Also, reusing the same TCP connection is not recommended by that document, and as such, should not be mentioned as a solution by nat-scenarios. - S3.1.2, Reference [13] points to a very old version of outbound (circa 2005]; suggest using the latest version. - S3.2.1, Reference [15] is now rfc4961, bcp131. Please update. - S3.2.1.1, Reference [6] points to rfc3581, not rfc3605, as appears to be the intent in line seven of that section. - S3.2.2, Reference [11] is now rfc4787. - S3.2.2: Those not familiar with rfc4787 will not have any idea of the terms "Endpoint independent mapping" and "Address dependent mapping." As a survey paper (or RFC), nat-scenarios could either provide a quick blurb on what these are, or can simply state that: However, STUN does not work with certain NATs prevelant in the marketplace; for more information on the characteristics of such NATs, please see RFC4787 [11]. - S3.2.5.1: Reference [6] points to rfc3581, not rfc3605, as appears to be the intent in line two of that section. - S3.2.5.2: Reference [6] points to rfc3581, not rfc3605, as appears to be the intent in line two of that section. - S3.2.5, at the end of that section, I would suggest adding a table like this (double-check my rows and columns): | Primary | Consumer | Minimal | | Profile | Profile | Profile | ---------+----------+----------+---------+ ICE | Yes | No | No | ---------+----------+----------+---------+ STUN | Yes | Yes | No | ---------+----------+----------+---------+ TURN Use | Yes | No | No | ---------+----------+----------+---------+ RFC3605 | Yes | Yes | No | ---------+----------+----------+---------+ Symm. RTP| Yes | No | Yes | (RFC4961)| | | | ---------+----------+----------+---------+ - S4.1.1.2, towards the end of the section: s/Connection Re-use draft [13]/outbound draft [13] - S4.1.2, page 17, last sentence of the topmost paragraph: s/REGISTER message (5) would look as follows:/The REGISTER message of (5), when proxied in (6) looks as follows:/ - S4.1.4.1, page 22: In message (2), shouldn't the R-URI be re-written with the address registered earlier? Also, there are two "sip" schemes in the R-URI for message (2); i.e., "sip:sip:client@client.example.com" - S4.1.4.2 is empty. - S4.2.1.1.1, on page 27, in the discussion around message flows (5)-(8), you may want to explain that the second local address requested for STUN is for the RTCP port. - S4.2.1.1.2, page 30, in the discussion around message flows (7)-(10), you may want to explain that the second local address requested for STUN is for the RTCP port. - The next figure after Figure 20 is Figure 22. There isn't a Figure 21 as far as I can see. - S4.2.1.2.1, Figure 23, page 39: Continuation in the SDP is denoted by a new convention -- using the bigram /*. I have not seen this new convention in any SIP-related drafts yet. Instead of using a new convention, maybe we should continue to use the existing convention of markup. Alternatively, off-hand, I do not recall what SDP's ABNF says about line continuation, but if it requires a LWS, the continuation character could be a normal space. I lean towards using already established conventions for the sake of the reader who may be familiar with these from reading previous SIP-related RFCs/I-Ds. - S4.2.1.2.1, the SDP at the bottom of page 40: two comments on this. First comment echoes the above use of the bigram for continuation. Second comment is that you should consider numbering this ICE SDP answer for the sake of consistency since the ICE SDP offer was numbered as Figure 23. - S4.2.1.2.1, page 41, first bullet item: I don't know what is the expected depth of understanding of the reader with respect to ICE when reading this paragraph. For instance, once ICE has frozen the candidates in L, does the connectivity check proceed in parallel or in sequence? That is, is foundation $L1 tried first, and if connectivity checks fail, then foundation $L2 is tried? Or do they proceed in parallel? Maybe inserting a quick statement right after the sentence "At this stage, all .... 'Frozen' state." (at about midway down the bullet item.) Second comment is more editorial, but I will include it here since we are discussing this sub-section anyway: consider adding para- graphs for readability. There is a lot of information in this bullet item, so re-organizing this in a few paragraphs would help tremendously. - S4.2.1.2.1, Figure 22, page 34: At about half-way down the page, there is a depiction of media flowing from L to R. However, there isn't any noun for the "from" preposition. I think the "from" should be followed by the foundation $L-NAT-PUB-1, but please double-check. In fact, in the rest of the figure, all of the "from" prepositions do not have a noun associated with them. May want to consider putting the right foundation after the "from". - S4.2.1.2.1, Figures 25 and 26: Same comment as the one in "S4.2.1.2.1, Figure 23, page 39" above: Continuation in the SDP is denoted by a new convention -- using the bigram /*... - S4.2.2.1, Figure 27: Since you are using the foundation "L-PRIV-1", you may want to consider re-labeling the "Client" vertical line with "L". - S4.2.2.2, first paragraph, page 45: "STUN toolkit" or "STUN profile"? Editorial comments, including nits: ===================================== - S1, first sentence: s/large/complex/ - S1, second sentence: s/further confused/made worse/ or "exacerbated" works as well. - S1, second paragraph, first sentence: You may want to reconsider the word "produced"; not all of the protocols mentioned are RFCs yet. - S1, second paragraph, first sentence: You may want to provide a reference to each of the protocol you mention. - S1, third paragraph, first sentence: s/attempts to provide/provides - S1, last paragraph: s/will be split/is split or "is organized" works as well. - S2, first paragraph can be tightened considerably. Something like: Normal SIP response routing over UDP causes the response to be delivered to source IP address specified in the topmost Via header, or the "received" parameter of the topmost Via header. The port is extracted ... - S2, page 5, second paragraph, second sentence: s/This period of inactivity can range drastically from/This period of inactivity may vary from/ - S2, page 5, second paragraph, third sentence: suggest taking the word "Pure" out; doesn't contribute much. - S2, page 5, last paragraph: s/RTP [2]]/RTP [2]/ - S2, page 6, last paragraph of the section: s/are not available/is not available alternatively, you can make "address" plural, and then leave it as "are not available" - S3, first two sentences: consider rewording as follows: As mentioned previously, the traversal of SIP through existing NATs can be divided into two discrete problem areas: getting the core signaling across the NAT, and enabling media as specified by SDP in a SIP offer/answer exchange to flow between endpoints. - S3.2.1, s/NAT(as illustrated/NAT (as illustrated/ - S3.2.1, towards the end of the section, you have a sentence: "This technique is known as 'Symmetric RTP' and is documented in [15]." Consider: a) Removing that sentence; b) Putting reference [15] nine lines above, where you first mention 'Symmetric' RTP. - S3.2.5.2: s/in the unfortunate situation of being// (i.e., delete that phrase.) - S4.1.2, page 17, last paragraph: s/new Registration/new registration - S4.1.3.1, Figure 8: In reality, you can compress the figure by only including the following messages: 3 and 4 and abstract the rest using "...". The discussion that follows the figure focuses on the contents of the INV request; the challenge shown in message 2, and the ringing in message 5 and 6 and everything below that is inconsequential. - S4.2, towards the end of page 23: For the sake of completeness it may be good to provide a reference to the ICE specification in the sentence "Detailed information on individual ... the core ICE specification." - S4.2.1.1.2, Figure 20: You may want to consider beginning the vertical line under the heading "STUN Server" after the horizontal line of the SIP INVITE (1). As the drawing is depicted now, it appears that the SIP INVITE request is going through the STUN server, which is not the case. - S4.2.1.2, the partial sentence on top of page 31: s/when initiating./when initiating the session./ - S4.2.1.2.1, page 41, first bullet item: s/work there way/work their way/ - S4.2.2.2, page 48: The second bullet sign on the page appears to be superfluous.