draft-ietf-sipcore-dns-dual-stack-07.txt   draft-ietf-sipcore-dns-dual-stack-08.txt 
SIPCORE O. Johansson SIPCORE O. Johansson
Internet-Draft Edvina AB Internet-Draft Edvina AB
Updates: 3263 (if approved) G. Salgueiro Updates: 3263 (if approved) G. Salgueiro
Intended status: Standards Track Cisco Systems Intended status: Standards Track Cisco Systems
Expires: January 9, 2017 V. Gurbani Expires: March 4, 2017 V. Gurbani
Bell Labs, Nokia Networks Bell Labs, Nokia Networks
D. Worley, Ed. D. Worley, Ed.
Ariadne Ariadne
July 8, 2016 August 31, 2016
Locating Session Initiation Protocol (SIP) Servers in a Dual-Stack IP Locating Session Initiation Protocol (SIP) Servers in a Dual-Stack IP
Network Network
draft-ietf-sipcore-dns-dual-stack-07 draft-ietf-sipcore-dns-dual-stack-08
Abstract Abstract
RFC 3263 defines how a Session Initiation Protocol (SIP) RFC 3263 defines how a Session Initiation Protocol (SIP)
implementation, given a SIP Uniform Resource Identifier (URI), should implementation, given a SIP Uniform Resource Identifier (URI), should
locate the next-hop SIP server using Domain Name System (DNS) locate the next-hop SIP server using Domain Name System (DNS)
procedures. As SIP networks increasingly transition from IPv4-only procedures. As SIP networks increasingly transition from IPv4-only
to dual-stack, a quality user experience must be ensured for dual- to dual-stack, a quality user experience must be ensured for dual-
stack SIP implementations. This document updates the DNS procedures stack SIP implementations. This document updates the DNS procedures
described in RFC 3263 for dual-stack SIP implementations in described in RFC 3263 for dual-stack SIP implementations in
skipping to change at page 1, line 44 skipping to change at page 1, line 44
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 9, 2017. This Internet-Draft will expire on March 4, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. DNS Procedures in a Dual-Stack Network . . . . . . . . . . . 4 3. DNS Procedures in a Dual-Stack Network . . . . . . . . . . . 4
3.1. Dual-Stack SIP UA DNS Record Lookup Procedure . . . . . . 4 3.1. Dual-Stack SIP UA DNS Record Lookup Procedure . . . . . . 4
3.2. Indicating Address Family Preference in DNS SRV Records . 5 3.2. Indicating Address Family Preference in DNS SRV Records . 5
4. Clarification of interaction with RFC 6724 . . . . . . . . . 5 4. Clarification of Interaction with RFC 6724 . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
8. Revision History . . . . . . . . . . . . . . . . . . . . . . 8 8. Revision History . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Changes from draft-ietf-sipcore-dns-dual-stack-06 to 8.1. Changes from draft-ietf-sipcore-dns-dual-stack-07 to
draft-ietf-sipcore-dns-dual-stack-07 . . . . . . . . . . 8 draft-ietf-sipcore-dns-dual-stack-08 . . . . . . . . . . 8
8.2. Changes from draft-ietf-sipcore-dns-dual-stack-05 to 8.2. Changes from draft-ietf-sipcore-dns-dual-stack-06 to
draft-ietf-sipcore-dns-dual-stack-06 . . . . . . . . . . 8 draft-ietf-sipcore-dns-dual-stack-07 . . . . . . . . . . 9
8.3. Changes from draft-ietf-sipcore-dns-dual-stack-04 to 8.3. Changes from draft-ietf-sipcore-dns-dual-stack-05 to
draft-ietf-sipcore-dns-dual-stack-05 . . . . . . . . . . 8 draft-ietf-sipcore-dns-dual-stack-06 . . . . . . . . . . 9
8.4. Changes from draft-ietf-sipcore-dns-dual-stack-03 to 8.4. Changes from draft-ietf-sipcore-dns-dual-stack-04 to
draft-ietf-sipcore-dns-dual-stack-04 . . . . . . . . . . 8 draft-ietf-sipcore-dns-dual-stack-05 . . . . . . . . . . 9
8.5. Changes from draft-ietf-sipcore-dns-dual-stack-02 to 8.5. Changes from draft-ietf-sipcore-dns-dual-stack-03 to
draft-ietf-sipcore-dns-dual-stack-03 . . . . . . . . . . 9 draft-ietf-sipcore-dns-dual-stack-04 . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 8.6. Changes from draft-ietf-sipcore-dns-dual-stack-02 to
draft-ietf-sipcore-dns-dual-stack-03 . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . 10 9.1. Normative References . . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . 10 9.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
The Session Initiation Protocol (SIP, [RFC3261]) and the additional The Session Initiation Protocol (SIP, [RFC3261]) and the additional
documents that extended it provide support for both IPv4 and IPv6. documents that extended it provide support for both IPv4 and IPv6.
However, this support does not fully extend to the highly hybridized However, this support does not fully extend to the highly hybridized
environments that are characteristic of the transitional migratory environments that are characteristic of the transitional migratory
phase from IPv4 to IPv6 networks. During this phase, many server and phase from IPv4 to IPv6 networks. During this phase, many server and
client implementations run on dual-stack hosts. In such client implementations run on dual-stack hosts. In such
skipping to change at page 3, line 45 skipping to change at page 4, line 5
that are specific to the SIP domain such as "proxy", "registrar", that are specific to the SIP domain such as "proxy", "registrar",
"redirect server", "user agent server" or "UAS", "user agent client" "redirect server", "user agent server" or "UAS", "user agent client"
or "UAC", "back-to-back user agent" or "B2BUA", "dialog", or "UAC", "back-to-back user agent" or "B2BUA", "dialog",
"transaction", and "server transaction". "transaction", and "server transaction".
This document uses the term "SIP server" that is defined to include This document uses the term "SIP server" that is defined to include
the following SIP entities: user agent server, registrar, redirect the following SIP entities: user agent server, registrar, redirect
server, a SIP proxy in the role of user agent server, and a B2BUA in server, a SIP proxy in the role of user agent server, and a B2BUA in
the role of a user agent server. the role of a user agent server.
This document also uses the following terminology to make clear While this document focuses on the dual-stack situation described in
distinction between SIP entities supporting only IPv4, only IPv6 or RFC 6555 and other documents, concerning the migration from an
supporting both IPv4 and IPv6: IPv4-only network to a network supporting both IPv4 and IPv6, the
techniques described can be used in other situations. Possible
IPv4-only UA/UAC/UAS: An IPv4-only UA/UAC/UAS supports SIP signaling situations include when a device has multiple interfaces with
and media only on the IPv4 network. It does not understand IPv6 distinct addressing characteristics and when additional IP address
addresses. families are created in the future. This document uses the general
term "dual-stack" to include all situations where the client has
IPv6-only UA/UAC/UAS: An IPv6-only UA/UAC/UAS supports SIP signaling access to multiple communication methods that have distinct
and media only on the IPv6 network. It does not understand IPv4 addressing characteristics.
addresses.
dual-stack UA/UAC/UAS: A UA/UAC/UAS that supports SIP signaling and
media on both IPv4 and IPv6 networks.
The term "address records" means the DNS records which translate a The term "address records" means the DNS records which translate a
domain name into addresses within the address family(ies) that the domain name into addresses within the address family(ies) that the
entity supports (as A records provide IPv4 addresses and AAAA records entity supports (as A records provide IPv4 addresses and AAAA records
provide IPv6 addresses), regardless of whether the address family was provide IPv6 addresses), regardless of whether the address family was
defined before or after this document was approved. defined before or after this document was approved.
3. DNS Procedures in a Dual-Stack Network 3. DNS Procedures in a Dual-Stack Network
This specification introduces two normative DNS lookup procedures. This specification introduces two normative DNS lookup procedures.
skipping to change at page 5, line 9 skipping to change at page 5, line 13
explicit port once the A or AAAA records have been looked up. explicit port once the A or AAAA records have been looked up.
Happy Eyeballs [RFC6555] documents that looking up the "A or AAAA Happy Eyeballs [RFC6555] documents that looking up the "A or AAAA
record" is not an effective practice for dual-stack clients and that record" is not an effective practice for dual-stack clients and that
it can add significant connection delay and greatly degrade user it can add significant connection delay and greatly degrade user
experience. Therefore, this document makes the following normative experience. Therefore, this document makes the following normative
addendum to the DNS lookup procedures of Section 4.2 of RFC 3263 addendum to the DNS lookup procedures of Section 4.2 of RFC 3263
[RFC3263] for IPv4/IPv6 hybrid SIP networks and recommends it as a [RFC3263] for IPv4/IPv6 hybrid SIP networks and recommends it as a
best practice for such dual-stack networks: best practice for such dual-stack networks:
The dual-stack client SHOULD look up all address records (i.e., The dual-stack client SHOULD look up address records for all
for all address family(ies) that it supports) for the domain name address families that it supports for the domain name and add the
and add the resulting addresses to the list of IP addresses to be resulting addresses to the list of IP addresses to be contacted.
contacted. A client MUST be prepared for the existence of DNS A client MUST be prepared for the existence of DNS resource
resource records containing addresses in families that it does not records containing addresses in families that it does not support;
support; if such records may be returned by the client's DNS if such records may be returned by the client's DNS queries, such
queries, such records MUST be ignored as unusable and the records MUST be ignored as unusable and the supported addresses
supported addresses used as specified herein. used as specified herein.
3.2. Indicating Address Family Preference in DNS SRV Records 3.2. Indicating Address Family Preference in DNS SRV Records
The Happy Eyeballs algorithm [RFC6555] is particularly effective for The Happy Eyeballs algorithm [RFC6555] is particularly effective for
dual-stack HTTP client applications that have significant performance dual-stack HTTP client applications that have significant performance
differences between their IPv4 and IPv6 network paths. This is differences between their IPv4 and IPv6 network paths. This is
because the client can initiate two TCP connections to the server, because the client can initiate two TCP connections to the server,
one using IPv4 and one using IPv6, and then use the connection which one using IPv4 and one using IPv6, and then use the connection which
completes first. completes first. This works properly because the client can test
each route by initiating a TCP connection, but simply opening a TCP
connection to an HTTP server does not change the server's state; the
client will send the HTTP request on only one connection.
Unfortunately, in common SIP situations, it is not possible to "race" Unfortunately, in common SIP situations, it is not possible to "race"
simultaneous request attempts using two address families. In this simultaneous request attempts using two address families. If the SIP
common scenario it is often necessary for a dual-stack client to requests are transmitted as single UDP packets, sending two copies of
indicate a preference for either IPv4 or IPv6. A service may use DNS the request to two different addresses risks having two copies of the
SRV records to indicate such a preference for an address family. request propagating through the SIP network at the same time. The
difference between SIP and HTTP is that in SIP the sender cannot test
a route in a non-state-changing way.
(If two copies of the same request arrive at the destination client,
the client MUST reject the second of them with a 482 "Merged Request"
response.[RFC3261] But this rule is not sufficient to prevent user-
visible differences in behavior. A proxy that is upstream of the
second request to arrive at the client may (almost immediately!)
serially fork the second request to further destinations (e.g., the
voicemail service for the destination client).)
In this common scenario it is often necessary for a dual-stack client
to indicate a preference for either IPv4 or IPv6. A service may use
DNS SRV records to indicate such a preference for an address family.
This way, a server with a high-latency and/or low-capacity IPv4 This way, a server with a high-latency and/or low-capacity IPv4
tunnel may indicate a preference for being contacted using IPv6. A tunnel may indicate a preference for being contacted using IPv6. A
server that wishes to do this can use the lowest SRV priority to server that wishes to do this can use the lowest SRV priority to
publish hostnames that only resolve in IPv6 and the next priority publish hostnames that only resolve in IPv6 and the next priority
with host names that resolve in both address families. with host names that resolve in both address families.
Note that hostnames that have addresses in only one address family Note that hostnames that have addresses in only one address family
are discouraged by [RFC6555]. Such special-purpose hostnames SHOULD are discouraged by [RFC6555]. Such special-purpose hostnames SHOULD
be used only as described in this section, as targets of SRV records be used only as described in this section, as targets of SRV records
for an aggregate host name, where the aggregate host name ultimately for an aggregate host name, where the aggregate host name ultimately
resolves to addresses in all families supported by the client. resolves to addresses in all families supported by the client.
4. Clarification of interaction with RFC 6724 4. Clarification of Interaction with RFC 6724
Section 5 of [RFC6157] specifies that the addresses from the address Section 5 of [RFC6157] specifies that the addresses from the address
records for a single target DNS name for a server's DNS name must be records for a single target DNS name for a server's DNS name must be
contacted in the order specified by the source and destination contacted in the order specified by the source and destination
address selection algorithms defined in [RFC6724] (the successor of address selection algorithms defined in [RFC6724]. The set of
[RFC3484]). The set of addresses provided to a single invocation of addresses provided to a single invocation of the destination address
the destination address selection algorithm MUST be the address selection algorithm MUST be the address records for the target DNS
records for the target DNS name in a single SRV record (or, if there name in a single SRV record (or, if there are no SRV records, the DNS
are no SRV records, the DNS name in the URI or derived via NAPTR) -- name in the URI or derived via NAPTR) -- the destination address
the destination address selection algorithm MUST NOT reorder selection algorithm MUST NOT reorder addresses derived from different
addresses derived from different SRV records. Typically, desination SRV records. Typically, desination address selection is done by
address selection is done by using the (relatively new) getaddrinfo() using the (relatively new) getaddrinfo() function to translate the
function to translate the target DNS name into a list of IPv4 and/or target DNS name into a list of IPv4 and/or IPv6 addresses in the
IPv6 addresses in the order in which they are to be contacted, as order in which they are to be contacted, as that function implements
that function implements [RFC6724]. [RFC6724].
Thus, if SRV lookup on the server's DNS name is successful, the major Thus, if SRV lookup on the server's DNS name is successful, the major
ordering of the complete list of destination addresses is determined ordering of the complete list of destination addresses is determined
by the priority and weight fields of the SRV records (as specified in by the priority and weight fields of the SRV records (as specified in
[RFC2782]) and the (minor) ordering among the destinations derived [RFC2782]) and the (minor) ordering among the destinations derived
from the "target" field of a single SRV record is determined by from the "target" field of a single SRV record is determined by
[RFC6724]. [RFC6724].
For example, consider a server with DNS name example.com, with TCP For example, consider a server with DNS name example.com, with TCP
transport specified. The relevant SRV records are: transport specified. The relevant SRV records for example.com are:
_sip._tcp.example.com. 300 IN SRV 10 1 5060 sip-1.example.com. _sip._tcp.example.com. 300 IN SRV 10 1 5060 sip-1.example.com.
_sip._tcp.example.com. 300 IN SRV 20 1 5060 sip-2.example.com. _sip._tcp.example.com. 300 IN SRV 20 1 5060 sip-2.example.com.
The processing of [RFC2782] results in this ordered list of target
domain names:
sip-1.example.com
sip-2.example.com
The address records for sip-1.example.com, as ordered by [RFC6724], The address records for sip-1.example.com, as ordered by [RFC6724],
are are
sip-1.example.com. 300 IN AAAA 2001:0db8:58:c02::face sip-1.example.com. 300 IN AAAA 2001:0db8:58:c02::face
sip-1.example.com. 300 IN AAAA 2001:0db8:c:a06::2:cafe sip-1.example.com. 300 IN AAAA 2001:0db8:c:a06::2:cafe
sip-1.example.com. 300 IN AAAA 2001:0db8:44:204::d1ce sip-1.example.com. 300 IN AAAA 2001:0db8:44:204::d1ce
sip-1.example.com. 300 IN A 192.0.2.45 sip-1.example.com. 300 IN A 192.0.2.45
sip-1.example.com. 300 IN A 203.0.113.109 sip-1.example.com. 300 IN A 203.0.113.109
sip-1.example.com. 300 IN A 198.51.100.24 sip-1.example.com. 300 IN A 198.51.100.24
skipping to change at page 8, line 9 skipping to change at page 8, line 38
the SIP Forum IPv6 Working Group. This document is based on a lot of the SIP Forum IPv6 Working Group. This document is based on a lot of
tests and discussions at SIPit events, organized by the SIP Forum. tests and discussions at SIPit events, organized by the SIP Forum.
This document has benefited from the expertise and review feedback of This document has benefited from the expertise and review feedback of
many participants of the IETF DISPATCH and SIPCORE WG mailing lists many participants of the IETF DISPATCH and SIPCORE WG mailing lists
as well as those on the SIP Forum IPv6 Task Group mailing list. The as well as those on the SIP Forum IPv6 Task Group mailing list. The
authors wish to specifically call out the efforts and express their authors wish to specifically call out the efforts and express their
gratitude for the detailed and thoughtful comments and corrections of gratitude for the detailed and thoughtful comments and corrections of
Dan Wing, Brett Tate, Rifaat Shekh-Yusef, Carl Klatsky, Mary Barnes, Dan Wing, Brett Tate, Rifaat Shekh-Yusef, Carl Klatsky, Mary Barnes,
Keith Drage, Cullen Jennings, Simon Perreault, Paul Kyzivat, Adam Keith Drage, Cullen Jennings, Simon Perreault, Paul Kyzivat, Adam
Roach, Richard Barnes, Ben Campbell, and Stefan Winter. Adam Roach Roach, Richard Barnes, Ben Campbell, Stefan Winter, Spencer Dawkins,
devised the example in Section 4. and Suresh Krishnan. Adam Roach devised the example in Section 4.
8. Revision History 8. Revision History
[Note to RFC Editor: Please remove this entire section upon [Note to RFC Editor: Please remove this entire section upon
publication as an RFC.] publication as an RFC.]
8.1. Changes from draft-ietf-sipcore-dns-dual-stack-06 to draft-ietf- 8.1. Changes from draft-ietf-sipcore-dns-dual-stack-07 to draft-ietf-
sipcore-dns-dual-stack-08
Remove the reference to RFC 3484, since that RFC has been superseded,
and the reference was only the statement that 3484 had been
superseded by RFC 6724.
Added explanation why "racing" simultaneous copies of a SIP requests
causes incorrect behavior. Acknowledged Spencer Dawkins for this.
In Section 4, made explcit the ordered list of target domain names
that result from processing the SRV records. Acknowledged Suresh
Krishnan for suggesting this.
Updated the Terminology section to remove the definitions of
"IPv4-only", etc. (which weren't being used) and add a definition of
"dual-stack" that includes all multiple-stack situations.
8.2. Changes from draft-ietf-sipcore-dns-dual-stack-06 to draft-ietf-
sipcore-dns-dual-stack-07 sipcore-dns-dual-stack-07
Update per Ben Campbell's AD evaluation. Update per Ben Campbell's AD evaluation.
Update Vijay Gurbani's affiliation. Update Vijay Gurbani's affiliation.
Update per Stefan Winter's OPS-DIR review. Update per Stefan Winter's OPS-DIR review.
8.2. Changes from draft-ietf-sipcore-dns-dual-stack-05 to draft-ietf- 8.3. Changes from draft-ietf-sipcore-dns-dual-stack-05 to draft-ietf-
sipcore-dns-dual-stack-06 sipcore-dns-dual-stack-06
Acknowledged Adam Roach for providing the example in Section 4. Acknowledged Adam Roach for providing the example in Section 4.
Correct references to [RFC6157] vs. references to [RFC6724]. Correct references to [RFC6157] vs. references to [RFC6724].
8.3. Changes from draft-ietf-sipcore-dns-dual-stack-04 to draft-ietf- 8.4. Changes from draft-ietf-sipcore-dns-dual-stack-04 to draft-ietf-
sipcore-dns-dual-stack-05 sipcore-dns-dual-stack-05
Simplified the acknowledgments. Simplified the acknowledgments.
Improve wording and punctuation. Improve wording and punctuation.
Rewrote Section 4 based on critiques on the Sipcore list. Included Rewrote Section 4 based on critiques on the Sipcore list. Included
an example by Adam Roach. an example by Adam Roach.
Replaced "RR's" with "records" per suggestion by Jean Mahoney. Replaced "RR's" with "records" per suggestion by Jean Mahoney.
8.4. Changes from draft-ietf-sipcore-dns-dual-stack-03 to draft-ietf- 8.5. Changes from draft-ietf-sipcore-dns-dual-stack-03 to draft-ietf-
sipcore-dns-dual-stack-04 sipcore-dns-dual-stack-04
Changed the "updates" specification to add RFC 3263 and remove RFC Changed the "updates" specification to add RFC 3263 and remove RFC
6157. 6157.
Added Simon Perreault to the acknowledgments. Added Simon Perreault to the acknowledgments.
Minor wording changes. Minor wording changes.
8.5. Changes from draft-ietf-sipcore-dns-dual-stack-02 to draft-ietf- 8.6. Changes from draft-ietf-sipcore-dns-dual-stack-02 to draft-ietf-
sipcore-dns-dual-stack-03 sipcore-dns-dual-stack-03
Described the relationship to RFC 3263 as "update", since the Described the relationship to RFC 3263 as "update", since the
existing wording in 3263 is not what we want. Arguably, the new existing wording in 3263 is not what we want. Arguably, the new
wording is what was intended in 3263, but the existing wording either wording is what was intended in 3263, but the existing wording either
does not say that or says it in a way that is easily misunderstood. does not say that or says it in a way that is easily misunderstood.
Described the relationship to RFC 6157 as "clarification", since the Described the relationship to RFC 6157 as "clarification", since the
described interaction between 3263 and 6157 appears to be the only described interaction between 3263 and 6157 appears to be the only
reasonable interpretation. reasonable interpretation.
skipping to change at page 10, line 39 skipping to change at page 11, line 33
<http://www.rfc-editor.org/info/rfc6724>. <http://www.rfc-editor.org/info/rfc6724>.
9.2. Informative References 9.2. Informative References
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002, DOI 10.17487/RFC3261, June 2002,
<http://www.rfc-editor.org/info/rfc3261>. <http://www.rfc-editor.org/info/rfc3261>.
[RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484,
DOI 10.17487/RFC3484, February 2003,
<http://www.rfc-editor.org/info/rfc3484>.
[RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with
Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April
2012, <http://www.rfc-editor.org/info/rfc6555>. 2012, <http://www.rfc-editor.org/info/rfc6555>.
Authors' Addresses Authors' Addresses
Olle E. Johansson Olle E. Johansson
Edvina AB Edvina AB
Runbovaegen 10 Runbovaegen 10
Sollentuna SE-192 48 Sollentuna SE-192 48
 End of changes. 23 change blocks. 
73 lines changed or deleted 108 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/