[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Network Working Group                                      Keith Allen
Internet Draft                                            Weijing Chen
Expiration Date: April 2003             SBC Technology Resources, Inc.

                                                          October 2002



                    IPv6 for Large Access Providers
                      draft-allen-lap-ipv6-00.txt

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of [RFC2026].

   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.

Abstract

   This document discusses how Large Access Providers (LAP) could use
   IPv6 to solve current technical challenges.  In particular, IPv6Æs
   large address space and optional header mechanism can be used to
   provide scalable and manageable broadband Internet access and
   Virtual Private Network (VPN) services.  A new optional header to
   support forwarding-plane based VPNs is proposed.


Table of Contents

   1.   Introduction.................................................2
   2.   Large Access Provider Problems...............................2
   3.   IPv6 Solutions...............................................3
   3.1.   IPv6 for Mass Market Broadband Internet Access..............3
   3.1.1.  IPv6 Broadband Access Operation..........................4
   3.1.2.  IPv4 Support.............................................5
   3.1.3.  Advantages of using IPv6 for Broadband Access............5


Allen and Chen            Expire April 2003                  [Page 1]


Internet Draft       draft-allen-LAP-IPv6-00.txt            Oct. 2002


   3.2.   Virtual Private Networking..................................5
   3.2.1.  IPv6 Connectionless VPN Operation........................6
   3.2.2.  Internet Access and VPN Site Discovery Problems..........7
   3.2.3.  VPN Site Discovery Solution..............................7
   3.2.4.  Internet Access Solution.................................8
   3.2.5.  IPv6 Connectionless VPN Advantages.......................9
   4.   VPN Header Details..........................................10
   5.   Security Consideration......................................11
   6.   Conclusion..................................................11
   7.   References..................................................11
   8.   Authors' Addresses..........................................12


1.   Introduction

   Large providers of Internet access are faced with difficult demands
   that could be met by IPv6.  This paper will show how large access
   providers could use IPv6 to meet their service needs and at the same
   time position them to support the evolution to IPv6.  This paper
   will also propose some new capabilities for IPv6 to help meet the
   needs of large access providers.

2.   Large Access Provider Problems

   Two of the hardest problems faced by large and very large access
   providers are:

      1. Providing broadband access to large numbers of subscribers
        while offering them advanced capabilities such as QoS.
      2. Implementing VPNs on a large scale.

   Currently, the industry seems to be turning towards the use of
   connections of one type or another to address these problems, rather
   than applying the datagram principles on which the Internet was
   founded.  Many large access providers, particularly telcos, use ATM
   connections and PPP to provide users with a means to access the
   network.  Some schemes for providing QoS will rely upon additional
   connections such as additional ATM connections and PPP sessions or
   MPLS label switched paths.  The current solutions for VPNs also rely
   upon connections, usually MPLS paths.

   Adding connections to the Internet and trying to maintain them will
   in the end prove to be unduly complicated, increasing operational
   expenditures and slowing new service activations.  Instead, this is
   a good time to take a step back and consider what makes a networking
   technology successful.

   There are two networking technologies that have achieved global
   deployment: telephony (PSTN) and IP.  These two technologies are
   globally successful because they are scalable and manageable.  But


Allen and Chen            Expire April 2003                  [Page 2]


Internet Draft       draft-allen-LAP-IPv6-00.txt            Oct. 2002


   what makes them scalable and manageable?  Both technologies have two
   interesting traits that lend themselves to scalability and
   manageability:

      1. Each subscriber on either network has a globally unique address
        that can be used to route communications to them.
      2. All of the permanent state associated with a subscriber is
        maintained at their connection point with the network.  No
        internal network resources need to be allocated for any
        particular subscriber.

   Basically, the simple idea behind both networks is: get the
   subscriber connected to some interface on the network, give them an
   address, and let them go.  The management of some new feature (such
   as DHCP or Caller ID) requires only the simple configuration of the
   subscriberÆs router or switch interface.  Resources internal to the
   network need to be administered and engineered, but on an aggregate
   basis, not per-subscriber.  Once the administration and engineering
   of resources internal to the network is required for each subscriber
   (e.g. threading a permanent connection through the network, or
   creating virtual routing functions on a set of routers), easy
   manageability goes out the window.

   Just to clarify, the connections being discussed here are
   connections that are dedicated to individual subscribers and
   established and maintained through administrative means by the
   service provider.  This does not include the connections (links or
   trunks) between switches or routers; all networks require these.
   Nor does it include the connections established on-demand through
   signaling in a telephone network.

3. IPv6 Solutions

   So how can IPv6 solve these problems and at the same remain true to
   the InternetÆs connectionless heritage?  The broadband access and
   VPN problems are addressed separately below.

3.1. IPv6 for Mass Market Broadband Internet Access

   The challenge for large access providers in the broadband Internet
   access market is to connect the masses of residential and business
   subscribers on one side of their network with ISPs, Application
   Service Providers, and perhaps enterprise networks on the other side
   of their network.  Traditionally, Layer 2 or Layer 2.5 technologies
   have been employed for this.  IPv6, however, offers a much more
   scalable and manageable alternative.  Consider that the job of a
   large access provider is to get a packet of data from a subscriberÆs
   premises across the providerÆs local network to an ISP or ASP, and
   the reverse for traffic going the other direction.  IPv6 is an ideal


Allen and Chen            Expire April 2003                  [Page 3]


Internet Draft       draft-allen-LAP-IPv6-00.txt            Oct. 2002


   technology for this, especially given its large address space and
   routing header mechanism.

3.1.1.    IPv6 Broadband Access Operation

   HereÆs how access providers can use IPv6 for broadband subscribers.
   Assume for the moment that a broadband Internet access subscriber
   has an IPv6-capable computer (or PDA, Internet appliance, etc.).  As
   this computer boots up it will acquire an IPv6 address (which weÆll
   call its ôcare-ofö address) from the access provider (e.g. DSL or
   cable company) through either stateless [RFC2462] or stateful
   [RFC2131] address autoconfiguration.  It cannot at this point,
   however, reach the public Internet.  It can, though, communicate
   with the subscriberÆs ISP, which is also connected to the same IPv6
   network.  The computer next sends a directed DHCP request to an
   access gateway belonging to the subscriberÆs ISP, requesting an IPv6
   address (which weÆll call its ôhomeö address) from the ISP.  This
   request includes authentication information.  Alternatively, the
   computer can be assigned a static IPv6 address from the ISP.

   The subscriberÆs computer now has two IPv6 addresses: a care-of
   address received from the access provider, and a home address
   received from the ISP.  The home address is going to be the
   computerÆs main address.  Traffic sent from this computer will have
   the home address as the IP source address, and traffic from other
   subscribers will be directed to this home address.  Any traffic sent
   to the home address will be delivered to the ISP gateway from which
   the address was acquired.  That gateway must then forward the
   traffic to the care-of address assigned to the computer.

   To make sure this forwarding occurs, the ISP gateway must associate,
   or ôbind,ö the home address with the care-of address.  This binding
   can be accomplished in two ways.  The first is to borrow the
   ôbinding updateö message from mobile IP.  Using this approach, after
   acquiring both addresses, the subscriberÆs computer would send a
   binding update message to the ISP gateway, binding its home address
   with its care-of address.  The other approach would instead have the
   subscriberÆs computer include the care-of address in the DHCP
   request.  The ISP gateway could then bind the home address with the
   care-of address when the home address is allocated.

   Once the binding is in place, the ISP gateway then uses IPv6Æs
   routing header [RFC2460] capability (rather than IPv6 encapsulation)
   to forward Internet traffic to the subscriber.  The route specified
   by the IPv6 header and this routing header will have two hops. The
   first hop is the care-of address and the second hop is the home
   address.  The care-of address will get the packet to the
   subscriberÆs computer.  The computerÆs internal protocol stack will
   then recognize the home address and process the packet.



Allen and Chen            Expire April 2003                  [Page 4]


Internet Draft       draft-allen-LAP-IPv6-00.txt            Oct. 2002


   The above describes routing traffic from the Internet to the
   subscriber.  Traffic sent from the subscriber to the Internet
   follows the reverse route, also with a two-hop route specified by
   IPv6 header and routing header.  The first hop is the ISP access
   gatewayÆs address and the next hop is the Internet destination
   address.  The routing header is added into each IPv6 packet by the
   protocol stack inside the subscriberÆs computer.  This will ensure
   that all of the subscriberÆs traffic is routed through the ISP.

3.1.2.    IPv4 Support

   IPv6 support for address and routing headers make it well suited for
   broadband access, especially when subscribers natively use IPv6.
   During the transition from IPv4 to IPv6, an IPv4-in-IPv6 tunneling
   approach could be used.  That is, an access node (e.g. modem or home
   gateway) on the subscriberÆs premises could take any IPv4 packets
   from the subscriber, encapsulate them in an IPv6 packet, and forward
   them to the ISP.  IPv6 packets would be transferred by the access
   node without modification.

3.1.3.    Advantages of using IPv6 for Broadband Access

   IPv6 offers many advantages over the Layer 2 and 2.5 technologies
   currently used for broadband Internet access.  One is the simple
   ability for the access provider to ôpingö a subscriberÆs interface.
   Due to IPv6Æs enormous address space and support for address
   autoconfiguration, address management would be fairly simple.
   Finally, it would replace the need to establish connections between
   each subscriber and their ISP with a single, uniform, scalable, and
   manageable IPv6 network.  Not only would these capabilities help to
   simplify operations for service providers, it could also help speed
   the introduction of IPv6 and actually help subscribers by solving
   the problems associated with private addresses and Network Address
   Translation (NAT).

3.2. Virtual Private Networking

   Another problem being faced by large access providers is
   implementing VPNs for large numbers of subscribers.  Most of the
   industryÆs focus is on either Layer 3 VPNs as specified in [RFC2547]
   or Layer 2 VPNs, but IPv6 provides the basis for a connectionless
   approach to VPNs that will likely be more scalable and easier to
   manage than RFC 2547 L3VPNs or L2VPNs.

   First, consider the reasons why subscribers want VPNs:

      1. Security.  Subscribers want to control the traffic that comes
        in across their network interfaces.
      2. Private Addresses.  Subscribers donÆt want to be constrained in
        the assignment of addresses.


Allen and Chen            Expire April 2003                  [Page 5]


Internet Draft       draft-allen-LAP-IPv6-00.txt            Oct. 2002


      3. Ease-of-use.  Subscribers want to offload some of the
        management of their network by buying a VPN instead of
        individual links between sites.
      4. Economics.  Again, subscribers want to buy a VPN instead of
        individual links between sites.
      5. Quality of Service (QoS).  Subscribers want QoS guarantees and
        Service Level Agreements (SLAs).

   Quickly scanning this list reveals that certainly the private
   address issue can be solved with IPv6.  IPv6Æs enormous address
   space will make it possible to give subscribers sizable ranges of
   addresses for them to use.  As for the other needs, typically the
   reason why subscribers buy individual links between sites is
   security.  Security is really the key to VPNs.  If security can be
   maintained, many subscribers will give up the maintenance of
   individual links between sites and turn to VPNs.

   The security approach taken by RFC 2547 is to limit the reachability
   of addresses in VPNs.  This requires building not only many
   connections (and even layered connections) internal to the network,
   but also a rather elaborate control plane consisting of virtual
   routers exchanging routing information.

   Instead of this control plane approach to security, however,
   consider instead a more direct, forwarding plane approach.  Instead
   of limiting reachability, why not simply stop unwanted packets from
   being delivered to VPN subscribers at the network egress?  The key
   to this, of course, is to know which packets subscribers want and
   which they donÆt.  This could be accomplished by securely marking
   each packet as belonging to a particular VPN when that packet enters
   the network.  IPv6Æs optional header mechanism is a perfect means
   for accomplishing this.  We propose, with details below, the
   definition of an IPv6 optional header for VPNs.  The main purpose of
   this optional header is to carry a VPN identifier that marks a
   packet as belonging to a particular VPN.

3.2.1.    IPv6 Connectionless VPN Operation

   Given this proposed capability to label VPN packets in IPv6, an
   access provider would create a VPN for a subscriber by first
   assigning a unique VPN ID to that subscriber.  A unique VPN ID could
   be an IPv6 address prefix under control of the access provider, or a
   number allocated out of a separate space.

   The access provider then enables VPN processing on each interface on
   the Provider Edge (PE) routers serving a site in the VPN.  The VPN
   ID assigned to the subscriber is included with the VPN interface
   configuration.  When the PE receives a packet on a VPN interface, it
   adds the VPN header, containing the VPN ID, into the packet and
   sends it on its way.  Any egress packets on the VPN interface are


Allen and Chen            Expire April 2003                  [Page 6]


Internet Draft       draft-allen-LAP-IPv6-00.txt            Oct. 2002


   first checked to make sure they have the VPN header and that the VPN
   ID inside matches that assigned to the interface.  Any packets that
   do not are discarded. For those that do, the VPN header is stripped
   and the packet is delivered.

   An alternative to this would be for the Customer Edge (CE) equipment
   to add and strip the VPN headers, with the PE gear merely checking
   to make sure the VPN ID is valid.

   The access provider will have to make sure that ALL packets with VPN
   headers entering its network are valid by comparing them with the
   VPN id assigned to the interface.  If the interface does not have
   VPN processing enabled, or if the VPN IDs do not match, the packet
   will either have to be dropped or stripped of its VPN header.

   To enable interworking between different VPNs, it might be necessary
   for PE router interfaces to be configurable with some small number
   of VPN IDs (instead of just one), and to allow packets with any VPN
   ID on the list to pass.  Also, it might be necessary to either turn
   off the VPN rejection mechanism or to have a fairly large number of
   VPN IDs on peering points between access providers.  Turning off the
   capability would mean the access providers entering into the peering
   relationship would have to trust each other, but trust is also
   required for VPN route exchanges in the RFC 2547 approach.

3.2.2.    Internet Access and VPN Site Discovery Problems

   Two key issues, VPN Internet access and VPN site neighborhood
   discovery, must be solved to make this approach feasible.
   Fortunately IPv6 routing header and multicast address capabilities
   are well suited to solve these problems.

   The VPN header mechanism proposed above will keep traffic inside a
   VPN from getting outside the VPN, and traffic outside the VPN from
   getting inside it.  Users on VPNs, however, often need to access
   sites that are not part of their VPN.  Also, routers at each VPN
   site need to know how to route traffic to other VPN sites.  The
   following sections describe how this can be implemented.

3.2.3.    VPN Site Discovery Solution

   Often a VPN subscriber will have many sites, so the CE routers at
   these different sites will need a means to discover each other and
   to discover how to route packets among themselves.  Before
   describing this, however, some terms must be defined.

   In addition to assigning a VPN ID to each VPN, the VPN subscriber
   will also be assigned an IPv6 address range to use as they choose.
   Addresses in this range will be referred to as ôhomeö addresses.
   The interfaces connecting the CE routers to the service providerÆs


Allen and Chen            Expire April 2003                  [Page 7]


Internet Draft       draft-allen-LAP-IPv6-00.txt            Oct. 2002


   network are also assigned IPv6 addresses, but these addresses come
   out of the service providerÆs address range, not the subscriberÆs
   address range.  These addresses will be referred to as ôcare ofö
   addresses.

   One final action is required of the service provider when first
   establishing a VPN: the assignment of an IPv6 multicast address for
   each VPN.  A slight modification to the CE routers could then enable
   them to multicast routing protocol discovery packets (e.g. OSPF HELO
   packets) on this multicast address.  This will enable all of the CE
   routers in a VPN to discover each other, and they will all appear to
   be ôone hopö away from each other.

   When the routers discover each other using the multicast address,
   they will be identified by their ôhomeö addresses.  To actually
   communicate directly with another CE, however, a CE will need to
   know its peerÆs ôcare ofö address.  The equivalent of an ARP
   [RFC826] protocol will be needed, but this is straightforward.  Each
   CE can then multicast a modified ARP message to find other CE's
   ôcare ofö address that can be used to reach other CE with a
   particular CE's home address.

   A CE router can then forward an IPv6 packet to another CE router by
   adding a routing header into the packet.  The resulted route
   specified by IPv6 header and this new routing header will have two
   hops.  The first hop is the other CE's care of address and the
   second hop is the original destination address of the packet.

   Note that even if a site not part of the VPN somehow gets added to
   the multicast group, it will still not be able to exchange routing
   information with any routers inside the VPN due to the VPN header
   checking mechanism.

3.2.4.    Internet Access Solution

   Typically traffic to or from a site outside the VPN is passed
   through a firewall to prevent security violations, while traffic
   between sites within the VPN is not.  Forwarding-plane based VPNs
   will work the same way.  A firewall will have a separate interface
   (logical or physical) to the IPv6 service providerÆs network.  The
   PE serving this interface will not be configured with a VPN ID, and
   thus will drop any egress packets on this interface with a VPN ID,
   and drop or strip the VPN header out of any ingress packets that
   have a VPN header.

   In addition to knowing how to route packets to other VPN sites, as
   described in the previous section, each CE router will also need to
   know how to route traffic destined outside the VPN.  Once a default
   route to the Internet through firewall is established at one or more
   of the VPN sites, this information will also get propagated among


Allen and Chen            Expire April 2003                  [Page 8]


Internet Draft       draft-allen-LAP-IPv6-00.txt            Oct. 2002


   the CE routers using their routing protocol.  A CE router at a site
   without a firewall will then automatically learn to route Internet-
   bound traffic securely to a VPN site equipped with a firewall.  To
   actually forward the traffic it will add a routing header just as it
   did for other inter-site traffic.  After arriving at the remote site
   the traffic will then pass through the firewall and out to the
   Internet.  Return traffic will follow the reverse route, assuming
   the subscriber has correctly advertised the route to the network
   service provider using BGP.

   Provided with the ability to automatically discover all the CE
   routers in a VPN, and to forward packets between them, CE routers
   can then implement the necessary routing functions to enable VPN
   users to securely communicate with each other, and to also access
   other sites through a firewall.

3.2.5.    IPv6 Connectionless VPN Advantages

   This forwarding plane based approach to implementing VPNs has many
   advantages.

   Service provider simplicity.  This forwarding plane approach to VPNs
   aligns with the traits that keep networks scalable and manageable:
   service state is maintained at the subscriberÆs interface.  Internal
   resources do not have to be allocated and maintained for a
   particular subscriber.  Establishing a VPN for a subscriber requires
   only two simple one-time steps: allocating a VPN ID for the
   subscriber, and allocating an IPv6 multicast address for the
   subscriber.  For each site in the VPN, the service provider must
   then of course establish a link to the site.  After that, the
   service provider simply has to configure the PE interface serving
   the site with the VPN ID assigned to the subscriber.

   Subscriber simplicity.  The subscriber can continue to use whatever
   internal routing protocol they want without change.  Configuring a
   CE router takes only two simple steps (in addition to those required
   to set up any other router).  First, the subscriber must configure
   the CE routerÆs WAN interface with the ôcare ofö address assigned by
   the service provider.  Second, the subscriber must also configure
   that interface with the multicast address assigned by the service
   provider.  After that, the router can join the multicast group and
   automatically discover the other sites.

   Compatibility.  This approach also works well for IPv4 VPN and L2VPN
   subscribers.  For IPv4 VPN, IPv4-in-IPv6 tunneling instead of IPv6
   routing headers is used to encapsulate packet.  A CE at a VPN site
   takes any IPv4 packets from the subscriber, encapsulates them in an
   IPv6 packet, and forwards them to the other site.  Encapsulating L2
   (VLAN) frames in IPv6 packets can easily support L2VPNs.  Because


Allen and Chen            Expire April 2003                  [Page 9]


Internet Draft       draft-allen-LAP-IPv6-00.txt            Oct. 2002


   the network connecting the CE routers is a routable IPv6 network,
   spanning tree algorithms can be used for L2VPNs.

   Hardware-based solution.  This VPN security approach relies on
   hardware instead of software.  The packet processors serving all
   interfaces, not just VPN interfaces, will have to do more work to
   validate VPN headers, and even add and strip them.  It does,
   however, relieve routers from having to implement large numbers of
   virtual routers and the software control mechanisms to coordinate
   them.  It also eliminates the need for the large numbers of MPLS
   paths and paths within paths required to support VPNs.  Finally,
   since MooreÆs law continues to hold for hardware but does not apply
   to software, it favors the forwarding plane approach to VPN
   security.

   Reviewing the VPN subscriber needs listed above reveals that IPv6
   could be augmented to meet them all.  The security mechanism
   proposed here can provide the security required by VPN users.  IPv6
   already provides a generous address space.  Given these, the cost
   and hassle of maintaining separate links between sites will no
   longer be necessary for many subscribers.

   The only remaining issue from the list above is QoS.  VPN
   subscribers, though, are not the only users requiring QoS.  QoS is
   being addressed for both IPv4 and IPv6, and connectionless QoS
   mechanisms can still be utilized in a connectionless VPN.

4.   VPN Header Details

   This section provides the details on the proposed VPN ID header for
   IPv6.  The VPN ID header is a specific option of the more generic
   destination options header (header type 60).  It has the following
   format:

      31            24 23           16 15            8 7             0
                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                      |0 1 1|type = ? | length = 9    |   VPN hop     |
      +---------------------------------------------------------------+
      |                                                               |
      |                         VPN ID (8 octets)                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The first three bits of the first octet are 011 and the remaining
   five bits is the Destination Option Type number (to be determined).
   The meaning of first three bits is spelled out in [RFC2460].  The
   values specified here (011) require that nodes not recognizing this
   option type should discard the packet and that the option data (VPN
   hop count) may change en-route.  Discarding the packet is a
   conservative choice meant to ensure that if a packet is somehow
   delivered to a node not capable of processing VPN headers the packet


Allen and Chen            Expire April 2003                 [Page 10]


Internet Draft       draft-allen-LAP-IPv6-00.txt            Oct. 2002


   is dropped rather than possibly delivered to a site outside the VPN.
   VPN hop count is an 8-bit unsigned integer.  It will be incremented
   by 1 by each peering node of a VPN provider that forwards the
   packet. VPN ID is the 64-bit identifier of each VPN.

5.   Security Consideration

   For broadband Internet access service, packet security is neither
   better nor worse than a typical Internet access connection.

   For VPN service, if the PE devices under the control of the access
   provider are properly configured with VPN ID(s), packets will not
   enter a VPN unless authorized to do so.  If the CE devices under the
   control of the VPN subscriber are properly configured with home
   address, care-of address, and multicast address, packets will not
   leave a VPN unless in a manner consistent with the policies of the
   VPN.

6.   Conclusion

   IPv6 is well-suited to provide solutions to problems currently faced
   by large Internet access providers.  ItÆs multicast and routing
   header capabilities can be used for mass market broadband Internet
   access, and the addition of the proposed VPN header will provide a
   forwarding-plane based solution for VPNs.  Using native IPv6 to
   solve these problems will avoid the scalability and manageability
   problems inherent with permanent connection based solutions, while
   positioning service providers to serve customers who are migrating
   to IPv6.

7.   References

   [RFC826] "An Ethernet Address Resolution Protocol", D. Plummer,
   November, 1982.

   [RFC2026] "The Internet Standards Process -- Revision 3", S.
   Bradner, October, 1996.

   [RFC2131] "Dynamic Host Configuration Protocol", R. Droms, March
   1997.

   [RFC2460] "Internet Protocol, Version 6 (IPv6) Specification", S.
   Deering, R. Hinden, December, 1998.

   [RFC2462] "IPv6 Stateless Address Autoconfiguration", S. Thomson, T.
   Narten, December 1998.

   [RFC2547bis] "BGP/MPLS VPNsö, draft-ietf-ppvpn-rfc2547bis-02.txt, E.
   Rosen, Y. Rekhter, etc, July, 2002.



Allen and Chen            Expire April 2003                 [Page 11]


Internet Draft       draft-allen-LAP-IPv6-00.txt            Oct. 2002



8.   Authors' Addresses

   Keith Allen
   SBC Technology Resources, Inc.
   9505 Arboretum Blvd.
   Austin, Texas 78759
   Phone: +1 512 372 5741
   Email: kallen@tri.sbc.com

   Weijing Chen
   SBC Technology Resources, Inc.
   9505 Arboretum Blvd.
   Austin, Texas 78759
   Phone: +1 512 372 5710
   Email: wchen@tri.sbc.com




Allen and Chen            Expire April 2003                 [Page 12]


Html markup produced by rfcmarkup 1.124, available from https://tools.ietf.org/tools/rfcmarkup/