Internet DRAFT - draft-lee-l3vpn-ipv6-vpn
draft-lee-l3vpn-ipv6-vpn
L3VPN Working Group Bin. Lee, Huawei
Internet Draft HF. Chen, Huawei
Expires: April 2006 October 17, 2005
IPv6 VPN Based Address Format
draft-lee-l3vpn-ipv6-vpn-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 April 17, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved.
Abstract
This text introduces a kind of method to carry out VPN based on IPv6
addresses, defines VPN unicast and multicast address structure and
the method to construct VPN topology, and depicts unicast and
multicast routing and forwarding process between VPN sites. Moreover,
this text discusses VPN security.
Lee, Chen Expires April 17, 2006 [Page 1]
Internet-Draft IPv6 VPN based Address Format October 2005
Table of Contents
1. Introduction.................................................2
2. VPN Address..................................................4
2.1. VPN-Local Addresses.....................................4
2.2. Global VPN Addresses....................................5
2.3. Mapping between Global VPN Addresses and VPN-local Addresses
............................................................6
3. Allocating VPN Site ID.......................................7
4. VPN Topology.................................................7
4.1. VPN Topology Discovery Process..........................8
4.2. Establishing Site Route Table...........................9
5. VPN Packet Forward...........................................9
5.1. Forward within the Site.................................9
5.2. Forward on SE at the Ingress...........................10
5.3. Forward in the Public Network..........................10
5.4. Forward on SE at the Egress............................10
6. Internet Access.............................................11
7. Overriding Autonomous System................................11
8. Interconnecting with IPv4 Sites.............................11
9. Security Considerations.....................................13
9.1. Ingress Check..........................................13
9.2. Egress Check...........................................13
10. IANA Considerations........................................13
11. References.................................................14
11.1. Normative References..................................14
11.2. Informative References................................14
Author's Addresses.............................................15
Intellectual Property Statement................................15
Disclaimer of Validity.........................................16
Copyright Statement............................................16
Acknowledgment.................................................16
1. Introduction
This text describes a kind of VPN based on the IPv6 address structure.
The Ipv6 address has been widely used for addressing in the site and
subnet. But it hasn't been used for addressing between sites in VPN
yet. There are enough bits available in IPv6 addresses to allow us to
embed a VPN site ID in the IPv6 address, so that no encapsulation
overhead is required to achieve isolation between VPNs. Meanwhile,
VPN site ID can serve as an aggregation route to a site. Between
sites in the same VPN, routes are reachable. Between sites in
Lee, Chen Expires April 17, 2006 [Page 2]
Internet-Draft IPv6 VPN based Address Format October 2005
different VPNs, routes are unreachable. In this way, VPNs may be
formed in a great variety of topologies.
Addresses used for mutual access in VPN are named VPN addresses.
Their forms differ in VPN from those in Internet, who are named the
VPN-local address and the global VPN address respectively. Compared
with the internal VPN address, the global VPN address increases VPN
site ID and carries out address translation by site edge devices.
The VPN addresses defined in this text do not conflict with the
unique local IPv6 unicast addresses defined in [UNILOCAL]. As a
special local VPN address, the latter is not used for addressing in
the public network, while the global VPN address is used for
addressing in the public network. On site edge devices, unique local
IPv6 unicast addresses can also be translated to global VPN addresses.
For the sake of supporting multicast, assign specific multicast
addresses for VPN. Similar to VPN site ID, site edge devices embed
VPN group ID in VPN multicast addresses.
Routing and forwarding of packets in VPN is the same as that in the
site, and VPN hosts cannot tell the difference between mutual access
in the site and mutual access in VPN. Therefore, the defined unicast
and multicast address formats in VPN are the same as addresses in the
site. Thus, hosts do not need modification. While addressing between
sites or on Internet, the global VPN address is similar to the public
network address of Internet in both format and routing and forwarding
mode. Moreover, Internet addressing can be easily carried out on
devices.
For composing several sites into a VPN, this text defines VPN
topology discovery mechanism.
This kind of VPN has the following features:
1. VPN information is embedded in the IPv6 address, so there is no
additional cost in VPN packets encapsulation.
2. The forward process of VPN packets is consistent with that of the
average IP packets, so VPN traffic can be born on the pure IPv6
network.
3. Use VPN site ID as the valid global site identifier, as the
aggregation route to reach the site and as the basis on which VPN
topology forms. VPN site ID can be identical with global routing
prefix of this site.
Lee, Chen Expires April 17, 2006 [Page 3]
Internet-Draft IPv6 VPN based Address Format October 2005
4. Site edge routes take charge of updating VPN information and
ensuring the security of VPN information.
The reference model of this VPN is shown as follows.
........... .................. ............
. . . . . . .
. VPN1 . +-------+ . . +-------+ . VPN2 .
. Site1 .---| | . .---| SE2 |----. Site2 .
........... | | . Public . +-------+ ............
| SE1 |---. IPv6 .
........... | | . Network . +-------+ ............
. .---| | . .---| SE3 |----. .
. VPN2 . +-------+ . . +-------+ . VPN1 .
. Site1 . . . . Site2 .
........... .................. ............
The device at the boundary between the VPN site and the public
network is named Site Edge router (SE). When SE belongs to operators,
this model becomes PE-based VPN. When SE belongs to clients, this
model becomes CE-based VPN.
2. VPN Address
Two kinds of VPN addresses are defined to carry out VPN addressing
within VPN and on the public network.
2.1. VPN-Local Addresses
The VPN-local address is similar to the link-local address and the
site-local address. It's encapsulated by hosts. Valid only within VPN,
this address can help complete interconnection in VPN.
The unicast address structure is as follows.
| 10 bits | 38 bits | 16 bits | 64 bits |
+----------+-------------------------+------------------------+
|1111111011| reserved | subnet ID| interface ID |
+----------+-------------------------+------------------------+
Lee, Chen Expires April 17, 2006 [Page 4]
Internet-Draft IPv6 VPN based Address Format October 2005
Through using the same type prefix (1111111011) of the site-local
address, the current hosts and routers can use the VPN-local address
without changing.
If sites have used unique local IPv6 unicast addresses that are
defined in [UNILOCAL], they can continue to use it.
Multicast address structure is as follows.
| 8 | 4 | 4 | 80 | 32 |
+--------+----+----+---------------------------------------------+
|11111111|flgs|scop| reserved | group ID |
+--------+----+----+---------------------------------------------+
The flgs field contains four bits.
+-+-+-+-+
|V|R|P|T|
+-+-+-+-+
V bit(the ninth bit)refers to the VPN multicast address. In VPN, it
is set as 0. For details about R bit and P bit, see [ADDR ARCH]. T
bit (the twelfth bit) implies that the multicast address is not
permanent, which is set as 1. The scop field (from the thirteen bit
to the sixteen bit) is set as 0101, which is the same as the valid
multicast address in the site. Thus, the current hosts and routers
can use the VPN-local multicast address without changing.
2.2. Global VPN Addresses
The global VPN address is used for destination addressing in VPN on
the public network. Routers on the public network only consider how
to reach a VPN site and which VPN site to reach, without considering
how to reach the destination within the VPN site.
Global VPN addresses are different from global public network
addresses. Routers must prevent global VPN addresses of different
VPNs from mutual access.
Unicast address structure is as follows:
Lee, Chen Expires April 17, 2006 [Page 5]
Internet-Draft IPv6 VPN based Address Format October 2005
| 3 | 45 bits | 16 bits | 64 bits |
+---+---------------------+-----------+----------------------------+
|010| VPN site ID | subnet ID | interface ID |
+---+---------------------+-----------+----------------------------+
|Global VPN routing prefix|
Global VPN routing prefix contains a prefix 010 and a VPN site ID.
The former is separated from global public network addresses, and the
latter is used for addressing a VPN site in the public network.
Subnet ID and interface ID are only used to save internal VPN unicast
addresses. When addressing in the public network, they are neglected.
Multicast address structure is as follows.
| 8 | 4 | 4 | 48 | 32 | 32 |
+--------+----+----+--------------+--------------+---------------+
|11111111|flgs|scop| reserved | VPN group ID |local group ID |
+--------+----+----+--------------+--------------+---------------+
VPN group ID causes site edge devices (but I'm guessing here - please
let me know if I misunderstood) to transmit multicast packets between
sites of VPN. V bit in flgs field is set as 1, which refers to a VPN
multicast address. The scop field is set as 1110, which refers to a
valid global multicast address. The local group ID is used to save
internal VPN multicast addresses, which can be neglected when
addressing in the public network. Or combining with the VPN group ID,
it can be used for addressing in the public network.
2.3. Mapping between Global VPN Addresses and VPN-local Addresses
Mutual mapping can be carried out between Global VPN unicast
addresses and VPN-local unicast addresses. During the mapping,
interface ID and subnet ID do not change, but different prefixes will
be added and VPN site ID will be deleted or added to global addresses
or local addresses.
Lee, Chen Expires April 17, 2006 [Page 6]
Internet-Draft IPv6 VPN based Address Format October 2005
If unique local IPv6 unicast addresses are used, mutual translation
should be carried out between global ID and VPN site ID and different
prefixes should be added to them during the mapping.
Global VPN multicast addresses generate through the mapping from
local addresses. During the mapping, different flags and scop fields
are set and VPN group IDs are added or deleted for them.
3. Allocating VPN Site ID
When the global routing prefix is assigned to a site, it can be used
as VPN site ID. Global VPN unicast addresses and global unicast
addresses are identical in format but different in prefix. The prefix
of the former is 010, while that of the latter is 001. VPN site ID
corresponds to global routing prefix. Therefore, a site can
distinguish Internet from VPN by using different prefixes while
accessing them.
Independent of global routing prefix, allocating VPN site ID can be
completed, as long as it is the unique one in the global.
4. VPN Topology
<Text for this section>
VPN is composed of multiple sites. VPN topology refers to the
connection between each site. If some sites belong to the same VPN,
their routes are reachable. If not, their routes are unreachable. In
Global VPN addresses, site ID is used to identify sites. Moreover,
through site ID, there are several methods to learn which VPN a site
belongs to.
Method one: Use some fields in VPN site ID to identify VPN, that is,
VPN ID. If some sites belong to the same VPN, they have the same VPN
ID.
The format of VPN site ID is as follows.
| 29 bits | 16 bits |
+-------------------------------------+
| VPN ID | Site ID |
+-------------------------------------+
Lee, Chen Expires April 17, 2006 [Page 7]
Internet-Draft IPv6 VPN based Address Format October 2005
Method two: Append route attributes to VPN site ID so as to express
VPN topology. Route attributes can use the format of BGP extension
community attributes, that is, Route Target (RT) [EXT COMM].
Method three: Through static configuration on SEs to determine
between which sites exists VPN relation.
4.1. VPN Topology Discovery Process
Using the first VPN site ID method:
While initializing, SE sets VPN site ID containing VPN ID. Based on
VPN site ID, SE generates an IPv6 aggregation route, that is, 010:VPN
site ID::/48, which is named the VPN site route. SE advertises it to
backbone router and other SEs. Destination SE matches with VPN ID of
locally configured VPN site ID, based on the information about VPN ID
of VPN site route. If they are identical, this route is installed. If
not, it is dropped. Thus, routes between sites in the same VPN are
reachable, while routes between sites in different VPNs are
unreachable.
Using the second VPN site ID method:
While initializing, SE sets VPN site containing VPN site ID, the
ingress RT list and the egress RT list. Based on such information, SE
generates an IPv6 aggregation route, that is, 010:VPN site ID::/48
and appends RT extension community attribute contained in the egress
RT list. SE advertises it to backbone router and other SEs.
Destination SE matches with the local ingress RT list, based on RTs
of the VPN route. If at least one RT is identical, this route is
installed. If not, it is dropped. Thus, based on RT matching
relationship, a wide variety of VPN topologies can be constructed,
such as, full mesh and hub-spoke as well as Intranet and Extranet.
Using the third VPN site ID method:
While initializing, SE sets the VPN site. SE generates an IPv6
aggregation route, that is, 010:VPN site ID::/48 and advertises it to
backbone router and other SEs. Destination SE judges which VPN it
belongs to and determines to install or drop this route, based on the
locally configured site list.
If using unique local IPv6 unicast addresses, sites need to advertise
the global ID to other SEs accompanies the above processes.
To support multicast in VPN, set VPN group ID on SE when the VPN site
is configured. Then, SE joins to this multicast group specified by
Lee, Chen Expires April 17, 2006 [Page 8]
Internet-Draft IPv6 VPN based Address Format October 2005
VPN group ID through multicast routing protocols. This group is used
to propagate internal VPN multicast packets in the public network,
including each local group. However, if no host joins to a local
group within a site, it's unnecessary that the SE connected to this
site still receives multicast packets from the SE connected to
multicast source. Optimization method is as follows: Through
multicast routing protocols, SE joins to the multicast group
specified by VPN group ID + local group ID. This method aims at some
specific local groups. For example, traffic in this local group is
large, or only a fraction of sites join to this local group.
No matter which method is used, each site has a VPN site list on SE.
The list contains ID of other sites who have VPN relation with the
site. If using unique local IPv6 unicast addresses, each site has an
additional global ID. Thus, a mapping table comes into being between
a VPN site ID and a global ID.
4.2. Establishing Site Route Table
Each site generates a route table on SE. The table contains the route
of this site as well as routes of all sites that have VPN relation
with this site.
Internal routes of a site can be obtained from the internal of sites
through static configuration or routing protocols.
Aggregation routes to other sites can be obtained during topology
discovery, as described in the above section.
Internal routes of other sites can be obtained from routing protocols
between SEs. When SE advertises VPN routes to other sites, it should
specify an attribute for these routes to indicate where they come
from, that is, VPN site ID. If multiple VPN routes are installed on
SE, VPN site ID can be used to distinguish different VPN routes to
ensure the uniqueness of routes. After the destination SE receives
this route, check which local site and this route belong to the same
VPN so that install it to a route table that is related to this site.
5. VPN Packet Forward
5.1. Forward within the Site
When forwarding within the site, both source addresses and
destination addresses use the VPN-local address format without adding
VPN site ID or VPN group ID. Standard unicast or multicast forward
mechanism is also tolerable.
Lee, Chen Expires April 17, 2006 [Page 9]
Internet-Draft IPv6 VPN based Address Format October 2005
5.2. Forward on SE at the Ingress
First of all, use interface or sub interface or packet header to
judge which site the packets come from. After judgment, as for
unicast packets, add site ID, translate source addresses into global
VPN addresses, and search site route tables by destination addresses
for destination site ID. Translate destination addresses into global
VPN addresses and forward to the next hop based on the destination
site ID.
As for multicast packets, add source site ID, translate source
addresses into global VPN addresses, and add VPN group ID based on
VPN of the site. Then translate destination addresses into global VPN
multicast addresses based on VPN group ID, search multicast route
tables and forward them.
5.3. Forward in the Public Network
During VPN topology discovery, an aggregation route to the
destination site is obtained. Therefore, unicast packets use the
standard IPv6 routing and forwarding mechanism to reach SE at the
egress.
Multicast packets search the multicast route table based on VPN group
ID + local group ID in global VPN multicast addresses. If only the
route of VPN group ID exists in the route table, forward packets on
the basis of this aggregation route. If there is the route of VPN
group ID + local group ID, forward packets on the basis of this
precise route. Different from standard multicast forwarding process,
this multicast forwarding process is carried out through longest
matching method similar to unicast forwarding, which is named
multicast longest matching forwarding.
5.4. Forward on SE at the Egress
For unicast packets, locate the local site route table based on VPN
site ID in the destination address, translate source and destination
addresses into the VPN-local address, and search the site route table
and then forward packets into site. In this process, if the unique
local IPv6 unicast address is used, the VPN site ID of the source and
destination address is mapped to corresponding global ID.
For multicast packets, locate the local site based on VPN group ID in
the destination address, translate the source address into the VPN-
local address, and translate the destination address into the VPN-
local multicast address and then forward packets based on the local
group ID.
Lee, Chen Expires April 17, 2006 [Page 10]
Internet-Draft IPv6 VPN based Address Format October 2005
6. Internet Access
VPN sites can access Internet and other sites of VPN at the same time.
In the case of internet access, VPN-local addressed need to be
translated into global Internet addresses.
The format is shown as RFC3587.
| 3 | 45 bits | 16 bits | 64 bits |
+---+---------------------+-----------+----------------------------+
|001|global routing prefix| subnet ID | interface ID |
+---+---------------------+-----------+----------------------------+
The global routing prefix can be identical with VPN site ID.
This translation should be completed by terminals. The global routing
Prefix can be obtained by automatic configuration mechanism defined
in RFC2462 from SE.
Internet cannot access internal VPN multicast addresses.
7. Overriding Autonomous System
VPN uses the standard IPv6 routing and forwarding mechanism while
forwarding packets. Therefore, when overriding Autonomous System (AS),
VPN just needs to advertise VPN site and VPN group routes to the
neighboring AS to ensure routes are reachable between sites of the
same VPN. Then, internal site routes are advertised between SEs of
the same VPN.
8. Interconnecting with IPv4 Sites
This technology is also used to interconnect multiple IPv4 networks
through IPv6 backbone networks or access VPN user who have used IPv4
addresses.
By now, SE still assigns VPN site ID for each IPv4 site and a VPN
group ID for multicast of this site. SE meanwhile maintains an IPv4
route table for this site. But this kind of IPv4 route carries a
route attribute, which contains VPN site ID.
After obtaining the IPv4 route within the site, SE appends a VPN site
ID attribute and advertises it to other SEs. Then destination SE
Lee, Chen Expires April 17, 2006 [Page 11]
Internet-Draft IPv6 VPN based Address Format October 2005
checks whether this site and a local site belong to the same VPN. If
so, this route is installed. If not, it is dropped.
For the unicast packet entering SE, confirm which site it comes from
based on the inbound interface or sub-interface, search this site's
IPv4 route table, find the destination site ID and translate source
and destination IPv4 addresses into VPN IPv4-embedded IPv6 address.
The format is based IPv4-embedded IPv6 address defined by IP Version
6 Addressing Architecture, and add VPN site ID. It's shown as follows.
| 3 | 45 bits | 32 | 16 | 32 bits |
+---+-----------------------------+--------+--------------------------+
|010| VPN site ID |reserved|FFFF| IPv4 address |
+---+-----------------------------+--------+----+---------------------+
Then forward packets based on the destination site ID at this SE and
backbone routers. When packets reach SE at the egress, learn their
destination is an IPv4 site based on VPN site ID. Translate them into
IPv4 addresses and search the IPv4 route table of the site and then
forward packets into site.
For multicast packets entering SE, firstly detect which site they
come from based on the inbound interface or sub-interface, obtain the
VPN group ID of the site, and then translate the source address into
the VPN IPv4-embedded IPv6 address and translate the destination
address into the VPN ipv4-embedded IPv6 multicast address. The format
is shown as follows.
| 8 | 4 | 4 | 48 | 32 | 32 |
+--------+----+----+--------------+--------------+---------------+
|11111111|1RP1|1110| reserved | VPN group ID | IPv4 Group |
+--------+----+----+--------------+--------------+---------------+
Based on this address, forward packets in the backbone network, When
packets reach the egress of SE, learn their destination is an IPv4
site based on the VPN group ID, and translate it into an IPv4
multicast address and then forward packets into site.
Lee, Chen Expires April 17, 2006 [Page 12]
Internet-Draft IPv6 VPN based Address Format October 2005
9. Security Considerations
9.1. Ingress Check
The global VPN source and destination address can only be generated
by SE. Prevent feigned VPN packets from entering the backbone network,
through only receiving those packets whose source and destination
addresses are VPN-local addresses, unique local IPv6 unicast
addresses or global Internet addresses at interfaces connecting VPN
sites on a SE. If source and destination addresses of packets are
unique local IPv6 unicast addresses, check whether the global ID in
the source address is legal. Other interfaces in the SE do not
receive such packets whose source and destination addresses are VPN-
local addresses or unique local IPv6 unicast addresses, nor do
routers in backbone networks.
9.2. Egress Check
At the egress of SE, prevent the ingoing packets from being set
illegal source site ID. Separate VPN site ID from the source address
of VPN packets and check whether it and the site in the VPN
destination address belong to the same VPN. If not, drop this packet.
10. IANA Considerations
The IANA is requested to assigned the 4000::/3 prefix to global VPN
unicast address and add the following note and link it to this
address block.
4000::/3 VPN Global Unicast [IPv6 VPN]
Lee, Chen Expires April 17, 2006 [Page 13]
Internet-Draft IPv6 VPN based Address Format October 2005
11. References
11.1. Normative References
[ADDRARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", Work In Progress.
[RFC 3587] R. Hinden S. Deering and E. Nordmark, "IPv6 Global
Unicast Address Format", RFC3587, August 2003
[UNILOCAL] R. Hinden and B. Haberman, Unique Local IPv6 Unicast
Addresses, Work In Progress.
[RFC 2462] S. Thomson, T. Narten , "IPv6 Stateless Address
Autoconfiguration", RFC2462, December 1998
[RFC 4110] R. Callon, M. Suzuki, "A Framework for Layer 3 Provider-
Provisioned Virtual Private Networks (PPVPNs)", RFC4110,
July 2005
[EXT COMM] Ramachandra, Tappan, Rekhter, "BGP Extended Communities
Attribute", Work In Progress
11.2. Informative References
[BGPv6VPN] Jeremy De Clercq , Dirk Ooms, Marco Carugi and Francois
Le Faucheur , "BGP-MPLS IP VPN extension for IPv6 VPN",
Work In Progress
Lee, Chen Expires April 17, 2006 [Page 14]
Internet-Draft IPv6 VPN based Address Format October 2005
Author's Addresses
Bin Lee
Huawei Technologies
Hua Wei Bld.,No.3 Xinxi Rd.,
Shang-Di Information Industry Base
Hai-Dian District
Beijing P.R.China
Phone: +86 10 82882987
Email: l.b@huawei.com
Hongfei Chen
HUAWEI
Hua Wei Bld.,No.3 Xinxi Rd.,
Shang-Di Information Industry Base
Hai-Dian District
Beijing P.R.China
Phone: +86 10 82882540
Email: chenhongfei@huawei.com
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
Lee, Chen Expires April 17, 2006 [Page 15]
Internet-Draft IPv6 VPN based Address Format October 2005
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.
Lee, Chen Expires April 17, 2006 [Page 16]
