Draft: draft-ietf-sipping-v6-transition-03.txt Reviewer: Dale.Worley@comcast.net Review Date: Tuesday 7/18/2006 12:46 PM CST Review Deadline: 20 July 2006 Status: WGLC Summary: I believe that this I-D should advance, but the exposition needs to be clarified in several significant respects before it should become an RFC. * Technical and/or significant exposition matters Section 2. The I-D invokes the RFC 2119 all-caps words, but it uses them in only certain sections of the document. It's not clear to me whether being more meticulous in using all-caps words in the other sections would improve the document, as in most cases the discussion regards what are really "SHOULD requirements", and it is probably more important that the I-D clearly explain the pros and cons of its recommendations than that it lay down a large number of "MUST requirements". On the other hand, using more all-caps words would encourage lazy implementors to more closely adhere to the spirit of the I-D. Section 3.1. Section 3.2 duplicates much of the part of this section that deals with contacting a SIP agent based on a SIP URI. The two texts should be folded into one exposition, since proxies and UAs inherit identical behavior in that regard from the fact that they are both generic SIP agents. If these are folded together, make sure that the discussion of headers in 3.2 is not lost. (the text from "if IP addresses were used to generate the signatures ..." to "... as the basis for the Identity header and the AIB.") Section 3.1. The interaction between RFC 3263 and RFC 3484 seems to be poorly specified, and perhaps even incorrect as written. It seems to me that there is only one choice that is philosophically compatible with both RFCs, but it should be described in some detail to benefit implementors: (Note that I've omitted some details to show the overall structure of the algorithm more clearly.) As input, a SIP URI provides a host or IP address, possibly a port, and possibly a specification of acceptable transports. Step 1: NAPTR If the URI has one or more NAPTR records with appropriate "service" specifications, they are used to generate a series of domain names (with associated transport limitations) ordered by the NAPTR "order" field. Step 2: SRV The URI or the NAPTR results specify a set of domain names to be queried for SRV records. If any domain name in the list is translated by SRV records, its entry is replaced with the series of SRV results, ordered by the SRV "priority" field and the randomization implied by the "weight" field, while retaining the position relative to the other NAPTR results held by the domain name. (It is understood that at this point, the entries in the list are alternative hosts which share the labor of processing SIP requests for the SIP domain.) Step 3: A/AAAA The list now contains domain names and IP addresses. The domain names are used to find A or AAAA records, and each domain name is replaced with its addresses, while retaining the position relative to other list elements held by the domain name. (It is understood that all the A and AAAA results for a domain name route to the same host.) Step 4: RFC 3484 Within each group of addresses created by the last step, the procedures of RFC 3484 MUST be used to determine which are acceptable to contact and in what order. The output is an ordered list of network/address/transport combinations to try in order to contact an agent for the destination URI. When contacting an address/transport via IPv6, the agent uses the procedures of RFC 3484 to select a sending address, which in accordance with RFC 3261 may be placed in a Via header field as a receiving address. Section 4. I think this section needs an additional paragraph, inserted before the last paragraph, that sharply describes what the recommendation *is*, possibly using all-caps words. Most of the section lays out the considerations involved, and the last paragraph speaks of the advantages and disadvantages of "this strategy", but the writing leaves it somewhat implicit what the strategy is: An IPv6 host SHOULD be able to send and receive media using IPv4, but if it cannot, it SHOULD have use of an administratively associated relay that allow it to indirectly send and receive media using IPv4. Section 4.1, item 2. The intent is clear, but I think the phrasing needs improvement, since "c=" lines can be applied to either the entire session description or an individual media description, and there are multiple media descriptions, which separately must match: Each media description in the SDP answer MUST use the same network type as the corresponding media description in the offer. E.g., if the applicable "c=" line for a media description in the offer contained a network type with the value "IP4", the applicable "c=" line for the corresponding media description in the answer MUST contain "IP4" as the network type. [delete next sentence] Sections 4.2 and 4.3. These seem sketchy, as if they were notes regarding the topics, rather than a solidified description. I am not familiar with ICE/STUN/TURN, and perhaps a fuller knowledge of those protocols would make these sections clearer. But as a principle of writing, the logical structure of the section should be clear without prior knowledge of ICE/STUN/TURN. An example of the problem: The sentence "Note that, in case of forking, the same offer carried in an INVITE request can arrive to an IPv4-only user agent and to an IPv6-only user agent at roughly the same time." is clear enough, but it seems to have no relationship with the other sentences in the section. * Issues raised by other reviewers From: "Francois Audet" What will a hop that doesn't understand IPv6 addresses do with a Record-Route entry that includes an IPv6 address? Won't it have a problem with it? Gonzalo's poll of existing implementers convinces me that this is not a serious problem. Instead of having 2 separate Record-Route entries for the same interface (one IPv4 and one IPv6), wouldn't it make more sense to have only 1 entry which includes alternative addresses? That would be an improvement, but you might as well use a FQDN in the Record-Route to achieve this effect, rather than defining additional syntax for Record-Route. (And new syntax will *immediately* be incompatible with *all* implementations.) * Wording and nits The phrase "raw IP address" is used in several places. It is an evocative phrase to use in speech, but I see no added value to it in writing, since even in colloquial usage "IP address" is never used to include domain names (though "address" often is). Section 3.1. "Regardless of which network is tried first, each search corresponds to a different branch, and as such, mandates that the the normative behavior in RFC3261 to handle requests sent on a branch be followed." Clearer would be "In accordance with section 4.3 of RFC 3263, each attempt to contact a different network/address/transport combination MUST be treated as a separate request transaction, and in particular, must have a distinct value of the branch parameter of the topmost Via header field." Section 3.1.1. "If the proxy is inserting a URI that contains a fully qualified domain name of the proxy, then inserting one Record-Route header suffices; ..." should be "If the proxy is inserting a URI that contains a fully qualified domain name of the proxy, and the FQDN has both IPv4 and IPv6 addresses, then inserting one Record-Route header suffices; ...". This qualification is necessary because sometimes domain names are used to name interfaces rather than hosts, so the fact that a domain name routes to a dual-stacked host doesn't imply that *that* domain name has both types of address. Section 3.1.1, figure. It would help to add "IPv4" in the header between "UAC" and "Proxy", and add "IPv6" in the header between "Proxy" and "UAS": UAC IPv4 Proxy IPv6 UAS | P | | | | +-----F1------------>| | | +------F2------------>| | | | | |<-----F3-------------+ |<----F4-------------+ | Section 3.1.1. "It's route set will include ..." should be "Its route set will include ...". Section 3.1.1. "Strictly speaking, the proxy could have inserted its FQDN in the Record-Route URI and the result would have been the same." is awkward. Perhaps "Alternatively, the proxy could have inserted its FQDN in one Record-Route URI to achieve the same effect." Section 3.2. "and transport protocol of the next hop to contact lookups" -- it appears that the words "to contact lookups" are extraneous. Section 4, item 2. "utilizing Layer-2s" probably reads better as "utilizing Layer-2's" Section 4. "relays (i.e., TURN)" should be "relays (e.g., TURN)", as "i.e." means "that is", and thus states that all relays are TURN, whereas a particular SIP agent may know of a non-TURN agent. Section 4. "but an operator that" should be "but it requires an operator that" Section 4. "as a NAT-traversal" should be "for NAT traversal" Section 4. "limited from this aspect" should be "limited in this respect" Section 4.2. "gather addresses following" should be "gather addresses by following" Section 4.2. "gather IPv4 and IPv6 addresses" should be "gather both IPv4 and IPv6 addresses" Section 4.2. Delete the sentence "Note that, in case of forking, the same offer carried in an INVITE request can arrive to an IPv4-only user agent and to an IPv6-only user agent at roughly the same time.", unless it serves some purpose that is not now stated. Section 4.3. "This checks help" should be "These checks help" Section 6. "(TURN, STUN, SDP)" should be "(TURN [10], STUN [6], SDP [2])", as that allows someone who reads only the Security Considerations section to quickly find the included-by-reference Security Considerations for all of the included protocols. Section 6. "This document does not introduce .." is unclear -- does it mean "This document does not describe any new security threats." or "The procedures introduced in this document do not introduce any new security threats."? Section 8.2. Reference [18] (RFC 3484, "Default Address Selection for Internet Protocol Version 6 (IPv6)") should be promoted to Normative, as it is referenced with a MUST in sections 3.1 and 3.2.