Subject: [Sipping] Official review of draft-ietf-sipping-v6-transition-03.txt for WGLC

From: [email-masked]
Date: Tue, 18 Jul 2006 13:46:06 -0400

Review of draft-ietf-sipping-v6-transition-03 for WGLC.
			    Dale R. Worley

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" <[email-masked]>

    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.

[END]

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP