draft-ietf-v6ops-unman-scenarios-02.txt   draft-ietf-v6ops-unman-scenarios-03.txt 
INTERNET DRAFT C. Huitema INTERNET DRAFT C. Huitema
<draft-ietf-v6ops-unman-scenarios-02.txt> Microsoft <draft-ietf-v6ops-unman-scenarios-03.txt> Microsoft
June 16, 2003 R. Austein October 16, 2003 R. Austein
Expires December 16, 2003 Bourgeois Dilettant Expires April 16, 2004 Bourgeois Dilettant
S. Satapati S. Satapati
Cisco Systems, Inc. Cisco Systems, Inc.
R. van der Pol R. van der Pol
NLnet Labs NLnet Labs
Unmanaged Networks IPv6 Transition Scenarios Unmanaged Networks IPv6 Transition Scenarios
Status of this memo Status of this memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
skipping to change at page 10, line ? skipping to change at page 10, line ?
Huitema et al. [Page 3] Huitema et al. [Page 3]
There are really two kinds of "peer-to-peer" applications: ones There are really two kinds of "peer-to-peer" applications: ones
which only involve hosts on the unmanaged network, and ones which which only involve hosts on the unmanaged network, and ones which
involve both one or more hosts on the unmanaged network and one or involve both one or more hosts on the unmanaged network and one or
more hosts outside the unmanaged network. We will only consider the more hosts outside the unmanaged network. We will only consider the
latter kind of peer-to-peer applications, since the former can be latter kind of peer-to-peer applications, since the former can be
considered a subset of the kind of local applications discussed considered a subset of the kind of local applications discussed
in section 3.1. in section 3.1.
Peer-to-peer applications are a restricted subset of "server
applications" (discussed in section 3.4), in which the services are
only meant to be used by well-identified peers outside the unmanaged
network. These applications are often facilitated by a server
outside the unmanaged networks. Examples of peer-to-peer
applications would be a video-conference over IP, facilitated by a
Session Invitation Protocol (SIP) server, or a distributed game
application, facilitated by a "game lobby".
Peer-to-peer applications often don't work well in unmanaged IPv4 Peer-to-peer applications often don't work well in unmanaged IPv4
networks. Application developers often have to enlist the help of a networks. Application developers often have to enlist the help of a
"relay server", in effect restructuring the peer-to-peer connection "relay server", in effect restructuring the peer-to-peer connection
into a pair of back-to-back client/server connections. into a pair of back-to-back client/server connections.
3.4 Server applications 3.4 Server applications
"Server applications" involve running a server in the unmanaged "Server applications" involve running a server in the unmanaged
network for use by other parties outside the network. Typical network for use by other parties outside the network. Typical
examples would be running a web server or an e-mail server on one of examples would be running a web server or an e-mail server on one of
skipping to change at page 10, line ? skipping to change at page 10, line ?
network. On the other hand, it is also possible to use out-of-band network. On the other hand, it is also possible to use out-of-band
techniques (such as cut-and-paste into an instant message system) to techniques (such as cut-and-paste into an instant message system) to
pass around the address of the target server. pass around the address of the target server.
4 Application requirements of an IPv6 unmanaged network 4 Application requirements of an IPv6 unmanaged network
As we transition to IPv6, we must meet the requirements of the As we transition to IPv6, we must meet the requirements of the
various applications, which we can summarize in the following way: various applications, which we can summarize in the following way:
applications that used to work well with IPv4 should continue applications that used to work well with IPv4 should continue
working well during the transition; it should be possible to use working well during the transition; it should be possible to use
Huitema et al. [Page 4]
IPv6 to deploy new applications that are currently hard to deploy in IPv6 to deploy new applications that are currently hard to deploy in
IPv4 networks; and the deployment of these IPv6 applications should IPv4 networks; and the deployment of these IPv6 applications should
be simple and easy to manage, but the solutions should also be be simple and easy to manage, but the solutions should also be
robust and secure. robust and secure.
The application requirements for IPv6 Unmanaged Networks fall into The application requirements for IPv6 Unmanaged Networks fall into
three general categories: connectivity, naming, and security. three general categories: connectivity, naming, and security.
Connectivity issues include the provision of IPv6 addresses and Connectivity issues include the provision of IPv6 addresses and
their quality: do hosts need global addresses, should these their quality: do hosts need global addresses, should these
Huitema et al. [Page 4]
addresses be stable or, more precisely, what should the expected addresses be stable or, more precisely, what should the expected
lifetimes of these addresses be? Naming issues include the lifetimes of these addresses be? Naming issues include the
management of names for the hosts: do hosts need DNS names, and is management of names for the hosts: do hosts need DNS names, and is
inverse name resolution a requirement? Security issues include inverse name resolution a requirement? Security issues include
possible restriction to connectivity, privacy concerns and, possible restriction to connectivity, privacy concerns and,
generally speaking, the security of the applications. generally speaking, the security of the applications.
4.1 Requirements of local applications 4.1 Requirements of local applications
Local applications require local connectivity. They must continue to Local applications require local connectivity. They must continue to
skipping to change at page 10, line ? skipping to change at page 10, line ?
cases, these PTR records are perfunctory, derived in an algorithmic cases, these PTR records are perfunctory, derived in an algorithmic
fashion from the IPv4 address; the main information that they fashion from the IPv4 address; the main information that they
contain is the domain name of the ISP. Whether or not an equivalent contain is the domain name of the ISP. Whether or not an equivalent
function should be provided in an IPv6 network is unclear. function should be provided in an IPv6 network is unclear.
4.2.1 Privacy requirement of client applications 4.2.1 Privacy requirement of client applications
It is debatable whether the IPv6 networking service should be It is debatable whether the IPv6 networking service should be
engineered to enhance the privacy of the clients, and specifically engineered to enhance the privacy of the clients, and specifically
whether support for RFC 3041 should be required. RFC 3041 enables whether support for RFC 3041 should be required. RFC 3041 enables
Huitema et al. [Page 5]
hosts to pick IPv6 addresses in which the host identifier is hosts to pick IPv6 addresses in which the host identifier is
randomized; this was designed to make sure that the IPv6 addresses randomized; this was designed to make sure that the IPv6 addresses
and the host identifier cannot be used to track the Internet and the host identifier cannot be used to track the Internet
connections of a device's owner. connections of a device's owner.
Many observe that randomizing the host identifier portion of the Many observe that randomizing the host identifier portion of the
address is only a half measure. If the unmanaged network address address is only a half measure. If the unmanaged network address
prefix remains constant, the randomization only hides which host in prefix remains constant, the randomization only hides which host in
the unmanaged network originates a given connection, e.g. the the unmanaged network originates a given connection, e.g. the
Huitema et al. [Page 5]
children's computer versus their parents'. This would place the children's computer versus their parents'. This would place the
privacy rating of such connections on a par with that of IPv4 privacy rating of such connections on a par with that of IPv4
connections originating from an unmanaged network in which a NAT connections originating from an unmanaged network in which a NAT
manages a static IPv4 address; in both cases, the IPv4 address or manages a static IPv4 address; in both cases, the IPv4 address or
the IPv6 prefix can be used to identify the unmanaged network, e.g. the IPv6 prefix can be used to identify the unmanaged network, e.g.
the specific home from which the connection originated. the specific home from which the connection originated.
However, randomization of the host identifier does provide benefits. However, randomization of the host identifier does provide benefits.
First, if some of the hosts in the unmanaged network are mobile, the First, if some of the hosts in the unmanaged network are mobile, the
randomization destroys any correlation between the addresses used at randomization destroys any correlation between the addresses used at
skipping to change at page 10, line ? skipping to change at page 10, line ?
it is reasonable to require that all unmanaged networks allow use of it is reasonable to require that all unmanaged networks allow use of
privacy addresses by those hosts that choose to do so. privacy addresses by those hosts that choose to do so.
4.3 Requirements of peer-to-peer applications 4.3 Requirements of peer-to-peer applications
Peer-to-peer applications require global connectivity. In an IPv6 Peer-to-peer applications require global connectivity. In an IPv6
network, we would expect the peers to use a global IPv6 address, network, we would expect the peers to use a global IPv6 address,
which will have to remain stable for the duration of the peer-to- which will have to remain stable for the duration of the peer-to-
peer session. peer session.
Huitema et al. [Page 6]
Peer-to-peer applications often use ad hoc naming systems, sometimes
derived from an "instant messaging" service. (Peer-to-peer
applications that rely on the DNS for name resolution have the same
naming requirements as server applications, which are discussed in
the next section.) Many of these systems are proprietary; an example
of a standard system is the session invitation protocol (SIP)
[RFC3261]. In these systems, the peers register their presence to a
"rendezvous" server, using a name specific to the service; the case
of SIP, they would use a SIP URL, of the form
"sip:user@example.com". A peer-to-peer session typically starts with
an exchange of synchronization messages through the rendezvous
servers, during which the peers exchange the addresses that will be
used for the session.
There are multiple aspects to the security of peer-to-peer There are multiple aspects to the security of peer-to-peer
applications, many of which relate to the security of the rendezvous applications, many of which relate to the security of the rendezvous
system. If we assume that the peers have been able to safely system. If we assume that the peers have been able to safely
exchange their IPv6 addresses, the main security requirement is the exchange their IPv6 addresses, the main security requirement is the
capability to safely exchange data between the peers, without capability to safely exchange data between the peers, without
interference by third parties. interference by third parties.
Private conversations by one of the authors with developers of peer- Private conversations by one of the authors with developers of peer-
Huitema et al. [Page 6]
to-peer applications suggest that many would be willing to consider to-peer applications suggest that many would be willing to consider
an "IPv6-only" model if they can get two guarantees: an "IPv6-only" model if they can get two guarantees:
1) That there is no regression from IPv4, i.e. that all customers 1) That there is no regression from IPv4, i.e. that all customers
who could participate in a peer-to-peer application using IPv4 can who could participate in a peer-to-peer application using IPv4 can
also be reached by IPv6. also be reached by IPv6.
2) That IPv6 provides a solution for at least some of their hard 2) That IPv6 provides a solution for at least some of their hard
problems, e.g. enabling peers located behind an IPv4 NAT to problems, e.g. enabling peers located behind an IPv4 NAT to
participate in a peer-to-peer application. participate in a peer-to-peer application.
skipping to change at page 10, line ? skipping to change at page 10, line ?
NAT, for each service provided by a server, the NAT has to be NAT, for each service provided by a server, the NAT has to be
configured to forward packets sent to that service to the server configured to forward packets sent to that service to the server
that offers the service. that offers the service.
Server applications normally rely on the publication of the server's Server applications normally rely on the publication of the server's
address in the DNS. This, in turn, requires that the server be address in the DNS. This, in turn, requires that the server be
provisioned with a "global DNS name". provisioned with a "global DNS name".
The DNS entries for the server will have to be updated, preferably The DNS entries for the server will have to be updated, preferably
in real time, if the server's address changes. In practice, updating in real time, if the server's address changes. In practice, updating
Huitema et al. [Page 7]
the DNS can be slow, which implies that server applications will the DNS can be slow, which implies that server applications will
have a better chance of being deployed if the IPv6 addresses remain have a better chance of being deployed if the IPv6 addresses remain
stable for a long period. stable for a long period.
The security of server applications depends mostly on the The security of server applications depends mostly on the
correctness of the server, and also on the absence of collateral correctness of the server, and also on the absence of collateral
effects: many incidents occur when the opening of a server on the effects: many incidents occur when the opening of a server on the
Internet inadvertently enables remote access to some other services Internet inadvertently enables remote access to some other services
on the same host. on the same host.
skipping to change at page 10, line ? skipping to change at page 10, line ?
which there is little or no deployment to a final stage in which we which there is little or no deployment to a final stage in which we
might retire the IPv4 infrastructure. We expect this process to might retire the IPv4 infrastructure. We expect this process to
stretch over many years; we also expect it to not be synchronized, stretch over many years; we also expect it to not be synchronized,
as different parties involved will deploy IPv6 at different paces. as different parties involved will deploy IPv6 at different paces.
In order to get some clarity, we distinguish three entities involved In order to get some clarity, we distinguish three entities involved
in the transition of an unmanaged network: the ISP (possibly in the transition of an unmanaged network: the ISP (possibly
including ISP consumer premise equipment (CPE)), the home gateway, including ISP consumer premise equipment (CPE)), the home gateway,
and the hosts (computers and appliances). Each can support IPv4- and the hosts (computers and appliances). Each can support IPv4-
only, both IPv4 and IPv6 or IPv6-only. That gives us 27 only, both IPv4 and IPv6 or IPv6-only. That gives us 27
Huitema et al. [Page 7]
possibilities. We describe the most important cases. We will assume possibilities. We describe the most important cases. We will assume
that in all cases the hosts are a combination of IPv4-only, dual that in all cases the hosts are a combination of IPv4-only, dual
stack and (perhaps) IPv6-only hosts. stack and (perhaps) IPv6-only hosts.
The cases we will consider are: The cases we will consider are:
A) a gateway which does not provide IPv6 at all; A) a gateway which does not provide IPv6 at all;
B) a dual-stack gateway connected to a dual stack ISP; B) a dual-stack gateway connected to a dual stack ISP;
C) a dual stack gateway connected to an IPV4-only ISP; and C) a dual stack gateway connected to an IPV4-only ISP; and
D) a gateway connected to an IPv6-only ISP D) a gateway connected to an IPv6-only ISP
skipping to change at page 10, line ? skipping to change at page 10, line ?
The cases of directly connected hosts are in effect variants of The cases of directly connected hosts are in effect variants of
cases B, C and D, in which the host can use all solutions available cases B, C and D, in which the host can use all solutions available
to gateways: case B if the ISP is dual stack, case C if the ISP only to gateways: case B if the ISP is dual stack, case C if the ISP only
provides IPv4 connectivity, and case D if the ISP only provides IPv6 provides IPv4 connectivity, and case D if the ISP only provides IPv6
connectivity. connectivity.
In the cases where the gateway is a bridge, the hosts are in effect In the cases where the gateway is a bridge, the hosts are in effect
directly connected to the ISP, and for all practical matter behave directly connected to the ISP, and for all practical matter behave
as directly connected hosts. as directly connected hosts.
Huitema et al. [Page 8]
The case where the gateway is an IP router but not a NAT will be The case where the gateway is an IP router but not a NAT will be
treated as small variants in the analysis of case A, B, C and D. treated as small variants in the analysis of case A, B, C and D.
5.1 Case A, host deployment of IPv6 applications 5.1 Case A, host deployment of IPv6 applications
In this case the gateway doesn't provide IPv6; the ISP may or may In this case the gateway doesn't provide IPv6; the ISP may or may
not provide IPv6, but this is not relevant, since the non-upgraded not provide IPv6, but this is not relevant, since the non-upgraded
gateway would prevent the hosts from using the ISP service. Some gateway would prevent the hosts from using the ISP service. Some
hosts will try to get IPv6 connectivity, in order to run hosts will try to get IPv6 connectivity, in order to run
applications that require IPv6, or work better with IPv6. The hosts applications that require IPv6, or work better with IPv6. The hosts
skipping to change at page 10, line ? skipping to change at page 10, line ?
There are two variations of this case, depending on the type of There are two variations of this case, depending on the type of
service implemented by the gateway. In many cases, the gateway is a service implemented by the gateway. In many cases, the gateway is a
direct obstacle to the deployment of IPv6, but a gateway which is direct obstacle to the deployment of IPv6, but a gateway which is
some form of bridge-mode CPE or which is a plain (neither some form of bridge-mode CPE or which is a plain (neither
filtering nor NAT) router does not really fall into this category. filtering nor NAT) router does not really fall into this category.
5.1.1 Application support in Case A 5.1.1 Application support in Case A
The focus of Case A is to enable communication between a host on the The focus of Case A is to enable communication between a host on the
unmanaged network and some IPv6-only hosts outside of the network. unmanaged network and some IPv6-only hosts outside of the network.
Huitema et al. [Page 8]
The primary focus in the immediate future, i.e. for the early The primary focus in the immediate future, i.e. for the early
adopters of IPv6, will be peer-to-peer applications. However, as adopters of IPv6, will be peer-to-peer applications. However, as
IPv6 deployment progresses, we will likely find a situation where IPv6 deployment progresses, we will likely find a situation where
some networks have IPv6-only services deployed, at which point we some networks have IPv6-only services deployed, at which point we
would like case A client applications to be able to access those would like case A client applications to be able to access those
services. services.
Local applications are not a primary focus of Case A. At this stage, Local applications are not a primary focus of Case A. At this stage,
we expect all clients in the unmanaged network to have either IPv4 we expect all clients in the unmanaged network to have either IPv4
only or dual stack support. Local applications can continue working only or dual stack support. Local applications can continue working
skipping to change at page 10, line ? skipping to change at page 10, line ?
and easy to deploy: they are deployed in a coordinated fashion as and easy to deploy: they are deployed in a coordinated fashion as
part of a peer-to-peer network, which means that hosts can all part of a peer-to-peer network, which means that hosts can all
receive some form of IPv6 upgrade; they often provide their own receive some form of IPv6 upgrade; they often provide their own
naming infrastructure, in which case they are not dependent on DNS naming infrastructure, in which case they are not dependent on DNS
services. services.
5.1.2 Addresses and connectivity in Case A 5.1.2 Addresses and connectivity in Case A
We saw in 5.1.1 that the likely motivation for deployment of IPv6 We saw in 5.1.1 that the likely motivation for deployment of IPv6
connectivity in hosts in case A is a desire to use peer-to-peer and connectivity in hosts in case A is a desire to use peer-to-peer and
Huitema et al. [Page 9]
client IPv6 applications. These applications require that all client IPv6 applications. These applications require that all
participating nodes get some form of IPv6 connectivity, i.e. at participating nodes get some form of IPv6 connectivity, i.e. at
least one globally reachable IPv6 address. least one globally reachable IPv6 address.
If the local gateway provides global IPv4 addresses to the local If the local gateway provides global IPv4 addresses to the local
hosts, then these hosts can individually exercise the mechanisms hosts, then these hosts can individually exercise the mechanisms
described in case C, "IPv6 connectivity without provider support." described in case C, "IPv6 connectivity without provider support."
If the local gateway implements a NAT function, another type of If the local gateway implements a NAT function, another type of
mechanism is needed. The mechanism to provide connectivity to peers mechanism is needed. The mechanism to provide connectivity to peers
behind NAT should be easy to deploy, and light weight; it will have behind NAT should be easy to deploy, and light weight; it will have
skipping to change at page 10, line ? skipping to change at page 10, line ?
servers are needed, these servers will in practice have to be servers are needed, these servers will in practice have to be
deployed as part of the "support infrastructure" for the peer-to- deployed as part of the "support infrastructure" for the peer-to-
peer network or for an IPv6-based service; economic reality implies peer network or for an IPv6-based service; economic reality implies
that the cost of running these servers should be as low as possible. that the cost of running these servers should be as low as possible.
5.1.3 Naming services in Case A 5.1.3 Naming services in Case A
At this phase of IPv6 deployment, hosts in the unmanaged domain have At this phase of IPv6 deployment, hosts in the unmanaged domain have
access to DNS services over IPv4, through the existing gateway. DNS access to DNS services over IPv4, through the existing gateway. DNS
resolvers are supposed to serve AAAA records, even if they only resolvers are supposed to serve AAAA records, even if they only
Huitema et al. [Page 9]
implement IPv4; the local hosts should thus be able to obtain the implement IPv4; the local hosts should thus be able to obtain the
IPv6 addresses of IPv6-only servers. IPv6 addresses of IPv6-only servers.
Reverse lookup is difficult to provide for hosts on the unmanaged Reverse lookup is difficult to provide for hosts on the unmanaged
network if the gateway is not upgraded. This is a potential issue network if the gateway is not upgraded. This is a potential issue
for client applications. Some servers require a reverse lookup as for client applications. Some servers require a reverse lookup as
part of accepting a client's connection, and may require that the part of accepting a client's connection, and may require that the
direct lookup of the corresponding name matches the IPv6 address of direct lookup of the corresponding name matches the IPv6 address of
the client. There is thus a requirement either to provide a reverse the client. There is thus a requirement either to provide a reverse
lookup solution, or to make sure that IPv6 servers do not require lookup solution, or to make sure that IPv6 servers do not require
skipping to change at page 15, line 41 skipping to change at page 15, line 18
the remaining IPv4 only hosts. the remaining IPv4 only hosts.
6 Security Considerations 6 Security Considerations
Security considerations are discussed as part of the applications' Security considerations are discussed as part of the applications'
requirements. They include: requirements. They include:
- the guarantee that local applications are only used locally, - the guarantee that local applications are only used locally,
- the protection of the privacy of clients - the protection of the privacy of clients
- the requirement that peer-to-peer connections are only used by - the requirement that peer-to-peer connections are only used by
authorized peers. authorized peers
- the requirement that tunneling protocols used for IPv6 access over
IPv4 be designed for secure use
- the related requirement that servers in the infrastructure
supporting transition scenarios be designed not to be vulnerable to
abuse.
The security solutions currently used in IPv4 networks include a The security solutions currently used in IPv4 networks include a
combination of firewall functions in the gateway, authentication and combination of firewall functions in the gateway, authentication and
authorization functions in the applications, encryption and authorization functions in the applications, encryption and
authentication services provides by IP security, Transport Layer authentication services provides by IP security, Transport Layer
Security and application specific services, and host-based security Security and application specific services, and host-based security
products such as anti-virus software, and host firewalls. The products such as anti-virus software, and host firewalls. The
applicability of these tools in IPv6 unmanaged networks will be applicability of these tools in IPv6 unmanaged networks will be
studied in a companion document. studied in a companion document.
skipping to change at page 19, line 20 skipping to change at page 19, line 20
3.1 Local applications ............................................ 3 3.1 Local applications ............................................ 3
3.2 Client applications ........................................... 3 3.2 Client applications ........................................... 3
3.3 Peer-to-peer applications ..................................... 3 3.3 Peer-to-peer applications ..................................... 3
3.4 Server applications ........................................... 4 3.4 Server applications ........................................... 4
4 Application requirements of an IPv6 unmanaged network ........... 4 4 Application requirements of an IPv6 unmanaged network ........... 4
4.1 Requirements of local applications ............................ 5 4.1 Requirements of local applications ............................ 5
4.2 Requirements of client applications ........................... 5 4.2 Requirements of client applications ........................... 5
4.2.1 Privacy requirement of client applications .................. 5 4.2.1 Privacy requirement of client applications .................. 5
4.3 Requirements of peer-to-peer applications ..................... 6 4.3 Requirements of peer-to-peer applications ..................... 6
4.4 Requirements of server applications ........................... 7 4.4 Requirements of server applications ........................... 7
5 Stages of IPv6 deployment ....................................... 8 5 Stages of IPv6 deployment ....................................... 7
5.1 Case A, host deployment of IPv6 applications .................. 9 5.1 Case A, host deployment of IPv6 applications .................. 8
5.1.1 Application support in Case A ............................... 9 5.1.1 Application support in Case A ............................... 8
5.1.2 Addresses and connectivity in Case A ........................ 9 5.1.2 Addresses and connectivity in Case A ........................ 9
5.1.3 Naming services in Case A ................................... 10 5.1.3 Naming services in Case A ................................... 9
5.2 Case B, IPv6 connectivity with provider support ............... 10 5.2 Case B, IPv6 connectivity with provider support ............... 10
5.2.1 Application support in Case B ............................... 10 5.2.1 Application support in Case B ............................... 10
5.2.2 Addresses and connectivity in Case B ........................ 11 5.2.2 Addresses and connectivity in Case B ........................ 11
5.2.3 Naming services in Case B ................................... 12 5.2.3 Naming services in Case B ................................... 11
5.3 Case C, IPv6 connectivity without provider support ............ 12 5.3 Case C, IPv6 connectivity without provider support ............ 12
5.3.1 Application support in Case C ............................... 13 5.3.1 Application support in Case C ............................... 12
5.3.2 Addresses and connectivity in Case C ........................ 13 5.3.2 Addresses and connectivity in Case C ........................ 12
5.3.3 Naming services in Case C ................................... 13 5.3.3 Naming services in Case C ................................... 13
5.4 Case D, ISP stops providing native IPv4 connectivity .......... 13 5.4 Case D, ISP stops providing native IPv4 connectivity .......... 13
5.4.1 Application support in Case D ............................... 14 5.4.1 Application support in Case D ............................... 13
5.4.2 Addresses and connectivity in Case D ........................ 14 5.4.2 Addresses and connectivity in Case D ........................ 14
5.4.3 Naming services in Case D ................................... 15 5.4.3 Naming services in Case D ................................... 14
6 Security Considerations ......................................... 15 6 Security Considerations ......................................... 15
7 IANA Considerations ............................................. 15 7 IANA Considerations ............................................. 15
8 Copyright ....................................................... 16 8 Copyright ....................................................... 15
9 Intellectual Property ........................................... 16 9 Intellectual Property ........................................... 16
10 Acknowledgements ............................................... 17 10 Acknowledgements ............................................... 16
11 References ..................................................... 17 11 References ..................................................... 16
12 Authors' Addresses ............................................. 18 12 Authors' Addresses ............................................. 18
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/