IPv6 Transition in the Session Initiation Protocol (SIP)
draft-ietf-sipping-v6-transition-07

[Ballot discuss]
Some of my issues were resolved in the new revision,
but the below one still appear to be a problem:

> An IPv6-only node SHOULD be able to send and receive media using IPv4
> addresses ...

This does not seem to make sense to me. Did you mean "An IPv6
node SHOULD be also able to support IPv4 for media?"

[Ballot discuss]
Some of my issues were resolved in the new revision,
but the below ones still appear to be problems:

> An IPv6-only node SHOULD be able to send and receive media using IPv4
> addresses ...

This does not seem to make sense to me. Did you mean "An IPv6
node SHOULD be also able to support IPv4 for media?"

> 1. In some cases, especially those dealing with third party call
>    control (see Section 4.2 of [12]), there arises a need to specify
>    the IPv6 equivalent of the IPv4 unspecified address (0.0.0.0) in
>    the SDP offer.  For this, IPv6 implementations MUST use a domain
>    name within the .invalid DNS top-level domain instead of of using
>    the IPv6 unspecified address (i.e., ::).

Why? Is there some SIP-syntax related interaction that prevents
:: from being used?

[Ballot discuss]
Some of my issues were resolved in the new revision,
but the below ones still appear to be problems:

> An IPv6-only node SHOULD be able to send and receive media using IPv4
> addresses ...

This does not seem to make sense to me. Did you mean "An IPv6
node SHOULD be also able to support IPv4 for media?"

> ... but if it cannot, it SHOULD have the use of an
> administratively associated relay (i.e., STUN relay usage [8]) that
> allows it to indirectly send and receive media using IPv4.

The word SHOULD is ambiguous here. Do you mean that the node
SHOULD support STUN? Or that the network admins SHOULD
ensure that a STUN relay is available in such a situation?
Or both? I would recommend just stating that STUN support
is a SHOULD, and then talking about the expected network
configuration without keywords.

> 1. In some cases, especially those dealing with third party call
>    control (see Section 4.2 of [12]), there arises a need to specify
>    the IPv6 equivalent of the IPv4 unspecified address (0.0.0.0) in
>    the SDP offer.  For this, IPv6 implementations MUST use a domain
>    name within the .invalid DNS top-level domain instead of of using
>    the IPv6 unspecified address (i.e., ::).

Why? Is there some SIP-syntax related interaction that prevents
:: from being used?

[Ballot discuss]
Some of my issues were resolved in the new revision,
but the below ones still appear to be problems. I apologize


> An IPv6-only node SHOULD be able to send and receive media using IPv4
> addresses ...

This does not seem to make sense to me. Did you mean "An IPv6
node SHOULD be also able to support IPv4 for media?"

> ... but if it cannot, it SHOULD have the use of an
> administratively associated relay (i.e., STUN relay usage [8]) that
> allows it to indirectly send and receive media using IPv4.

The word SHOULD is ambiguous here. Do you mean that the node
SHOULD support STUN? Or that the network admins SHOULD
ensure that a STUN relay is available in such a situation?
Or both? I would recommend just stating that STUN support
is a SHOULD, and then talking about the expected network
configuration without keywords.

> 1. In some cases, especially those dealing with third party call
>    control (see Section 4.2 of [12]), there arises a need to specify
>    the IPv6 equivalent of the IPv4 unspecified address (0.0.0.0) in
>    the SDP offer.  For this, IPv6 implementations MUST use a domain
>    name within the .invalid DNS top-level domain instead of of using
>    the IPv6 unspecified address (i.e., ::).

Why? Is there some SIP-syntax related interaction that prevents
:: from being used?

[Ballot discuss]
This is a great document overall, and once the following issues
have been resolved I will move to a Yes vote.

> 2.  Networks utilizing Layer-2's that do not support contemporary
>    IPv4 and IPv6 usage on the same link (e.g., the 3rd Generation
>    Partnership Project, 3GPP).

I am not aware of such a limitation. I believe there is a limitation
that one PDP Context (a virtual connection over an actual radio
resource) is exclusively either for IPv4 or IPv6. However, you
can create multiple PDP Contexts. Suggested edit is deleting the
text in parantheses, or softening the "do not support" statement
to include something about unwillingness to spend resources for
both.

> An IPv6-only node SHOULD be able to send and receive media using IPv4
> addresses ...

This does not seem to make sense to me. Did you mean "An IPv6
node SHOULD be also able to support IPv4 for media?"

> ... but if it cannot, it SHOULD have the use of an
> administratively associated relay (i.e., STUN relay usage [8]) that
> allows it to indirectly send and receive media using IPv4.

The word SHOULD is ambiguous here. Do you mean that the node
SHOULD support STUN? Or that the network admins SHOULD
ensure that a STUN relay is available in such a situation?
Or both? I would recommend just stating that STUN support
is a SHOULD, and then talking about the expected network
configuration without keywords.

> 1. In some cases, especially those dealing with third party call
>    control (see Section 4.2 of [12]), there arises a need to specify
>    the IPv6 equivalent of the IPv4 unspecified address (0.0.0.0) in
>    the SDP offer.  For this, IPv6 implementations MUST use a domain
>    name within the .invalid DNS top-level domain instead of of using
>    the IPv6 unspecified address (i.e., ::).

Why? Is there some SIP-syntax related interaction that prevents
:: from being used?

[Ballot discuss]
[I am probably about to expose my ignorance wrt to SIP, but here goes nothing...]

From the Abstract and Section 3.1, I understood the goals of this document to supporting
transition for user agents that only support IPV4 or IPV6.  Specifically, the abstract begins with
"This document describes how IPV4 [SIP] user agents can communicate with IPv4 user agents..."
and in section 3.1, Proxy Behavior, the second sentence begins "In order to support both
IPv4-only and IPv6-only user agents ..."

However, the second paragraph of Section 3.2 says:
"Autonomous domains SHOULD deploy dual-stack user agent servers, or alternatively,
deploy both IPv4-only and IPv6-only servers."

If we follow the other guidance in the specification regarding dual-stack inbound and
outbound proxy servers why is this necessary?  And are we really likely to have dual
stack user agent servers with IPv4-only or IPv6-only user agents?

[Ballot discuss]
[I am probably about to expose my ignorance wrt to SIP, but here goes nothing...]

From the Abstract and Section 3.1, I understood the goals of this document to supporting transition for user agents that only support IPV4 or IPV6.  Specifically, the abstract begins with
"This document describes how IPV4 [SIP] user agents can communicate with IPv4 user agents..."
and in section 3.1, Proxy Behavior, the second sentence begins "In order to support both
IPv4-only and IPv6-only user agents ..."

However, the second paragraph of Section 3.2 says:
"Autonomous domains SHOULD deploy dual-stack user agent servers, or alternatively,
deploy both IPv4-only and IPv6-only servers."

If we follow the other guidance in the specification regarding dual-stack inbound and
outbound proxy servers why is this necessary?  And are we really likely to have dual
stack user agent servers with IPv4-only or IPv6-only user agents?

[Ballot comment]
Based on Gen-ART Review by Suresh Krishnan

  Since the document mentions usage of dual stack it makes sense to
  add an informative reference to RFC4213.

[Ballot comment]
Section 3.1., paragraph 0:
> 3.1.  Proxy Behavior

  If IPv6 transition capabilities depend on the presence of v4/v6
  proxies (and DNS entries, etc.), the document should REQUIRE their
  presence, rather than merely RECOMMEND them. (Or is there another IPv6
  transition mechanism that doesn't require this?)

PROTO Write-up

1.a) Have the chairs personally reviewed this version of the Internet
Draft (ID), and in particular, do they believe this ID is ready
to forward to the IESG for publication? Which chair is the WG
Chair Shepherd for this document?

Yes, the WG chairs have reviewed and believe the ID is ready.
Mary Barnes is the WG Chair Shepherd for this document.

1.b) Has the document had adequate review from both key WG members
and key non-WG members? Do you have any concerns about the
depth or breadth of the reviews that have been performed?

The document has been reviewed by WG members, with no concerns about the
depth or breadth of the review.

1.c) Do you have concerns that the document needs more review from a
particular (broader) perspective (e.g., security, operational
complexity, someone familiar with AAA, internationalization,
XML, etc.)?

No.

1.d) Do you have any specific concerns/issues with this document that
you believe the ADs and/or IESG should be aware of? For
example, perhaps you are uncomfortable with certain parts of the
document, or have concerns whether there really is a need for
it. In any event, if your issues have been discussed in the WG
and the WG has indicated it that it still wishes to advance the
document, detail those concerns in the write-up.

No.

1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

There is strong WG consensus behind this document and no one that has
expressed concerns about its progression.

1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email to the Responsible Area Director. (It should be
separate email because this questionnaire will be entered into
the tracker).
No.

1.g) Have the chairs verified that the document checks out against
all the ID nits? (see http://www.ietf.org/ID-Checklist.html).
Boilerplate checks are not enough; this check needs to be
thorough.

Yes.

1.h) Has the document split its references into normative and
informative? Are there normative references to IDs, where the
IDs are not also ready for advancement or are otherwise in an
unclear state? The RFC Editor will not publish an RFC with
normative references to IDs (will delay the publication until
all such IDs are also ready for RFC publicatioin). If the
normative references are behind, what is the strategy for their
completion? On a related matter, are there normative references
that are downward references, as described in BCP 97, RFC 3967
RFC 3967 [RFC3967]? Listing these supports the Area Director in
the Last Call downref procedure specified in RFC 3967.

The references are split into normative and informative.

There are three normative reference that are not yet published as RFCs:


[9] Rosenberg, J., Mahy, R., and C. Huitema, "Traversal Using Relay
NAT (TURN)", draft-ietf-behave-turn-01 (work in progress),
February 2006.

[10] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A
Methodology for Network Address Translator (NAT) Traversal for
Offer/Answer Protocols", draft-ietf-mmusic-ice-08 (work in
progress), March 2006.

[11] Camarillo, G. and O. Novo, "Traversal Using Relay NAT (TURN)
Extension for IPv4/IPv6 Transition",
draft-ietf-behave-turn-ipv6-00 (work in progress).

These documents have not yet undergone IESG review, however they are
high priority work
items, so their publication should not introduce too large of a delay
into the publication
timeframe for this document. Also, the references to these other
documents is at a very
high level, thus detailed changes in those documents should not impact
the content of this document.

There are no normative references which are downward references.

------

Protocol write-up for: draft-ietf-sipping-v6-transition-04
by Mary Barnes, mary.barnes@nortel.com, 19 Sept 2006

Technical Summary

This document describes how IPv4 Session Initiation Protocol (SIP)
user agents can communicate with IPv6 SIP user agents (and vice
versa) at the signaling layer as well as exchange media once the
session has been successfully set up. Both single- and dual-stack
(i.e., an IPv4-only and an IPv4/IPv6) user agents are considered.


Working Group Summary

The SIPPING WG supports the development and advancement of this
document.
In addition, this document updates RFC 3264, which was developed in
the MMUSIC WG.
However, the MMUSIC chairs have agreed to the completion of this work
within the
SIPPING WG.

Protocol Quality

This document defines a normative update to the processing described
in RFC 3264.
It does not introduce any new protocol elements. This normative
processing is clearly
defined in section 4.1.

This document was thoroughly reviewed by WG chairs and WG members,
including
those with expertise in IPv4 to IPv6 transitions and interworking.

Mary Barnes is the WG chair shepherd. Jon Peterson is the responsible
Area
director.


------



Mary H. Barnes
mary.barnes@nortel.com