SIPPING Working Group G. Camarillo Internet-Draft Ericsson Updates: 3264 (if approved) K. El Malki Expires: December 14, 2006 Athonet V. Gurbani, Ed. Lucent Technologies, Inc./Bell Laboratories June 12, 2006 IPv6 Transition in the Session Initiation Protocol (SIP) draft-ietf-sipping-v6-transition-03.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 14, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract 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 Camarillo, et al. Expires December 14, 2006 [Page 1] Internet-Draft IPv6 Transition in SIP June 2006 (i.e., an IPv4-only and an IPv4/IPv6) user agents are considered in this document. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. The Signaling Layer . . . . . . . . . . . . . . . . . . . . . 4 3.1 Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . 4 3.1.1 Relaying Requests Across Different Networks . . . . . 5 3.2 UA Behavior . . . . . . . . . . . . . . . . . . . . . . . 8 4. The Media Layer . . . . . . . . . . . . . . . . . . . . . . . 9 4.1 Updates to RFC3264 . . . . . . . . . . . . . . . . . . . . 10 4.2 Initial Offer . . . . . . . . . . . . . . . . . . . . . . 10 4.3 Connectivity Checks . . . . . . . . . . . . . . . . . . . 11 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8.1 Normative References . . . . . . . . . . . . . . . . . . . 12 8.2 Informational References . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13 A. Sample IPv4/IPv6 DNS File . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . 15 Camarillo, et al. Expires December 14, 2006 [Page 2] Internet-Draft IPv6 Transition in SIP June 2006 1. Introduction SIP [3] is a protocol to establish and manage multimedia sessions. After the exchange of signaling messages, SIP endpoints generally exchange session, or media traffic, which is not transported using SIP but a different protocol. For example, audio streams are typically carried using Real-Time Transport Protocol (RTP [16]). Consequently, a complete solution for IPv6 transition needs to handle both the signaling layer and the media layer. While unextended SIP can handle heterogeneous IPv6/IPv4 networks at the signaling layer as long as proxy servers and their Domain Name Service (DNS) entries are properly configured, user agents using different networks and address spaces must implement extensions in order to exchange media between them. This document addresses the systems-level issues to make SIP work successfully between IPv4 and IPv6. Section 3 and Section 4 provide discussions on the topics that are pertinent to the signaling layer and media layer, respectively, to establish a successful session between heterogeneous IPv4/IPv6 networks. 2. Terminology In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [1] and indicate requirement levels for compliant implementations. IPv4-only user agent: An IPv4-only user agent supports SIP signaling and media only on the IPv4 network. It does not understand IPv6 addresses. IPv4-only node: A host that implements only IPv4. An IPv4-only node does not understand IPv6. The installed base of IPv4 hosts existing before the transition begins are IPv4-only nodes. IPv6-only user agent: An IPv6-only user agent supports SIP signaling and media only on the IPv6 network. It does not understand IPv4 addresses. IPv6-only node: A host that implements IPv6 and does not implement IPv4. IPv4/IPv6 node: A host that implements both IPv4 and IPv6; such hosts are also known as "dual-stack" hosts. Camarillo, et al. Expires December 14, 2006 [Page 3] Internet-Draft IPv6 Transition in SIP June 2006 IPv4/IPv6 user agent: An user agent that supports SIP signaling and media on both IPv4 and IPv6 networks. IPv4/IPv6 proxy: A proxy that supports SIP signaling on both IPv4 and IPv6 networks. 3. The Signaling Layer An autonomous domain sends and receives SIP traffic to and from its user agents as well as to and from other autonomous domains. This section describes the issues related to such traffic exchanges at the signaling layer; i.e., the flow of SIP messages between participants in order to establish the session. We assume that the network administrators appropriately configure their networks such that the SIP servers within an autonomous domain can communicate between themselves. While this section contains systems-level issues, it does not address implementation-specific issues (i.e., parser torture tests). Such topics are outlined in detail in a separate document [20]. 3.1 Proxy Behavior User agents typically send SIP traffic to an outbound proxy, which takes care of routing it forward. In order to support both IPv4-only and IPv6-only user agents, it is RECOMMENDED that domains deploy dual-stack outbound proxy servers or, alternatively, deploy both IPv4-only and IPv6-only outbound proxies. Furthermore, there SHOULD exist both IPv6 and IPv4 DNS entries for outbound proxy servers. This allows the user agent to query DNS and obtain an IP address most appropriate for its use (i.e., an IPv4-only user agent will query DNS for A resource records (RR), an IPv6-only user agent will query DNS for AAAA RRs, and a dual-stack user agent will query DNS for all RRs and choose a specific network.) Some domains provide automatic means for user agents to discover their proxy servers. It is RECOMMENDED that domains implement appropriate discovery mechanisms to provide user agents with the IPv4 and IPv6 addresses of their outbound proxy servers. For example, a domain may support both the DHCPv4 [14] and the DHCPv6 [13] options for SIP servers. On the receiving side, user agents inside an autonomous domain receive SIP traffic from sources external to their domain through an inbound proxy (which is sometimes co-located with the registrar of the domain). As was the case previously, it is RECOMMENDED that domains deploy dual-stack inbound proxies or, alternatively, deploy both IPv4-only and IPv6-only inbound proxy servers. This allows the user agents external to the autonomous domain to query DNS and Camarillo, et al. Expires December 14, 2006 [Page 4] Internet-Draft IPv6 Transition in SIP June 2006 receive an IP address of the inbound proxy most appropriate for its use (i.e., an IPv4-only user agent will query DNS for A RRs, an IPv6- only user agent will query DNS for AAAA RRs, and a dual-stack user agent will query DNS for all RRs and choose a specific network.) SIP uses DNS procedures to allow a proxy to resolve a SIP URI into the equivalent IP address, port, and transport protocol of the next hop to contact lookups [8]. When an IPv4/IPv6 proxy queries the DNS, it gets an ordered set of IP addresses, ports, and transports to use. If the server it is seeking is also dual-stacked, and has a DNS A and AAAA RR, then the proxy must be prepared to contact the downstream server on all the transports over both of the networks (i.e., IPv4 and IPv6). More specifically, when an IPv4/IPv6 proxy is prepared to send a request to an IPv4/IPv6 next hop server, it must determine whether to first send it to the IPv4 address of the server, or to the IPv6 address. A technique to aid in this decision is outlined in RFC 3484 [18]. If SRV RR's have been used to derive the addresses of the server, the "Priority" field of the SRV RR can also aid in such a decision; however, the technique in RFC 3484 has precedence. SRV priority levels MUST be used in addition to, but MUST NOT be used as a replacement for RFC 3484. 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. Appendix A contains a sample DNS zone file entry that has been populated with both IPv4 and IPv6 addresses. 3.1.1 Relaying Requests Across Different Networks A SIP proxy server that receives a request using IPv6 and relays it to a user agent (or another downstream proxy) using IPv4, and vice versa, needs to remain in the path traversed by subsequent requests. Therefore, such a SIP proxy server MUST be configured to Record-Route in that situation. Note that while this is the recommended practice, some problems may still arise if a RFC2543 [17] endpoint is involved in signaling. Since the ABNF in RFC2543 did not include production rules to parse IPv6 network identifiers, there is a good chance that a RFC2543-only compliant endpoint is not able to parse or regenerate IPv6 network identifiers in headers. Thus, despite a dual-stack proxy inserting itself into the session establishment, the endpoint itself may not succeed in the signaling establishment phase. This is generally not a problem with RFC3261 endpoints; even if such an endpoint runs on an IPv4-only node, it still is able to parse and regenerate IPv6 network identifiers. Camarillo, et al. Expires December 14, 2006 [Page 5] Internet-Draft IPv6 Transition in SIP June 2006 Relaying a request across different networks in this manner has other ramifications. For one, the proxy doing the relaying must remain in the signaling path for the duration of the session since without it, the upstream client and the downstream server would not be able to communicate directly. Second, to remain in the signaling path, the proxy MUST insert one or two Record-Route headers. If the proxy is inserting a URI that contains a fully qualified domain name of the proxy, then inserting one Record-Route header suffices; but if the proxy is inserting raw IP addresses in the Record-Route header, then it must insert two such headers. The first Record-Route header will contain the proxy's IP address that is compatible with the network type of the downstream server and the second Record-Route header will contain the proxy's IP address that is compatible with the upstream client. An example helps illustrate this behavior. In the example, we use only those headers pertinent to the discussion. Other headers have been omitted for brevity. In addition, only the INVITE request and final response (200 OK) are shown; it is not the intent of the example to provide a complete call flow that includes provisional responses and other requests. In this example, proxy P, responsible for the domain example.com, receives a request from an IPv4-only upstream client. It proxies this request to an IPv6-only downstream server. Proxy P is running on a dual-stack host; on the IPv4 interface, it has an address of 192.0.2.1 and on the IPv6 interface, it sports an address of 2001:db8::1. Camarillo, et al. Expires December 14, 2006 [Page 6] Internet-Draft IPv6 Transition in SIP June 2006 UAC Proxy UAS | P | | | | +-----F1------------>| | | +------F2------------>| | | | | |<-----F3-------------+ |<----F4-------------+ | ... ... ... | | | V V V F1: INVITE sip:alice@example.com SIP/2.0 ... F2: INVITE sip:alice@2001:db8::10 SIP/2.0 Record-Route: Record-Route: ... F3: SIP/2.0 200 OK Record-Route: Record-Route: ... F4: SIP/2.0 200 OK Record-Route: Record-Route: ... When the UAS gets an INVITE and it accepts the invitation, it will send a 200 OK (F3) and form a route set. It's route set will include, as the first destination, the proxy's IPv6 interface. Similarly, when the 200 OK reaches the UAC, it creates a route set by following the guidelines of RFC3261 and reversing the Record-Route headers. Its route set will include, as the first destination, the proxy's IPv4 interface. In this manner, both the UAC and the UAS will have the correct address of the proxy to which they can target subsequent requests. Strictly speaking, the proxy could have inserted its FQDN in the Record-Route URI and the result would have been the same. This is because the proxy has both IPv4 and IPv6 addresses in the DNS; thus the URI resolution would have yielded an IPv4 address to the UAC and an IPv6 address to the UAS. Camarillo, et al. Expires December 14, 2006 [Page 7] Internet-Draft IPv6 Transition in SIP June 2006 3.2 UA Behavior SIP uses DNS procedures to allow a client to resolve a SIP URI into the equivalent IP address, port, and transport protocol of the next hop to contact lookups [8]. When an IPv4/IPv6 user agent queries the DNS, it gets an ordered set of IP addresses, ports, and transports to use. If the server it is seeking is also dual-stacked and has a DNS A and AAAA RR, then the client will need to be prepared to contact the server on all the transports over both of the networks (i.e., IPv4 and IPv6). More specifically, when an IPv4/IPv6 user agent is prepared to send a request to an IPv4/IPv6 next hop server, it must determine whether to first send it to the IPv4 address of the server, or to the IPv6 address. A technique to aid in this decision is outlined in RFC 3484 [18]. If SRV RR's have been used to derive the addresses of the server, the "Priority" field of the SRV RR can also aid in such a decision; however, the technique in RFC 3484 has precedence. SRV priority levels MUST be used in addition to, but MUST NOT be used as a replacement for RFC 3484. Regardless of which network is tried first, each search corresponds to a different branch, and as such, mandates that the normative behavior in RFC3261 to handle requests sent on a branch be followed. When a request is to be sent on a branch, certain identifiers are computed. Specifically, a branch ID is computed and inserted in the topmost Via header, and certain headers are used to generate signatures for Identity [21] and Authenticated Identity Body (AIB [19]). The headers that are used to generate signatures can contain either raw IP addresses or FQDNs; consequently, an implementation may choose to insert a raw IP address in such headers. This choice has ramifications, as discussed next. When a request is re-targeted to a new branch because the old one did not elicit a response, and the request is now destined to a new network (i.e., old request went to an IPv4 downstream server while the new one is destined towards an IPv6 downstream server) care must be taken in re-computing the identifiers. More specifically, implementations MUST ensure that, at the very least, the branch id is recomputed. Additionally, if raw IP addresses were used to generate the signatures for the Identity header and AIB, these signatures MUST be recomputed. To avoid recomputing the signatures used in the Identity header or the AIB, it is RECOMMENDED that SIP user agents use FQDNs in those headers that are used as the basis for the Identity header and the AIB. Camarillo, et al. Expires December 14, 2006 [Page 8] Internet-Draft IPv6 Transition in SIP June 2006 4. The Media Layer SIP establishes media sessions using the offer/answer model [4]. One endpoint, the offerer, sends a session description (the offer) to the other endpoint, the answerer. The offer contains all the media parameters needed to exchange media with the offerer: codecs, transport addresses, protocols to transfer media, etc. When the answerer receives an offer, it elaborates an answer and sends it back to the offerer. The answer contains the media parameters that the answerer is willing to use for that particular session. Offer and answer are written using a session description protocol. The most widespread protocol to describe sessions at present is called, aptly enough, the Session Description Protocol (SDP[2]). A direct offer/answer exchange between an IPv4-only user agent and an IPv6-only user agent does not result in the establishment of a session. The IPv6-only user agent wishes to receive media on one or more IPv6 addresses, but the IPv4-only user agent cannot send media to these addresses and generally does not even understand their format. This IP version incompatibility problem would not exist if hosts implementing IPv6 also implemented IPv4, and were configured with both IPv4 and IPv6 addresses. In such a case, a UA would be able to pick a compatible media transport address type to communicate with each other. Consequently, user agents need a means to obtain both IPv4 and IPv6 addresses to receive media and to place them in offers and answers. Note that pragmatism dictates that IPv6 user agents undertake the greater burden in the transition period. Since IPv6 user agents are not widely deployed yet, it seems appropriate that IPv6 user agents obtain IPv4 addresses instead of mandating an upgrade on the installed IPv4 base. Furthermore, IPv6 user agents are expected to be dual-stacked and thus also support IPv4, unlike the larger IPv4- only user agent base that does not or cannot support IPv6. However, there will be deployments where an IPv4/IPv6 node is unable to use both interfaces natively at the same time, and instead, runs as an IPv6-only node. Examples of such deployments include: 1. Networks where public IPv4 addresses are scarce and it is preferable to make large deployments only on IPv6. 2. Networks utilizing Layer-2s that do not support contemporary IPv4 and IPv6 usage on the same link (e.g., the 3rd Generation Partnership Project, 3GPP). Camarillo, et al. Expires December 14, 2006 [Page 9] Internet-Draft IPv6 Transition in SIP June 2006 In such cases, relays (i.e., TURN) should be used to allow IPv6-only nodes to utilize IPv4 addresses to communicate with IPv4-only nodes. The advantage of this strategy is that the installed base of IPv4 user agents continues to function unchanged, but an operator that introduces IPv6 must provide additional servers to allow IPv6 user agents to obtain IPv4 addresses. This strategy may come at an additional cost to SIP operators deploying IPv6. However, since IPv4-only SIP operators are also likely deploy TURN relays as a NAT- traversal, the additional effort to deploy IPv6 in an IPv4 SIP network should be limited from this aspect. 4.1 Updates to RFC3264 This section provides a normative update to RFC 3264 [4] in the following manner: 1. In some cases, especially those dealing with third party call control (see Section 4.2 of [15]), there arises a need to specify the IPv6 equivalent of the IPv4 unspecified address (0.0.0.0) in the SDP offer. Instead of using the IPv6 unspecified address (i.e., ::), implementations are REQUIRED to use a domain name within the .invalid DNS top level domain. 2. The SDP answer MUST use the same network type as in the offer, i.e., if the "c=" line of the offer contained a network type with the value "IP4", the "c=" line of the answer MUST contain the same network type. Similarly, if the "c=" line of the offer contained a network type with the value "IP6", the "c=" line of the answer MUST contain the same network type as well. 4.2 Initial Offer We now describe how user agents can gather addresses following the ICE (Interactive Connectivity Establishment) [12] procedures and how they can encode them in an SDP session description using the ANAT semantics [7] for the SDP grouping framework [5]. When following the ICE procedures, in addition to local addresses, user agents need to obtain addresses from relays. For example, an IPv6 user agent would obtain an IPv4 address from a relay. The relay would forward the traffic received on this IPv4 address to the user agent using IPv6. Such user agents MAY use any mechanism to obtain addresses in relays, but, following the recommendations in ICE, it is RECOMMENDED that user agents support TURN [10] [11] for this purpose. It is RECOMMENDED that user agents gather IPv4 and IPv6 addresses using the ICE procedures to generate all their offers. This way, both IPv4-only and IPv6-only answerers will be able to generate an Camarillo, et al. Expires December 14, 2006 [Page 10] Internet-Draft IPv6 Transition in SIP June 2006 answer that establishes a session. 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. Having placed both IPv4 and IPv6 addresses in the offer reduces the session establishment time because both all types of answerers find the offer valid. User agents that use SDP SHOULD support the ANAT semantics for the SDP grouping framework. ANAT allows user agents to include both IPv4 and IPv6 addresses in their SDP session descriptions. The SIP usage of the ANAT semantics is discussed in [9]. 4.3 Connectivity Checks Once the answerer has generated an answer following the ICE procedures, both user agents MAY perform the STUN-based [6] connectivity checks specified by ICE. This checks help prevent some types of flooding attacks and allow user agents to discover new addresses that can be useful in the presence of NATs (Network Address Translators). 5. IANA Considerations This document does not contain any actions for the IANA. 6. Security Considerations This document describes how IPv4 SIP user agents can communicate with IPv6 user agents (and vice versa). To do this, it uses additional protocols (TURN, STUN, SDP); the threat model of each such protocol is included in its respective document. This document does not introduce the possibility of any new security threats; however, it may make hosts more amenable to existing threats. Consider, for instance, a UAC that allocates an IPv4 and IPv6 addresses locally and inserts these into the SDP. Malicious user agents that may intercept the request can mount a denial of service attack targeted to the different network interfaces of the UAC. 7. Acknowledgment The authors would like to thank Mohamed Boucadair, Cullen Jennings, Aki Niemi, Jonathan Rosenberg, and Robert Sparks for discussions on the WG list that improved the quality of this document. 8. References Camarillo, et al. Expires December 14, 2006 [Page 11] Internet-Draft IPv6 Transition in SIP June 2006 8.1 Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [2] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998. [3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with the Session Description Protocol (SDP)", RFC 3264, June 2002. [5] Camarillo, G., Holler, J., and H. Schulzrinne, "Grouping of Media Lines in the Session Description Protocol (SDP)", RFC 3388, December 2002. [6] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)", RFC 3489, March 2003. [7] Camarillo, G. and J. Rosenberg, "The Alternative Network Address Types (ANAT) Semantics for the Session Description Protocol (SDP) Grouping Framework", RFC 4091, June 2005. [8] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002. [9] Camarillo, G. and J. Rosenberg, "Usage of the Session Description Protocol (SDP) Alternative Network Address Types (ANAT) Semantics in the Session Initiation Protocol (SIP)", RFC 4092, June 2005. [10] Rosenberg, J., Huitema, C., and R. Mahy, "Traversal Using Relay NAT (TURN)", draft-rosenberg-midcom-turn-08 (work in progress), September 2005. [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), February 2006. [12] 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. Camarillo, et al. Expires December 14, 2006 [Page 12] Internet-Draft IPv6 Transition in SIP June 2006 8.2 Informational References [13] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv6) Options for Session Initiation Protocol (SIP) Servers", RFC 3319, July 2003. [14] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCP- for-IPv4) Option for Session Initiation Protocol (SIP) Servers", RFC 3361, August 2002. [15] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, "Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)", RFC 3725. [16] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 3550, July 2003. [17] Handley, M., Schulzrinne, H., Schooler, E., and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999. [18] Draves, R., "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 3484, Feb 2003. [19] Peterson, J., "Session Initiation Protocol (SIP) Authenticated Identity Body (AIB) Format", RFC 3893, September 2004. [20] Gurbani, V., Boulton, C., and R. Sparks, "Recommendations on the use of IPv6 in the Session Initiation Protocol (SIP)", draft-gurbani-sipping-ipv6-sip-03 (work in progress), May 2006. [21] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", draft-ietf-sip-identity-06 (work in progress), October 2005. Authors' Addresses Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: Gonzalo.Camarillo@ericsson.com Camarillo, et al. Expires December 14, 2006 [Page 13] Internet-Draft IPv6 Transition in SIP June 2006 Karim El Malki Athonet Email: karim@athonet.com Vijay K. Gurbani (editor) Lucent Technologies, Inc./Bell Laboratories 2701 Lucent Lane Rm 9F-546 Lisle, IL 60532 USA Phone: +1 630 224 0216 Email: vkg@lucent.com Appendix A. Sample IPv4/IPv6 DNS File A portion of a sample DNS zone file entry is reproduced below that has both IPv4 and IPv6 addresses. This entry corresponds to a proxy server for the domain "example.com". The proxy server supports the Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) transport for both IPv4 and IPv6 networks. ... _sip._tcp SRV 20 0 5060 sip1.example.com SRV 0 0 5060 sip2.example.com _sip._udp SRV 20 0 5060 sip1.example.com SRV 0 0 5060 sip2.example.com sip1 IN A 192.0.2.1 sip1 IN AAAA 2001:db8::1 sip2 IN A 192.0.2.2 sip2 IN AAAA 2001:db8::2 ... Camarillo, et al. Expires December 14, 2006 [Page 14] Internet-Draft IPv6 Transition in SIP June 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Camarillo, et al. Expires December 14, 2006 [Page 15]