draft-ietf-geopriv-res-gw-lis-discovery-03.txt   draft-ietf-geopriv-res-gw-lis-discovery-04.txt 
GEOPRIV M. Thomson GEOPRIV M. Thomson
Internet-Draft Microsoft Internet-Draft Microsoft
Intended status: Informational R. Bellis Intended status: Informational R. Bellis
Expires: September 30, 2012 Nominet UK Expires: March 29, 2013 Nominet UK
March 29, 2012 September 25, 2012
Location Information Server (LIS) Discovery using IP address and Reverse Location Information Server (LIS) Discovery using IP address and Reverse
DNS DNS
draft-ietf-geopriv-res-gw-lis-discovery-03 draft-ietf-geopriv-res-gw-lis-discovery-04
Abstract Abstract
The residential gateway is a device that has become an integral part The residential gateway is a device that has become an integral part
of home networking equipment. Discovering a Location Information of home networking equipment. Discovering a Location Information
Server (LIS) is a necessary part of acquiring location information Server (LIS) is a necessary part of acquiring location information
for location-based services. However, discovering a LIS when a for location-based services. However, discovering a LIS when a
residential gateway is present poses a configuration challenge, residential gateway is present poses a configuration challenge,
requiring a method that is able to work around the obstacle presented requiring a method that is able to work around the obstacle presented
by the gateway. by the gateway.
skipping to change at page 1, line 42 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 30, 2012. This Internet-Draft will expire on March 29, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 23 skipping to change at page 2, line 23
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . 4 2. Conventions used in this document . . . . . . . . . . . . . . 4
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Residential Gateway . . . . . . . . . . . . . . . . . . . 6 3.1. Residential Gateway . . . . . . . . . . . . . . . . . . . 6
3.2. Residential Gateway Security Features . . . . . . . . . . 7 3.2. Residential Gateway Security Features . . . . . . . . . . 7
4. IP-based DNS Solution . . . . . . . . . . . . . . . . . . . . 8 4. IP-based DNS Solution . . . . . . . . . . . . . . . . . . . . 8
4.1. Identification of IP Addresses . . . . . . . . . . . . . . 8 4.1. Identification of IP Addresses . . . . . . . . . . . . . . 8
4.2. Domain Name Selection . . . . . . . . . . . . . . . . . . 9 4.2. Domain Name Selection . . . . . . . . . . . . . . . . . . 9
4.3. When To Use This Method . . . . . . . . . . . . . . . . . 9 4.3. When To Use The Reverse DNS Method . . . . . . . . . . . . 9
4.4. Private Address Spaces . . . . . . . . . . . . . . . . . . 10 4.4. Private Address Spaces . . . . . . . . . . . . . . . . . . 10
4.5. Necessary Assumptions and Restrictions . . . . . . . . . . 11 4.5. Necessary Assumptions and Restrictions . . . . . . . . . . 11
4.6. Failure Modes . . . . . . . . . . . . . . . . . . . . . . 11 4.6. Failure Modes . . . . . . . . . . . . . . . . . . . . . . 11
4.7. Deployment Considerations . . . . . . . . . . . . . . . . 11 4.7. Deployment Considerations . . . . . . . . . . . . . . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 15 7. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 15
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.1. Normative References . . . . . . . . . . . . . . . . . . . 17 8.1. Normative References . . . . . . . . . . . . . . . . . . . 17
8.2. Informative References . . . . . . . . . . . . . . . . . . 17 8.2. Informative References . . . . . . . . . . . . . . . . . . 17
skipping to change at page 3, line 18 skipping to change at page 3, line 18
access network. The LIS uses knowledge of the access network access network. The LIS uses knowledge of the access network
topology and other information to generate location for Devices. topology and other information to generate location for Devices.
Devices within an access network are able to acquire location Devices within an access network are able to acquire location
information from a LIS. information from a LIS.
The relationship between a Device and an access network might be The relationship between a Device and an access network might be
transient. Configuration of the correct LIS at the Device ensures transient. Configuration of the correct LIS at the Device ensures
that accurate location information is available. Without location that accurate location information is available. Without location
information, some network services are not available. information, some network services are not available.
The configuration of a LIS address on a Device requires some The configuration of a LIS IP address on a Device requires some
automated configuration process. This is particularly relevant when automated process. This is particularly relevant when it is
it is considered that Devices might move between different access considered that Devices might move between different access networks
networks. LIS Discovery [RFC5986] describes a method that employs served by different LISs. LIS Discovery [RFC5986] describes a method
the Dynamic Host Configuration Protocol (DHCPv4 [RFC2131], DHCPv6 that employs the Dynamic Host Configuration Protocol (DHCPv4
[RFC3315]) as input to U-NAPTR [RFC4848] discovery. [RFC2131], DHCPv6 [RFC3315]) as input to U-NAPTR [RFC4848] discovery.
A residential gateway, or home router, provides a range of networking A residential gateway, or home router, provides a range of networking
functions for Devices within the network it serves. In most cases, functions for Devices within the network it serves. Unfortunately in
these functions effectively prevent the successful use of DHCP for most cases these functions effectively prevent the successful use of
LIS discovery. DHCP for LIS discovery.
The drawback with DHCP is that universal deployment of a new option One drawback with DHCP is that universal deployment of a new option
takes a considerable amount of time. Often, networking equipment takes a considerable amount of time. Often, networking equipment
needs to be updated in order to support the new option. Of needs to be updated in order to support the new option. Of
particular concern are the millions of residential gateway devices particular concern are the millions of residential gateway devices
used to provide Internet access to homes and businesses. While used to provide Internet access to homes and businesses. While
[RFC5986] describes functions that can be provided by residential [RFC5986] describes functions that can be provided by residential
gateways to support LIS discovery, gateways built before the gateways to support LIS discovery, gateways built before the
publication of this specification do not (and cannot) provide these publication of this specification are not expected (and are likely
functions. not able) to provide these functions.
This document explores the problem of configuring Devices with a LIS This document explores the problem of configuring Devices with a LIS
address when a residential gateway is interposed between the Device address when a residential gateway is interposed between the Device
and access network. Section 3 defines the problem and Section 4 and access network. Section 3 defines the problem and Section 4
describes a method for determining a domain name that can be used for describes a method for determining a domain name that can be used for
discovery of the LIS. discovery of the LIS.
In some cases, the solution described in this document is based on a In some cases, the solution described in this document is based on a
UNilateral Self-Address Fixing (UNSAF) [RFC3424] method. For those UNilateral Self-Address Fixing (UNSAF) [RFC3424] method. For those
cases, this solution is considered transitional until such time as cases, this solution is considered transitional until such time as
skipping to change at page 5, line 50 skipping to change at page 5, line 50
( / \ / ) ( / \ / )
( +--------+ +--------+ ) ( +--------+ +--------+ )
( | Device | | Device | ) ( | Device | | Device | )
( +--------+ +--------+ ) ( +--------+ +--------+ )
( ) ( )
`- - - - - - - - - - - - - -' `- - - - - - - - - - - - - -'
Figure 1: Simplified Network Topology Figure 1: Simplified Network Topology
A particularly important characteristic of this arrangement is the A particularly important characteristic of this arrangement is the
relatively small area served by the residential gateway. Given a relatively small geographical area served by the residential gateway.
small enough area, it is reasonable to delegate the responsibility Given a small enough area, it is reasonable to delegate the
for providing Devices within the residential network with location responsibility for providing Devices within the residential network
information to the ISP. The ISP is able to provide location with location information to the ISP. The ISP is able to provide
information that identifies the residence, which should be adequate location information that identifies the residence, which should be
for a wide range of purposes. adequate for a wide range of purposes.
A residential network that covers a larger area might require a A residential network that covers a larger geographical area might
dedicated LIS, a case that is outside the scope of this document. require a dedicated LIS, a case that is outside the scope of this
document.
The goal of LIS discovery is to identify a LIS that is able to The goal of LIS discovery is to identify a LIS that is able to
provide the Device with accurate location information. In the provide the Device with accurate location information. In the
network topology described, this means identifying the LIS in the network topology described, this means identifying the LIS in the
access network. The residential gateway is a major obstacle in access network. The residential gateway is a major obstacle in
achieving this goal. achieving this goal.
3.1. Residential Gateway 3.1. Residential Gateway
A residential gateway can encompass several different functions A residential gateway can encompass several different functions
skipping to change at page 6, line 46 skipping to change at page 6, line 47
given a generic configuration that includes no information about the given a generic configuration that includes no information about the
ISP network. For instance, DNS configuration typically points to a ISP network. For instance, DNS configuration typically points to a
DNS relay on the gateway device. This approach ensures that the DNS relay on the gateway device. This approach ensures that the
local network served by the gateway is able to operate without a local network served by the gateway is able to operate without a
connection to the ISP, but it also means that Devices are effectively connection to the ISP, but it also means that Devices are effectively
ignorant of the ISP network. ignorant of the ISP network.
[RFC5986] describes several methods that can be applied by a [RFC5986] describes several methods that can be applied by a
residential gateway to assist Devices in acquiring location residential gateway to assist Devices in acquiring location
information. For instance, the residential gateway could forward LIS information. For instance, the residential gateway could forward LIS
address information to hosts within the network it serves. Such an address information to hosts within the network it serves.
active involvement in the discovery process only works for new Unfortunately, such an active involvement in the discovery process
residential gateway devices that implement these recommendations. only works for new residential gateway devices that implement those
recommendations.
Where residential gateways already exist, direct involvement of the Where residential gateways already exist, direct involvement of the
gateway in LIS discovery requires that the residential gateway be gateway in LIS discovery requires that the residential gateway be
updated or replaced. The cost of replacement is difficult to justify updated or replaced. The cost of replacement is difficult to justify
to the owner of the gateway, especially when it is considered that to the owner of the gateway, especially when it is considered that
the gateway still fills its primary function: Internet access. the gateway still fills its primary function: Internet access.
Existing residential gateways have proven to be quite reliable Existing residential gateways have proven to be quite reliable
devices, some operating continuously for many years without failure. devices, some operating continuously for many years without failure.
As a result, there are many operational gateways that are of a As a result, there are many operational gateways that are of a
skipping to change at page 8, line 34 skipping to change at page 8, line 34
4.1. Identification of IP Addresses 4.1. Identification of IP Addresses
A Device identifies a set of potential IP addresses that currently A Device identifies a set of potential IP addresses that currently
result in packets being routed to it. These are ordered by result in packets being routed to it. These are ordered by
proximity, with those addresses that are used in adjacent network proximity, with those addresses that are used in adjacent network
segments being favoured over those used in public or remote networks. segments being favoured over those used in public or remote networks.
The first addresses in the set are those that are assigned to local The first addresses in the set are those that are assigned to local
network interfaces. network interfaces.
A Device can use the Session Traversal Utilities for NAT (STUN) A Device can use the Session Traversal Utilities for NAT (STUN)
[RFC5389] to determine its public reflexive transport address. The [RFC5389] mechanism to determine its public reflexive transport
host uses the "Binding Request" message and the resulting address. The host uses the "Binding Request" message and the
"XOR-MAPPED-ADDRESS" parameter that is returned in the response. resulting "XOR-MAPPED-ADDRESS" parameter that is returned in the
response.
Alternative methods for determining other IP addresses MAY be used by Alternative methods for determining other IP addresses MAY be used by
the host. Universal Plug and Play (UPnP) [UPnP-IGD-WANIPConnection1] the Device. Universal Plug and Play (UPnP)
and NAT Port Mapping Protocol (NAT-PMP) [I-D.cheshire-nat-pmp] are [UPnP-IGD-WANIPConnection1] and NAT Port Mapping Protocol (NAT-PMP)
both able to provide the external address of a residential gateway [I-D.cheshire-nat-pmp] are both able to provide the external address
device when enabled. These as well as proprietary methods for of a residential gateway device when enabled. These as well as
determining other addresses might also be available. Because there proprietary methods for determining other addresses might also be
is no assurance that these methods will be supported by any access available. Because there is no assurance that these methods will be
network these methods are not mandated. Note also that in some supported by any access network these methods are not mandated. Note
cases, methods that rely on the view of the network from the also that in some cases, methods that rely on the view of the network
residential gateway device could reveal an address in a private from the residential gateway device could reveal an address in a
address range (see Section 4.5). private address range (see Section 4.5).
In many instances, the IP address produced might be from a private In many instances, the IP address produced might be from a private
address range. For instance, the address on a local network address range. For instance, the address on a local network
interface could be from a private range allocated by the residential interface could be from a private range allocated by the residential
gateway. In other cases, methods that rely on the view of the gateway. In other cases, methods that rely on the view of the
network (UPnP, NAT-PMP) from the residential gateway device could network (UPnP, NAT-PMP) from the residential gateway device could
reveal an address in a private address range if the access network reveal an address in a private address range if the access network
also uses NAT. For a private IP address, the derived domain name is also uses NAT. For a private IP address, the derived domain name is
only usable where the DNS server used contains data for the only usable where the DNS server used contains data for the
corresponding private IP address range. corresponding private IP address range.
skipping to change at page 9, line 21 skipping to change at page 9, line 22
4.2. Domain Name Selection 4.2. Domain Name Selection
The domain name selected for each resulting IP address is the name The domain name selected for each resulting IP address is the name
that would be used for a reverse DNS lookup. The domain name derived that would be used for a reverse DNS lookup. The domain name derived
from an IP version 4 address is in the ".in-addr.arpa." tree and from an IP version 4 address is in the ".in-addr.arpa." tree and
follows the construction rules in Section 3.5 of [RFC1035]. The follows the construction rules in Section 3.5 of [RFC1035]. The
domain name derived from an IP version 6 address is in the domain name derived from an IP version 6 address is in the
".ip6.arpa." tree and follows the construction rules in Section 2.5 ".ip6.arpa." tree and follows the construction rules in Section 2.5
of [RFC3596]. of [RFC3596].
Additional domain names are added to allow for a single record to Additional domain names are added to allow for a single DNS record to
cover a larger set of addresses. If the search on the domain derived cover a larger set of addresses. If the search on the domain derived
from the full IP address does not produce a NAPTR record with the from the full IP address does not produce a NAPTR record with the
desired service tag (e.g., "LIS:HELD"), a similar search is repeated desired service tag (e.g., "LIS:HELD"), a similar search is repeated
based on a shorter domain name, using a part of the IP address: based on a shorter domain name, using a part of the IP address:
o For IP version 4, the resulting domain name SHOULD be shortened o For IP version 4, the resulting domain name SHOULD be shortened
successively by one and two labels and the query repeated. This successively by one and two labels and the query repeated. This
corresponds to a search on a /24 or /16 network prefix. This corresponds to a search on a /24 or /16 network prefix. This
allows for fewer DNS records in the case where a single access allows for fewer DNS records in the case where a single access
network covering an entire /24 or /16 network is served by the network covering an entire /24 or /16 network is served by the
same LIS. same LIS.
o For IP version 6, the resulting domain SHOULD be shortened o For IP version 6, the resulting domain SHOULD be shortened
sucessively by 16, 18, 20 and 24 labels and the query repeated. sucessively by 16, 18, 20 and 24 labels and the query repeated.
This corresponds to a search on a /64, /56, /48 or /32 network This corresponds to a search on a /64, /56, /48 or /32 network
prefix. prefix.
DNS queries on other prefixes than those listed above SHOULD NOT be DNS queries on other prefixes than those listed above SHOULD NOT be
performed to limit the number of DNS queries performed by Devices. performed in order to limit the number of DNS queries performed by
If no LIS is discovered by this method, no more than four U-NAPTR Devices. If no LIS is discovered by this method, the result will be
resolutions are invoked for each IP address. that no more than four U-NAPTR resolutions are invoked for each IP
address.
4.3. When To Use This Method 4.3. When To Use The Reverse DNS Method
The DHCP method described in [RFC5986] SHOULD be attempted on all The DHCP method described in [RFC5986] SHOULD be attempted on all
local network interfaces before attempting this method. This method local network interfaces before attempting this method. This method
is employed either because DHCP is unavailable, when the DHCP server is employed either because DHCP is unavailable, when the DHCP server
does not provide a value for the access network domain name option, does not provide a value for the access network domain name option,
or if a request to the resulting LIS results in a HELD "notLocatable" or if a request to the resulting LIS results in a HELD "notLocatable"
error or equivalent. error or equivalent.
4.4. Private Address Spaces 4.4. Private Address Spaces
skipping to change at page 11, line 48 skipping to change at page 11, line 48
used, the entity providing a public IP address might not be able to used, the entity providing a public IP address might not be able to
provide the Device with location information. It is assumed that provide the Device with location information. It is assumed that
this entity is able to identify this problem and indicate this to the this entity is able to identify this problem and indicate this to the
Device (using the "notLocatable" HELD error, or similar). This Device (using the "notLocatable" HELD error, or similar). This
problem is described in more detail in [RFC5985]. problem is described in more detail in [RFC5985].
4.7. Deployment Considerations 4.7. Deployment Considerations
An access network provider SHOULD provide NAPTR records for each An access network provider SHOULD provide NAPTR records for each
public IP address that is used for Devices within the access network. public IP address that is used for Devices within the access network.
If the access network provider uses NAT, any DNS internal to that NAT If the access network provider uses NAT, any DNS server internal to
SHOULD also include records for the private address range. that NAT SHOULD also include records for the private address range.
NAPTR records can be provided for individual IP addresses. To limit NAPTR records can be provided for individual IP addresses. To limit
the proliferation of identical records, a single record can be placed the proliferation of identical records, a single record can be placed
at a the higher nodes of the tree (corresponding to /24 and /16 for at a the higher nodes of the tree (corresponding to /24 and /16 for
IPv4; /64, /48 and /32 for IPv6). A record at a higher point in the IPv4; /64, /48 and /32 for IPv6). A record at a higher point in the
tree (those with a shorter prefix) applies to all addresses lower in tree (those with a shorter prefix) applies to all addresses lower in
the tree (those with a longer prefix); records at the lower point the tree (those with a longer prefix); records at the lower point
override those at higher points, allowing for exceptions to be override those at higher points, thus allowing for exceptions to be
provided for at the lower point. specified.
5. IANA Considerations 5. IANA Considerations
[RFC Editor: please remove this section prior to publication.] [RFC Editor: please remove this section prior to publication.]
This document has no IANA actions. This document has no IANA actions.
6. Security Considerations 6. Security Considerations
The security considerations described in [RFC5986] apply to the The security considerations described in [RFC5986] apply to the
skipping to change at page 14, line 26 skipping to change at page 14, line 26
further security considerations relating to the identification of the further security considerations relating to the identification of the
IP address. It is possible that an attacker could attempt to provide IP address. It is possible that an attacker could attempt to provide
a falsified IP addresses in an attempt to subvert the rest of the a falsified IP addresses in an attempt to subvert the rest of the
process. process.
[RFC5389] describes attacks where an attacker is able to ensure that [RFC5389] describes attacks where an attacker is able to ensure that
a Device receives a falsified reflexive address. Even if the STUN a Device receives a falsified reflexive address. Even if the STUN
server is trusted, an attacker might be able to ensure that a server is trusted, an attacker might be able to ensure that a
falsified address is provided to the Device. falsified address is provided to the Device.
This attack is an effective means of denial of service, or a means to This attack could result in an effective means of denial of service,
provide a deliberately misleading service. Notably, any LIS that is or a means to provide a deliberately misleading service. Notably,
identified based on a falsified IP address could still be a valid LIS any LIS that is identified based on a falsified IP address could
for the given IP address, just not one that is useful for providing still be a valid LIS for the given IP address, just not one that is
the Device with location information. In this case, the LIS provides useful for providing the Device with location information. In this
a HELD "notLocatable" error, or an equivalent. If the falsified IP case, the LIS provides a HELD "notLocatable" error, or an equivalent.
address is under the control of the attacker, it is possible that If the falsified IP address is under the control of the attacker, it
misleading (but verifiable) DNS records could indicate a malicious is possible that misleading (but verifiable) DNS records could
LIS that provides false location information. indicate a malicious LIS that provides false location information.
In all cases of falsification, the best remedy is to perform some In all cases of falsification, the best remedy is to perform some
form of independent verification of the result. No specific form of independent verification of the result. No specific
mechanism is currently available to prevent attacks based on mechanism is currently available to prevent attacks based on
falsification of reflexive addresses; it is suggested that Devices falsification of reflexive addresses; it is suggested that Devices
attempt to independently verify that the reflexive transport address attempt to independently verify that the reflexive transport address
provided is accurate. provided is accurate.
Use of private address space effectively prevents use of the usual Use of private address space effectively prevents use of the usual
set of trust anchors for DNSSEC. Only a DNS server that is able to set of trust anchors for DNSSEC. Only a DNS server that is able to
skipping to change at page 18, line 20 skipping to change at page 18, line 20
Location Configuration Protocol: Problem Statement and Location Configuration Protocol: Problem Statement and
Requirements", RFC 5687, March 2010. Requirements", RFC 5687, March 2010.
[UPnP-IGD-WANIPConnection1] [UPnP-IGD-WANIPConnection1]
UPnP Forum, "Internet Gateway Device (IGD) Standardized UPnP Forum, "Internet Gateway Device (IGD) Standardized
Device Control Protocol V 1.0: WANIPConnection:1 Service Device Control Protocol V 1.0: WANIPConnection:1 Service
Template Version 1.01 For UPnP Version 1.0", DCP 05-001, Template Version 1.01 For UPnP Version 1.0", DCP 05-001,
Nov 2001. Nov 2001.
[I-D.cheshire-nat-pmp] [I-D.cheshire-nat-pmp]
Cheshire, S., "NAT Port Mapping Protocol (NAT-PMP)", Cheshire, S. and M. Krochmal, "NAT Port Mapping Protocol
draft-cheshire-nat-pmp-03 (work in progress), April 2008. (NAT-PMP)", draft-cheshire-nat-pmp-05 (work in progress),
September 2012.
[RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines",
BCP 152, RFC 5625, August 2009. BCP 152, RFC 5625, August 2009.
Authors' Addresses Authors' Addresses
Martin Thomson Martin Thomson
Microsoft Microsoft
3210 Porter Drive 3210 Porter Drive
Palo Alto, CA 94304 Palo Alto, CA 94304
 End of changes. 20 change blocks. 
61 lines changed or deleted 66 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/