TOC 
SIPPING WGV. Gurbani (Editor)
Internet-DraftLucent Technologies/Bell
Expires: January 9, 2006Laboratories
 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 © 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, 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
2.  Background: IPv6 Transition Strategies
    2.1  IPv6 Transition Strategies for Nodes
        2.1.1  IPv4 Client, IPv6 Server
        2.1.2  IPv6 Client, IPv4 Server
    2.2  IPv6 Transition Strategies for Applications
3.  SIP and IPv6 Network Configuration
4.  Parser Torture Tests
    4.1  Valid SIP request with raw IPv6 addresses
    4.2  Invalid IPv6 port
    4.3  SIP request with IPv6 prefix
    4.4  SIP request with IPv6 identifiers in SDP body
    4.5  More test cases
5.  DNS Interplay
6.  Insulating Your Implementation with IPv6 APIs: Source Code Examples
7.  Security Considerations
8.  IANA Considerations
9.  Acknowledgments
10.  References
    10.1  Normative References
    10.2  Informative References
§  Authors' Addresses
A.  Bit-exact archive of each test message
    A.1  Encoded Reference Messages
§  Intellectual Property and Copyright Statements




 TOC 

1. Introduction

The Session Initiation Protocol (SIP [1] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.)) 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.



 TOC 

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] (Gilligan, R. and E. Nordmark, “Transition Mechanisms for IPv6 Hosts and Routers,” August 2000.) as well as applications [5] (Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. Castro, “Application Aspects of IPv6 Transition,” March 2005.). 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] (Hinden, R. and S. Deering, “Internet Protocol Version 6 (IPv6) Addressing Architecture,” April 2003.) 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).
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] (Gilligan, R. and E. Nordmark, “Transition Mechanisms for IPv6 Hosts and Routers,” August 2000.). 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] (Gilligan, R. and E. Nordmark, “Transition Mechanisms for IPv6 Hosts and Routers,” August 2000.). 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] (Stevens, W., Fenner, B., and A. Rudoff, “Unix Network Programming: The Sockets Networking API, Volume 1, Third Edition,” .) (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] (Stevens, W., Fenner, B., and A. Rudoff, “Unix Network Programming: The Sockets Networking API, Volume 1, Third Edition,” .)) 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] (Stevens, W., Fenner, B., and A. Rudoff, “Unix Network Programming: The Sockets Networking API, Volume 1, Third Edition,” .).

                                   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. 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] (Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. Stevens, “Basic Socket Extensions for IPv6,” February 2003.), 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...?)

                               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] (Gilligan, R. and E. Nordmark, “Transition Mechanisms for IPv6 Hosts and Routers,” August 2000.)) 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).
  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] (Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. Castro, “Application Aspects of IPv6 Transition,” March 2005.). 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] (Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. Castro, “Application Aspects of IPv6 Transition,” March 2005.) -- 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] (Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. Castro, “Application Aspects of IPv6 Transition,” March 2005.). 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] (Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. Castro, “Application Aspects of IPv6 Transition,” March 2005.) -- is depicted in Figure 4:

      +-------------------+
      |     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.



 TOC 

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] (Camarillo, G., “IPv6 Transition in the Session Initiation Protocol (SIP),” August 2005.). Options: (1) we could take this section out from this draft, (2) maintain a link to [3] (Camarillo, G., “IPv6 Transition in the Session Initiation Protocol (SIP),” August 2005.) and move both the drafts in tandem.

Points to be discussed here include:

  • Recommendations from [3] (Camarillo, G., “IPv6 Transition in the Session Initiation Protocol (SIP),” August 2005.) 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.
  • 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.


  •  TOC 

    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] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.). 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] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) 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] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.). 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
    
    

    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
    
    

    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.



     TOC 

    5. DNS Interplay

    TBD

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



     TOC 

    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.



     TOC 

    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] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.).



     TOC 

    8. IANA Considerations

    This draft does not require any IANA considerations.



     TOC 

    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.



     TOC 

    10. References



     TOC 

    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.


     TOC 

    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, February 2003.


     TOC 

    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


     TOC 

    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);
    
    

    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 --
    



     TOC 

    Intellectual Property Statement

    Disclaimer of Validity

    Copyright Statement

    Acknowledgment