SIPPING WG                                           V. Gurbani (Editor)
Internet-Draft                                  Lucent Technologies/Bell
Expires: January 9, 2006                                    Laboratories
                                                              C. Boulton
                                           Ubiquity Software Corporation
                                                            July 8, 2005


 Recommendations on the use of IPv6 in the Session Initiation Protocol
                                 (SIP)
                 draft-gurbani-sipping-ipv6-sip-00.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 January 9, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   Most operational experience with SIP to date has been over the IPv4
   network; however, SIP implementations that support IPv6 are starting
   to emerge.  IPv6 support in Session Initiation Protocol (SIP) goes
   beyond merely running a SIP stack on a host supporting a dual IP-
   stack (i.e., IPv4/IPv6).  In addition to host-level support for IPv6,



Gurbani (Editor) & Boulton    Expires January 9, 2006           [Page 1]


Internet-Draft                 IPv6 in SIP                     July 2005


   a SIP stack itself must exhibit certain behavior if it is to support
   IPv6.  This document describes such behavior in the form of
   recommendations that SIP implementors can use while constructing
   IPv6-aware SIP clients and servers.

   This work is being discussed on the sipping@ietf.org mailing list.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Background: IPv6 Transition Strategies . . . . . . . . . . . .  3
     2.1   IPv6 Transition Strategies for Nodes . . . . . . . . . . .  4
       2.1.1   IPv4 Client, IPv6 Server . . . . . . . . . . . . . . .  4
       2.1.2   IPv6 Client, IPv4 Server . . . . . . . . . . . . . . .  6
     2.2   IPv6 Transition Strategies for Applications  . . . . . . .  8
   3.  SIP and IPv6 Network Configuration . . . . . . . . . . . . . .  9
   4.  Parser Torture Tests . . . . . . . . . . . . . . . . . . . . . 10
     4.1   Valid SIP request with raw IPv6 addresses  . . . . . . . . 10
     4.2   Invalid IPv6 port  . . . . . . . . . . . . . . . . . . . . 11
     4.3   SIP request with IPv6 prefix . . . . . . . . . . . . . . . 11
     4.4   SIP request with IPv6 identifiers in SDP body  . . . . . . 12
     4.5   More test cases  . . . . . . . . . . . . . . . . . . . . . 12
   5.  DNS Interplay  . . . . . . . . . . . . . . . . . . . . . . . . 12
   6.  Insulating Your Implementation with IPv6 APIs: Source
       Code Examples  . . . . . . . . . . . . . . . . . . . . . . . . 12
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 13
   10.   References . . . . . . . . . . . . . . . . . . . . . . . . . 13
     10.1  Normative References . . . . . . . . . . . . . . . . . . . 13
     10.2  Informative References . . . . . . . . . . . . . . . . . . 13
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14
   A.  Bit-exact archive of each test message . . . . . . . . . . . . 14
     A.1   Encoded Reference Messages . . . . . . . . . . . . . . . . 15
       Intellectual Property and Copyright Statements . . . . . . . . 16
















Gurbani (Editor) & Boulton    Expires January 9, 2006           [Page 2]


Internet-Draft                 IPv6 in SIP                     July 2005


1.  Introduction

   The Session Initiation Protocol (SIP [1]) is protocol to establish,
   maintain, and tear down multimedia sessions.  Most operational
   experience with SIP to date has been over the IPv4 network; however,
   SIP implementations that support IPv6 are starting to emerge.  In
   SIP, IPv6 support needs to be provided not only by the host on which
   a SIP element is executing on, but support is also expected from the
   application (i.e., the SIP element) itself.  For instance, the
   presentation format of an IPv6 address is much different from its
   IPv4 counterpart, and a SIP element must be intelligent enough to
   converse with its upstream or downstream peer using the network that
   the peer supports.  Furthermore, within the SIP application itself,
   support for IPv6 must be provided in signaling header as well as the
   body (the Session Description Protocol (SDP) contains network
   identifiers that will be in IPv6 presentation format).

   In this draft, we provide a set of recommendations that will be of
   use to implementors for ensuring IPv6 support.  These include parser
   torture tests, the interplay between DNS A/AAAA queries and IPv6, and
   related strategies for encouraging the use of network application
   programming interfaces that render the application code agnostic of
   the underlying network.

2.  Background: IPv6 Transition Strategies

   Until IPv6 is deployed pervasively, IPv6 hosts will interoperate and
   co-exist with IPv4 hosts.  To this end, migration strategies have
   been defined for hosts and routers [4] as well as applications [5].
   Before looking at these strategies, we list some terminology first.
   IPv4-only node A host, router or an application that implements and
      understands IPv4 only.
   IPv6-only node A host, router or an application that implements and
      understands IPv6 only.
   IPv4/IPv6 A host, router or an application that is implements and
      understands both IPv4 and IPv6.
   Dual-Stack node See IPv4/IPv6.
   IPv6-native address A network identifier that identifies an IPv6
      endpoint.  The presentation of such an address follows the
      conventions established in section 2.2 of RFC3513 [2] that uses
      colon-separated hexadecimal values.
   IPv4-native address A network identifier that identifies an IPv4
      endpoint.  The presentation of such an address consists of four
      8-bit hexadecimal values separated by a period (the dotted-decimal
      format).






Gurbani (Editor) & Boulton    Expires January 9, 2006           [Page 3]


Internet-Draft                 IPv6 in SIP                     July 2005


   IPv4-mapped IPv6 addresses These addresses allow IPv6 applications on
      dual-stack nodes to communicate with IPv4-only nodes.  These
      addresses are not stored in any DNS data files, instead, they are
      created dynamically by the resolver.  The low order 32-bits
      contain an IPv4 address, preceded by the fixed value of "ffff" in
      the previous 16 bits.  The high order 80 bits are set to zeroes.
      Example ::ffff:192.168.10.1.

2.1  IPv6 Transition Strategies for Nodes

   The most widely used transition strategy is the dual-stack node (or
   IPv4/IPv6) strategy described in Section 2 of [4].  Many, if not all,
   vendors that provide IPv6 support do so while maintaining IPv4
   support in the operating system.  Under this strategy, an IPv4/IPv6
   node have the ability to send and receive both IPv4 and IPv6 packets.
   Such hosts can directly interoperate (at least at the network layer)
   with IPv4 nodes using IPv4 packets and also directly with IPv6 nodes
   using IPv6 packets [4].  While most operating systems come equipped
   with IPv6 support, the default behavior is that IPv6 is dormant and
   only IPv4 is active.  Special configuration is required to make IPv6
   active as well (since this configuration will vary among operating
   systems, we will not cover it in any detail here except to note that
   the Linux 2.6 and above kernel automatically enable IPv6 on the
   interface upon boot-up).

   A general property of a dual-stack node is that an IPv6 server can
   entertain requests from both IPv4 and IPv6 clients, and an IPv6
   client can converse with both an IPv6 and IPv4 server [6] (the cases
   where the network protocol matches between the client and the server
   are straightforward and not discussed further in this document).
   From this general property, it is apparent that IPv6-related APIs are
   a superset of IPv4 ones.  Implementations that judiciously use the
   IPv6 APIs will be able to execute their code in a dual-stack node
   where IPv6 support has been disabled (i.e., the code will run under
   IPv4 semantics).  We will revisit this topic in Section 5.

   Finally, the dual-stack node strategy assumes that the DNS is
   populated with both IPv4 and IPv6 addresses.  Over time, as the
   infrastructure moves to a pure IPv6 deployment, IPv4 addresses can be
   removed from DNS.

2.1.1  IPv4 Client, IPv6 Server

   Figure 1 (abridged from Figure 12.2 in [6]) depicts how an IPv6
   server supports both IPv4 and IPv6 clients.  The ensuing discussion
   in this section and the next is based on Chapter 12 of [6].





Gurbani (Editor) & Boulton    Expires January 9, 2006           [Page 4]


Internet-Draft                 IPv6 in SIP                     July 2005


                                      Dual-stack node
                                      +-----------+
                                      |IPv6 Server|
                IPv6 listening socket +-----------+
                bound to 0::0, port      /\    /\
                9999 (0::0 is the wild-   |     |
                card IPv6 address)        |     |
                                          +-----+
                                          | TCP |
                                       +> +-----+ <+
                                      _|           | _  IPv6 address
                  IPv4-mapped IPv6   /                \
                  address            +------+   +------+
                                     | IPv4 |   | IPv6 |
                                     +------+   +------+
                           192.168.10.1 /\         /\  2001:db8::1/32
                                         |          |
                                         |          |
                                         +----------+
                                         | Datalink |
                                         +-----+----+
                                            :  !  :
     =======================================:==!==:==========
                                            :     :
        +------------------------------+    :     :
        | Enet | IPv4 | TCP | TCP data |    :     :
        | hdr  | hdr  | hdr |          | ...:     :
        +------------------------------+          :
        type           dport                      :
        0800           9999                       :
        IPv4 link-layer packet                    :
        transmitted from an IPv4 client           :
                                                  :
       +--------------------------------+         :
       | Enet | IPv6   | TCP | TCP data |         :
       | hdr  | hdr    | hdr |          | ........:
       +--------------------------------+
       type            dport
       86dd            9999
       IPv6 link-layer packet transmitted from an IPv6 client

   Figure 1: A Dual-Stack Node Hosting a IPv6 Server.

   In Figure 1, an IPv6 server is hosted on a dual-stack node.  The IP
   layer of the node has two addresses, an IPv4 address (192.168.10.1)
   and an IPv6 address (2001:db8::1/32).  An IPv6 server has been
   started on this node, which has created a listening socket and has
   binded itself to the IPv6 wildcard address (0::0) and TCP port 9999.



Gurbani (Editor) & Boulton    Expires January 9, 2006           [Page 5]


Internet-Draft                 IPv6 in SIP                     July 2005


   We can summarize the steps that will allow an IPv4 TCP client to
   communicate with an IPv6 server
   1.  The IPv4 client calls gethostbyname() and finds a DNS A record
       for the server.  Recall that in the dual-stack transition
       strategy, DNS is populated with A and AAAA records.
   2.  The client calls connect() and the client's node sends a TCP SYN
       to the server.
   3.  The server's node receives the IPv4 SYN packet.  The destination
       port in the packet indicates an IPv6 listening socket, thus a
       flag is set to let the server know that this connection is using
       an IPv4-mapped IPv6 address (::ffff:192.168.10.1).  The server
       responds with an IPv4 SYN/ACK.  When the connection is
       established, the address returned to the server by accept() is
       the IPv4-mapped IPv6 address (a server, using the IPv6 sockets
       API [7], can explicitly check whether a given address is an IPv4-
       mapped IPv6 address; but otherwise, it never knows that it is
       communicating with an IPv4 client).
   4.  When the server sends messages to the IPv4-mapped IPv6 address,
       its IP stack generates IPv4 datagrams to the IPv4 address.  All
       communications between the client and server occur over IPv4.

2.1.2  IPv6 Client, IPv4 Server

   We now swap the protocols used by the client and server from the
   example used in the previous section.  Figure 2 shows an IPv4 server
   listening on an IPv4-only node while a IPv6 client sends a connection
   request to it from a dual-stack node.  (NOTE: if a dual-stack node is
   configured to run in IPv6-only mode, will its IP stack still create a
   IPv4-mapped IPv6 address when a connection request is made to an IPv4
   server...?)





















Gurbani (Editor) & Boulton    Expires January 9, 2006           [Page 6]


Internet-Draft                 IPv6 in SIP                     July 2005


                                  IPv4-only node
                                  +-----------+
                                  |IPv4 Server|
            IPv4 listening socket +-----------+
            bound to INADDR_ANY,        /\
            port 9999                   |
                                        |
                                      +-----+
                                      | TCP |
                                      +-----+
                                        /\
                                        |
                                        |
                                      +------+
                                      | IPv4 |
                                      +------+
                       192.168.10.1     /\
                                        |
                                        |
                                   +----------+
                                   | Datalink |
                                   +-----+----+
                                         !  :
   ======================================!==:==========
                                            :
      +------------------------------+      :
      | Enet | IPv4 | TCP | TCP data |      :
      | hdr  | hdr  | hdr |          | .....:
      +------------------------------+
      type           dport
      0800           9999
      IPv4 link-layer packet
      transmitted from an IPv6 client using the
      IPv4-mapped IPv6 address of the server

   Figure 2: An IPv4-only server communicating with an IPv6 client.

   In Figure 2, an IPv4-only node hosts an IPv4 server that has created
   a listening socket and bound itself to the wildcard address and TCP
   port 9999.  We can now summarize the steps that will allow an IPv6
   client to communicate with the IPv4 server.
   1.  The IPv6 client invokes getaddrinfo() (the IPv6 replacement for
       gethostbyname(); see [4]) with the AI_ALL and AI_V4MAPPED bits
       set.  This causes the resolver to return an IPv4- mapped IPv6
       address (since the IPv4 server will not have an IPv6 AAAA
       record).





Gurbani (Editor) & Boulton    Expires January 9, 2006           [Page 7]


Internet-Draft                 IPv6 in SIP                     July 2005


   2.  The IPv6 client calls connect() with the IPv4-mapped IPv6
       address.  The kernel detects the mapped address and automatically
       sends an IPv4 SYN to the server.
   3.  The server responds with an IPv4 SYN/ACK and the connection is
       established.  Datagrams are exchanged over IPv4.

2.2  IPv6 Transition Strategies for Applications

   Besides support for IPv6 in the node, many applications have to be
   updated to support IPv6 as well.  This is true for SIP.  The protocol
   contains network identifiers in many headers and the SDP body.
   Implementations must ensure that such identifiers are parsed and
   understood correctly.  Section 4 will discuss a suite of torture
   tests in this context.

   In this section, we present a discussion on application transition
   scenarios as outlined in [5].  That document classifies the
   transition in four different classifications; of these, only the last
   two -- case 3 and case 4 -- are pertinent to the discussion contained
   in this document.

   The first case -- labeled as case 3 in [5] -- is depicted in Figure
   3:


         +-------------------+
         |     appv4/v6      | (appv4/v6 - applications supporting
         +-------------------+             both IPv4 and IPv6)
         | TCP / UDP / others| (transport protocols - TCP, UDP,
         +-------------------+             SCTP, DCCP, etc.)
         |    IPv4 | IPv6    | (IP protocols supported/enabled in
         +-------------------+             the OS)

   Figure 3: Applications supporting both IPv4 and IPv6 in a dual-stack
   node

   Here, an application has been ported (or written from scratch) to run
   over IPv4 or IPv6.  This transition case is the most advisable [5].
   Some recommendations on writing SIP clients and servers that use this
   strategy will be provided in Section 6.

   The second case -- labeled as case 4 in [5] -- is depicted in Figure
   4:








Gurbani (Editor) & Boulton    Expires January 9, 2006           [Page 8]


Internet-Draft                 IPv6 in SIP                     July 2005


         +-------------------+
         |     appv4/v6      | (appv4/v6 - applications supporting
         +-------------------+             both IPv4 and IPv6)
         | TCP / UDP / others| (transport protocols - TCP, UDP,
         +-------------------+             SCTP, DCCP, etc.)
         |       IPv4        | (IP protocols supported/enabled in
         +-------------------+             the OS)

   Figure 4: Applications supporting both IPv4 and IPv6 in an IPv4-only
   node

   Here, an application has been ported (or written from scratch) to run
   over IPv4 and IPv6, however, the base operating system only supports
   IPv4.  IPv6 protocol may be supported on the operating system, but it
   may not be enabled.  This will be the most commonly deployed scenario
   for SIP systems in the near future.

   It is instructive to consider a specialized case, namely, an
   application is deployed on a legacy system that does not support IPv6
   at all.  The implications of this are that unlike the case where IPv6
   is supported but not enabled, applications will not compile at all on
   a legacy system with no IPv6 support.  Such systems will not have
   IPv6-specific libraries and system include files.  The application
   designer will have to make a conscious decision on how to restructure
   the code so that it can be compiled for a legacy IPv4-only node (for
   instance, using compile-time macros, or by creating a "shim layer"
   that insulates the application from the underlying network
   representation).  We point out such a legacy system for the sake of
   completeness only.  The discussion in this document and the source
   code examples assume that the underlying operating system is a dual-
   stack node, where the worst that can happen is that IPv6 is supported
   but disabled.

3.  SIP and IPv6 Network Configuration

   NOTE: A lot of discussion in this section is system oriented and is
   covered in the draft on IPv6 transition [3].  Options: (1) we could
   take this section out from this draft, (2) maintain a link to [3] and
   move both the drafts in tandem.

   Points to be discussed here include:
      Recommendations from [3] that implementations deploy dual-stack
      outbound proxy servers, or an IPv4-only and IPv6-only outbound
      proxy.
      Ditto for inbound proxy.
      Zero-configuration discovery of outbound proxy servers using
      rfc3319 and rfc3361.




Gurbani (Editor) & Boulton    Expires January 9, 2006           [Page 9]


Internet-Draft                 IPv6 in SIP                     July 2005


      When the networks of the UAC and UAS do not match, a proxy on a
      dual-stack node must intervene by Record-Route'ing.
      Media issues.

4.  Parser Torture Tests

   This section is informational, and is NOT NORMATIVE on any aspect of
   SIP.

   This section contains test messages based on the current version
   (2.0) of SIP as defined in [1].  Some messages exercise SIP's use of
   SDP.

   The test messages are organized into several sections.  Some stress
   only a SIP parser and others stress both the parser and the
   application above it.  Some messages are valid, and some are not.
   Each example clearly calls out what makes any invalid messages
   incorrect.

   This section does not attempt to catalog every way to make an invalid
   message, nor does it attempt to be comprehensive in exploring
   unusual, but valid, messages.  Instead, it catalogues some of the
   most common errors that implementations may exhibit during the
   parsing of IPv6 addresses.

   Please refer to the ABNF in [1] on representing IPv6 addresses in
   SIP.  IPv6 addresses are delimited by a '[' and ']'.

   The appendix contains an encoded binary form of all the messages and
   the algorithm needed to decode them into files.

4.1  Valid SIP request with raw IPv6 addresses

   This REGISTER request is well-formatted per the grammar in [1].  An
   IPv6 address in presentation form appears in the R-URI, Via header,
   and Contact header.

   Message Details: reg-good


    REGISTER sip:[2001:db8::10] SIP/2.0
    To: sip:user@example.com
    From: sip:user@example.com;tag=81x2
    Via: SIP/2.0/UDP [2001:db8::9:1];branch=z9hG4bKas3-111
    Call-ID: SSG9559905523997077@hlau_4100
    Contact: "Caller" <sip:caller@[2001:db8::1]>
    CSeq: 98176 REGISTER
    Content-Length: 0



Gurbani (Editor) & Boulton    Expires January 9, 2006          [Page 10]


Internet-Draft                 IPv6 in SIP                     July 2005


4.2  Invalid IPv6 port

   This REGISTER request contains a port number in the R-URI.  Note the
   placement of the port number: it is placed within the closing ']'
   delimiter.  It should have been placed outside the closing ']'
   delimiter.  SIP elements should reject this request, possibly with a
   "400 Bad Request" response.

   Message Details: reg-bad


    REGISTER sip:[2001:db8::10:5070] SIP/2.0
    To: sip:user@example.com
    From: sip:user@example.com;tag=81x2
    Via: SIP/2.0/UDP [2001:db8::9:1];branch=z9hG4bKas3-111
    Call-ID: SSG9559905523997077@hlau_4100
    Contact: "Caller" <sip:caller@[2001:db8::1]>
    CSeq: 98176 REGISTER
    Content-Length: 0



4.3  SIP request with IPv6 prefix

   This REGISTER request contains an IPv6 address with a prefix.  If the
   prefix occurs, it must be in the enclosing ']'.  This is a valid SIP
   request.
      NOTE: RFC3261 ABNF does not allow for a prefix.  Should we worry
      about prefixes in IPv6 addresses at all?  Should RFC3261 ABNF be
      modified to account for a prefix (see IPv6prefix production rule
      in rfc2373; oddly enough, it is not used anywhere on the RHS in
      that BNF)?

   Message Details: reg-prefix


    REGISTER sip:[2001:db8::10/32] SIP/2.0
    To: sip:user@example.com
    From: sip:user@example.com;tag=81x2
    Via: SIP/2.0/UDP [2001:db8::9:1];branch=z9hG4bKas3-111
    Call-ID: SSG9559905523997077@hlau_4100
    Contact: "Caller" <sip:caller@[2001:db8::1]>
    CSeq: 98176 REGISTER
    Content-Length: 0







Gurbani (Editor) & Boulton    Expires January 9, 2006          [Page 11]


Internet-Draft                 IPv6 in SIP                     July 2005


4.4  SIP request with IPv6 identifiers in SDP body

   This INVITE request is valid and well-formed.  Notice the IPv6
   addresses in the SDP body.

   Message Details: inv-good


    INVITE sip:user@[2001:db8::10] SIP/2.0
    To: sip:user@[2001:db8::10]
    From: sip:user@example.com;tag=81x2
    Via: SIP/2.0/UDP [2001:db8::9:1];branch=z9hG4bKas3-111
    Call-ID: SSG9559905523997077@hlau_4100
    Contact: "Caller" <sip:caller@[2001:db8::1]>
    CSeq: 8612 INVITE
    Content-Type: application/sdp
    Content-Length: 268

    v=0
    o=assistant 971731711378798081 0 IN IP6 2001:db8::20
    s=Live video feed for today's meeting
    c=IN IP6 2001:db8::1
    t=3338481189 3370017201
    m=audio 6000 RTP/AVP 2
    a=rtpmap:2 G726-32/8000
    m=video 6024 RTP/AVP 107
    a=rtpmap:107 H263-1998/90000


4.5  More test cases

   TBD.  Looking for more test cases...suggestions welcome.

5.  DNS Interplay

   TBD

   Points to discuss: Ordering of DNS addresses (rfc3484), rfc3319,
   rfc3361, 6to4 (rfc3056), ...

6.  Insulating Your Implementation with IPv6 APIs: Source  Code Examples

   TBD.

   Things to write here include the use of struct sockaddr_storage to
   insulate the application, creating sockets using AF_INET6, impact of
   these on IPv4 nodes and so on.




Gurbani (Editor) & Boulton    Expires January 9, 2006          [Page 12]


Internet-Draft                 IPv6 in SIP                     July 2005


7.  Security Considerations

   This document does not introduce any new security considerations
   beyond those that are already well known in the SIP community and
   documented in [1].

8.  IANA Considerations

   This draft does not require any IANA considerations.

9.  Acknowledgments

   The authors acknowledge the gracious help provided by Gonzalo
   Camarillo, Bob Gilligan, Larry Kollasch, Erik Nordmark, Robert
   Sparks, ...

   The appendix contains a bit-exact archive of each message following
   the convention established by Robert Sparks.

10.  References

10.1  Normative References

   [1]  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.

   [2]  Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
        Addressing Architecture", RFC 3513, April 2003.

   [3]  Camarillo, G., "IPv6 Transition in the Session Initiation
        Protocol (SIP)", draft-camarillo-sipping-v6-transition-00.txt
        (work in progress), August 2005.

10.2  Informative References

   [4]  Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6
        Hosts and Routers", RFC 2983, August 2000.

   [5]  Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. Castro,
        "Application Aspects of IPv6 Transition", RFC 4038, March 2005.

   [6]  Stevens, W., Fenner, B., and A. Rudoff, "Unix Network
        Programming: The Sockets Networking API, Volume 1, Third
        Edition".

   [7]  Gilligan, R., Thomson, S., Bound, J., McCann, J., and W.
        Stevens, "Basic Socket Extensions for IPv6", RFC 3493,



Gurbani (Editor) & Boulton    Expires January 9, 2006          [Page 13]


Internet-Draft                 IPv6 in SIP                     July 2005


        February 2003.


Authors' Addresses

   Vijay Gurbani (Ed.)
   Lucent Technologies/Bell Laboratories
   2000 Lucent Lane
   Rm 6G-440
   Naperville, IL  60566
   USA

   Phone: +1 630 224 0216
   Email: vkg@lucent.com


   Chris Boulton
   Ubiquity Software Corporation
   Building 3
   West Fawr Lane
   St Mellons
   Cardiff, South Wales  CF3 5EA

   Email: cboulton@ubiquitysoftware.com

Appendix A.  Bit-exact archive of each test message

   The following text block is an encoded, gzip compressed TAR archive
   of files that represent each of the example messages discussed in
   Section 4.

   To recover the compressed archive file intact, the text of this
   document may be passed as input to the following Perl script (the
   output should be redirected to a file or piped to "tar -xzvf -").


   #!/usr/bin/perl
   use strict;
   my $bdata = "";
   use MIME::Base64;
   while(<>) {
     if (/-- BEGIN MESSAGE ARCHIVE --/ .. /-- END MESSAGE ARCHIVE --/) {
           if ( m/^\s*[^\s]+\s*$/) {
               $bdata = $bdata . $_;
           }
      }
   }
   print decode_base64($bdata);



Gurbani (Editor) & Boulton    Expires January 9, 2006          [Page 14]


Internet-Draft                 IPv6 in SIP                     July 2005


   Alternatively, the base-64 encoded block can be edited by hand to
   remove document structure lines and fed as input to any base-64
   decoding utility.

A.1  Encoded Reference Messages


   -- BEGIN MESSAGE ARCHIVE --
   H4sICFSmxUIAA3h4LnRhcgDtV11v2jAU5dm/wurLnmj8kfiry9Sp7RhqNaHC+jJVkyEGo
   kGcJQa1+/VzYBSqivZlabWR8+JY91773uSeYyfNlu2Jtclxol2rJiCMEAvDFkIIc4aqsX
   r8M3prhFoYEYYp5jyq/DAljLdQXQntYlE6Xfgtlz8mz/pZNzXFM/ZVKeGmOP53k6wP3S8
   33cEFLNNcLUpTnH4j/u2rZCiUwugW9ru9gBwjMLBqnw/4VNj5jtXc6Xk+M8cjOz9xehIL
   fEfATarVZrHg63kP7qwhFb49GRY6G03jX3LaCYeXuqRtjDE407NZu3vuQ/sdGUVSoigiV
   EqOOD+dzvTie+h7C5zZzOmRU/CoCjDFEXxfpTNaTR6le/sBnPXNTwUFwwSui1+Fm8y1B/
   e5UVDn+SwdaZfaLCiT/MF6ZbKJmypImABgGSNgY12WqW+fzEHJMffdizHlgkuBBIbILw+
   7PQa32xMEyvgqXRq4TBNj4diYBI5tAZ1N9P27Es6NcWk2AaP4SSwGLqaUilBgLCSklFds
   IgiDeawXSWoh830Hrwe94ONNDxKg48Llc50rAjucsDYlgfAe3n29OUMkfHDHiG8D/AR+J
   sx/AilFIKt+Bm/dpw3qQWEm7aGuVf5f0n8UUrzR/4hHZKX/qPKvLaMdHLj+X190uv3Bxf
   VKvx8Ju4oQ33cC7Gj8vyn/UvhOhJvin2g8AocieBX/3/j+h0ISbvkfrvlPwub+9xrYz/+
   G+oeAiv95YcbpXX0K8DL/+Zb/bP3/xwht+P8K2M//gJJGAho0aNDgv8VvEkuUCwAWAAA=
   -- END MESSAGE ARCHIVE --






























Gurbani (Editor) & Boulton    Expires January 9, 2006          [Page 15]


Internet-Draft                 IPv6 in SIP                     July 2005


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 (2005).  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.




Gurbani (Editor) & Boulton    Expires January 9, 2006          [Page 16]