draft-ietf-dnsop-respsize-06.txt   draft-ietf-dnsop-respsize-07.txt 
DNSOP Working Group Paul Vixie, ISC DNSOP Working Group Paul Vixie, ISC
INTERNET-DRAFT Akira Kato, WIDE INTERNET-DRAFT Akira Kato, WIDE
<draft-ietf-dnsop-respsize-06.txt> August 2006 <draft-ietf-dnsop-respsize-07.txt> February 2007
DNS Referral Response Size Issues DNS Referral Response Size Issues
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
skipping to change at page 1, line 33 skipping to change at page 1, line 33
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). All Rights Reserved. Copyright (C) The IETF Trust (2007).
Abstract Abstract
With a mandated default minimum maximum message size of 512 octets, With a mandated default minimum maximum UDP message size of 512
the DNS protocol presents some special problems for zones wishing to octets, the DNS protocol presents some special problems for zones
expose a moderate or high number of authority servers (NS RRs). This wishing to expose a moderate or high number of authority servers (NS
document explains the operational issues caused by, or related to RRs). This document explains the operational issues caused by, or
this response size limit, and suggests ways to optimize the use of related to this response size limit, and suggests ways to optimize
this limited space. Guidance is offered to DNS server implementors the use of this limited space. Guidance is offered to DNS server
and to DNS zone operators. implementors and to DNS zone operators.
INTERNET-DRAFT August 2006 RESPSIZE INTERNET-DRAFT February 2007 RESPSIZE
1 - Introduction and Overview 1 - Introduction and Overview
1.1. The DNS standard (see [RFC1035 4.2.1]) limits message size to 512 1.1. The DNS standard (see [RFC1035 4.2.1]) limits message size to 512
octets. Even though this limitation was due to the required minimum IP octets. Even though this limitation was due to the required minimum IP
reassembly limit for IPv4, it became a hard DNS protocol limit and is reassembly limit for IPv4, it became a hard DNS protocol limit and is
not implicitly relaxed by changes in transport, for example to IPv6. not implicitly relaxed by changes in transport, for example to IPv6.
1.2. The EDNS0 protocol extension (see [RFC2671 2.3, 4.5]) permits 1.2. The EDNS protocol extension starting with version 0 permits larger
larger responses by mutual agreement of the requester and responder. responses by mutual agreement of the requester and responder (see
The 512 octet message size limit will remain in practical effect until [RFC2671 2.3, 4.5]). The 512 octet message size limit will remain in
there is widespread deployment of EDNS0 in DNS resolvers on the practical effect until there is widespread deployment of EDNS in DNS
Internet. resolvers on the Internet.
1.3. Since DNS responses include a copy of the request, the space 1.3. Since DNS responses include a copy of the request, the space
available for response data is somewhat less than the full 512 octets. available for response data is somewhat less than the full 512 octets.
Negative responses are quite small, but for positive and delegation Negative responses are quite small, but for positive and delegation
responses, every octet must be carefully and sparingly allocated. This responses, every octet must be carefully and sparingly allocated. This
document specifically addresses delegation response sizes. document specifically addresses delegation response sizes.
2 - Delegation Details 2 - Delegation Details
2.1. RELEVANT PROTOCOL ELEMENTS 2.1. RELEVANT PROTOCOL ELEMENTS
skipping to change at page 2, line 48 skipping to change at page 2, line 48
2.1.2. If the total response size exceeds 512 octets, and if the data 2.1.2. If the total response size exceeds 512 octets, and if the data
that does not fit was "required", then the TC bit will be set that does not fit was "required", then the TC bit will be set
(indicating truncation). This will usually cause the requester to retry (indicating truncation). This will usually cause the requester to retry
using TCP, depending on what information was desired and what using TCP, depending on what information was desired and what
information was omitted. For example, truncation in the authority information was omitted. For example, truncation in the authority
section is of no interest to a stub resolver who only plans to consume section is of no interest to a stub resolver who only plans to consume
the answer section. If a retry using TCP is needed, the total cost of the answer section. If a retry using TCP is needed, the total cost of
the transaction is much higher. See [RFC1123 6.1.3.2] for details on the transaction is much higher. See [RFC1123 6.1.3.2] for details on
the requirement that UDP be attempted before falling back to TCP. the requirement that UDP be attempted before falling back to TCP.
2.1.3. RRsets are never sent partially unless TC bit set to indicate 2.1.3. RRsets are never sent partially unless the TC bit is set to
truncation. When TC bit is set, the final apparent RRset in the final indicate truncation. When TC bit is set, the final apparent RRset in
non-empty section must be considered "possibly damaged" (see [RFC1035 the final non-empty section must be considered "possibly damaged" (see
6.2], [RFC2181 9]). [RFC1035 6.2], [RFC2181 9]).
INTERNET-DRAFT August 2006 RESPSIZE INTERNET-DRAFT February 2007 RESPSIZE
2.1.4. With or without truncation, the glue present in the additional 2.1.4. With or without truncation, the glue present in the additional
data section should be considered "possibly incomplete", and requesters data section should be considered "possibly incomplete", and requesters
should be prepared to re-query for any damaged or missing RRsets. Note should be prepared to re-query for any damaged or missing RRsets. Note
that truncation of the additional data section might not be signalled that truncation of the additional data section might not be signalled
via the TC bit since additional data is often optional (see discussion via the TC bit since additional data is often optional (see discussion
in [RFC4472 B]). in [RFC4472 B]).
2.1.5. DNS label compression allows a domain name to be instantiated 2.1.5. DNS label compression allows a domain name to be instantiated
only once per DNS message, and then referenced with a two-octet only once per DNS message, and then referenced with a two-octet
skipping to change at page 4, line 5 skipping to change at page 4, line 5
2.2.3. The minimum useful number of name servers is two, for redundancy 2.2.3. The minimum useful number of name servers is two, for redundancy
(see [RFC1034 4.1]). A zone's name servers should be reachable by all (see [RFC1034 4.1]). A zone's name servers should be reachable by all
IP transport protocols (e.g., IPv4 and IPv6) in common use. IP transport protocols (e.g., IPv4 and IPv6) in common use.
2.2.4. The best case is no truncation at all. This is because many 2.2.4. The best case is no truncation at all. This is because many
requesters will retry using TCP immediately, or will automatically re- requesters will retry using TCP immediately, or will automatically re-
query for RRsets that are possibly truncated, without considering query for RRsets that are possibly truncated, without considering
whether the omitted data was actually necessary. whether the omitted data was actually necessary.
INTERNET-DRAFT August 2006 RESPSIZE INTERNET-DRAFT February 2007 RESPSIZE
2.3. ADVICE TO SERVER IMPLEMENTORS 2.3. ADVICE TO SERVER IMPLEMENTORS
2.3.1. In case of multi-homed name servers, it is advantageous to 2.3.1. In case of multi-homed name servers, it is advantageous to
include an address record from each of several name servers before include an address record from each of several name servers before
including several address records for any one name server. If address including several address records for any one name server. If address
records for more than one transport (for example, A and AAAA) are records for more than one transport (for example, A and AAAA) are
available, then it is advantageous to include records of both types available, then it is advantageous to include records of both types
early on, before the message is full. early on, before the message is full.
skipping to change at page 5, line 5 skipping to change at page 5, line 5
second second
Alternate between adding all glue RRsets for any name servers whose Alternate between adding all glue RRsets for any name servers whose
names are in or below the zone being delegated, and all glue RRsets names are in or below the zone being delegated, and all glue RRsets
for any name servers who have multiple address RRsets (currently A for any name servers who have multiple address RRsets (currently A
and AAAA); and AAAA);
thence thence
All other glue RRsets, in any order. All other glue RRsets, in any order.
INTERNET-DRAFT August 2006 RESPSIZE INTERNET-DRAFT February 2007 RESPSIZE
Whenever there are multiple candidates for a position in this priority Whenever there are multiple candidates for a position in this priority
scheme, one should be chosen on a round-robin or fully random basis. scheme, one should be chosen on a round-robin or fully random basis.
The goal of this priority scheme is to offer "necessary" glue first, The goal of this priority scheme is to offer "necessary" glue first,
avoiding silent truncation for this glue if possible. avoiding silent truncation for this glue if possible.
2.3.6. If any "necessary content" is silently truncated, then it is 2.3.6. If any "necessary content" is silently truncated, then it is
advisable that the TC bit be set in order to force a TCP retry, rather advisable that the TC bit be set in order to force a TCP retry, rather
than have the zone be unreachable. Note that a parent server's proper than have the zone be unreachable. Note that a parent server's proper
response to a query for in-child glue or below-child glue is a referral response to a query for in-child glue or below-child glue is a referral
rather than an answer, and that this referral MUST be able to contain rather than an answer, and that this referral must be able to contain
the in-child or below-child glue, and that in outlying cases, only EDNS the in-child or below-child glue, and that in outlying cases, only EDNS
or TCP will be large enough to contain that data. or TCP will be large enough to contain that data.
3 - Analysis 3 - Analysis
3.1. An instrumented protocol trace of a best case delegation response 3.1. An instrumented protocol trace of a best case delegation response
follows. Note that 13 servers are named, and 13 addresses are given. follows. Note that 13 servers are named, and 13 addresses are given.
This query was artificially designed to exactly reach the 512 octet This query was artificially designed to exactly reach the 512 octet
limit. limit.
skipping to change at page 6, line 4 skipping to change at page 6, line 4
com. 86400 NS H.GTLD-SERVERS.NET. ;; @160 com. 86400 NS H.GTLD-SERVERS.NET. ;; @160
com. 86400 NS I.GTLD-SERVERS.NET. ;; @176 com. 86400 NS I.GTLD-SERVERS.NET. ;; @176
com. 86400 NS J.GTLD-SERVERS.NET. ;; @192 com. 86400 NS J.GTLD-SERVERS.NET. ;; @192
com. 86400 NS K.GTLD-SERVERS.NET. ;; @208 com. 86400 NS K.GTLD-SERVERS.NET. ;; @208
com. 86400 NS L.GTLD-SERVERS.NET. ;; @224 com. 86400 NS L.GTLD-SERVERS.NET. ;; @224
com. 86400 NS M.GTLD-SERVERS.NET. ;; @240 com. 86400 NS M.GTLD-SERVERS.NET. ;; @240
com. 86400 NS A.GTLD-SERVERS.NET. ;; @256 com. 86400 NS A.GTLD-SERVERS.NET. ;; @256
com. 86400 NS B.GTLD-SERVERS.NET. ;; @272 com. 86400 NS B.GTLD-SERVERS.NET. ;; @272
com. 86400 NS C.GTLD-SERVERS.NET. ;; @288 com. 86400 NS C.GTLD-SERVERS.NET. ;; @288
com. 86400 NS D.GTLD-SERVERS.NET. ;; @304 com. 86400 NS D.GTLD-SERVERS.NET. ;; @304
INTERNET-DRAFT August 2006 RESPSIZE INTERNET-DRAFT February 2007 RESPSIZE
;; ADDITIONAL SECTION: ;; ADDITIONAL SECTION:
A.GTLD-SERVERS.NET. 86400 A 192.5.6.30 ;; @320 A.GTLD-SERVERS.NET. 86400 A 192.5.6.30 ;; @320
B.GTLD-SERVERS.NET. 86400 A 192.33.14.30 ;; @336 B.GTLD-SERVERS.NET. 86400 A 192.33.14.30 ;; @336
C.GTLD-SERVERS.NET. 86400 A 192.26.92.30 ;; @352 C.GTLD-SERVERS.NET. 86400 A 192.26.92.30 ;; @352
D.GTLD-SERVERS.NET. 86400 A 192.31.80.30 ;; @368 D.GTLD-SERVERS.NET. 86400 A 192.31.80.30 ;; @368
E.GTLD-SERVERS.NET. 86400 A 192.12.94.30 ;; @384 E.GTLD-SERVERS.NET. 86400 A 192.12.94.30 ;; @384
F.GTLD-SERVERS.NET. 86400 A 192.35.51.30 ;; @400 F.GTLD-SERVERS.NET. 86400 A 192.35.51.30 ;; @400
G.GTLD-SERVERS.NET. 86400 A 192.42.93.30 ;; @416 G.GTLD-SERVERS.NET. 86400 A 192.42.93.30 ;; @416
H.GTLD-SERVERS.NET. 86400 A 192.54.112.30 ;; @432 H.GTLD-SERVERS.NET. 86400 A 192.54.112.30 ;; @432
skipping to change at page 7, line 4 skipping to change at page 7, line 4
d.dns.br requires 4 bytes d.dns.br requires 4 bytes
# of NS: 4 # of NS: 4
For maximum size query (255 byte): For maximum size query (255 byte):
only A is considered: # of A is 4 (green) only A is considered: # of A is 4 (green)
A and AAAA are considered: # of A+AAAA is 3 (yellow) A and AAAA are considered: # of A+AAAA is 3 (yellow)
preferred-glue A is assumed: # of A is 4, # of AAAA is 3 (yellow) preferred-glue A is assumed: # of A is 4, # of AAAA is 3 (yellow)
For average size query (64 byte): For average size query (64 byte):
only A is considered: # of A is 4 (green) only A is considered: # of A is 4 (green)
A and AAAA are considered: # of A+AAAA is 4 (green) A and AAAA are considered: # of A+AAAA is 4 (green)
preferred-glue A is assumed: # of A is 4, # of AAAA is 4 (green) preferred-glue A is assumed: # of A is 4, # of AAAA is 4 (green)
INTERNET-DRAFT August 2006 RESPSIZE INTERNET-DRAFT February 2007 RESPSIZE
% perl respsize.pl ns-ext.isc.org ns.psg.com ns.ripe.net ns.eu.int % perl respsize.pl ns-ext.isc.org ns.psg.com ns.ripe.net ns.eu.int
ns-ext.isc.org requires 16 bytes ns-ext.isc.org requires 16 bytes
ns.psg.com requires 12 bytes ns.psg.com requires 12 bytes
ns.ripe.net requires 13 bytes ns.ripe.net requires 13 bytes
ns.eu.int requires 11 bytes ns.eu.int requires 11 bytes
# of NS: 4 # of NS: 4
For maximum size query (255 byte): For maximum size query (255 byte):
only A is considered: # of A is 4 (green) only A is considered: # of A is 4 (green)
A and AAAA are considered: # of A+AAAA is 3 (yellow) A and AAAA are considered: # of A+AAAA is 3 (yellow)
skipping to change at page 8, line 4 skipping to change at page 8, line 4
otherwise be possible, since the common parent domain name only appears otherwise be possible, since the common parent domain name only appears
once in a DNS message and is referred to via "compression pointers" once in a DNS message and is referred to via "compression pointers"
thereafter. thereafter.
4.2. If all nameserver names for a zone share a common parent, then it 4.2. If all nameserver names for a zone share a common parent, then it
is operationally advisable to make all servers for the zone thus served is operationally advisable to make all servers for the zone thus served
also be authoritative for the zone of that common parent. For example, also be authoritative for the zone of that common parent. For example,
the root name servers (?.ROOT-SERVERS.NET) can answer authoritatively the root name servers (?.ROOT-SERVERS.NET) can answer authoritatively
for the ROOT-SERVERS.NET. This is to ensure that the zone's servers for the ROOT-SERVERS.NET. This is to ensure that the zone's servers
always have the zone's nameservers' glue available when delegating, and always have the zone's nameservers' glue available when delegating, and
INTERNET-DRAFT August 2006 RESPSIZE INTERNET-DRAFT February 2007 RESPSIZE
will be able to respond with answers rather than referrals if a will be able to respond with answers rather than referrals if a
requester who wants that glue comes back asking for it. In this case requester who wants that glue comes back asking for it. In this case
the name server will likely be a "stealth server" -- authoritative but the name server will likely be a "stealth server" -- authoritative but
unadvertised in the glue zone's NS RRset. See [RFC1996 2] for more unadvertised in the glue zone's NS RRset. See [RFC1996 2] for more
information about stealth servers. information about stealth servers.
4.3. Thirteen (13) is the effective maximum number of nameserver names 4.3. Thirteen (13) is the effective maximum number of nameserver names
usable traditional (non-extended) DNS, assuming a common parent domain usable traditional (non-extended) DNS, assuming a common parent domain
name, and given that implicit referral response truncation is name, and given that implicit referral response truncation is
skipping to change at page 8, line 45 skipping to change at page 8, line 45
single address record in some protocol family (e.g., an A RR), then all single address record in some protocol family (e.g., an A RR), then all
thirteen name servers or any subset thereof could multi-home in a second thirteen name servers or any subset thereof could multi-home in a second
protocol family by adding a second address record (e.g., an AAAA RR) protocol family by adding a second address record (e.g., an AAAA RR)
without reducing the reachability of the zone thus served. without reducing the reachability of the zone thus served.
5 - Source Code 5 - Source Code
#!/usr/bin/perl #!/usr/bin/perl
# #
# SYNOPSIS # SYNOPSIS
# repsize.pl [ -z zone ] fqdn_ns1 fqdn_ns2 ... # respsize.pl [ -z zone ] fqdn_ns1 fqdn_ns2 ...
# if all queries are assumed to have a same zone suffix, # if all queries are assumed to have a same zone suffix,
# such as "jp" in JP TLD servers, specify it in -z option # such as "jp" in JP TLD servers, specify it in -z option
# #
use strict; use strict;
use Getopt::Std; use Getopt::Std;
INTERNET-DRAFT August 2006 RESPSIZE INTERNET-DRAFT February 2007 RESPSIZE
my ($sz_msg) = (512); my ($sz_msg) = (512);
my ($sz_header, $sz_ptr, $sz_rr_a, $sz_rr_aaaa) = (12, 2, 16, 28); my ($sz_header, $sz_ptr, $sz_rr_a, $sz_rr_aaaa) = (12, 2, 16, 28);
my ($sz_type, $sz_class, $sz_ttl, $sz_rdlen) = (2, 2, 4, 2); my ($sz_type, $sz_class, $sz_ttl, $sz_rdlen) = (2, 2, 4, 2);
my (%namedb, $name, $nssect, %opts, $optz); my (%namedb, $name, $nssect, %opts, $optz);
my $n_ns = 0; my $n_ns = 0;
getopt('z', %opts); getopt('z', %opts);
if (defined($opts{'z'})) { if (defined($opts{'z'})) {
server_name_len($opts{'z'}); # just register it server_name_len($opts{'z'}); # just register it
skipping to change at page 9, line 48 skipping to change at page 9, line 48
return length($name) - length($suffix) + $sz_ptr return length($name) - length($suffix) + $sz_ptr
if (defined($namedb{$suffix})); if (defined($namedb{$suffix}));
$namedb{$suffix} = 1; $namedb{$suffix} = 1;
} }
return $len; return $len;
} }
sub arsect { sub arsect {
my ($sz_query, $nssect, $n_ns, $cond) = @_; my ($sz_query, $nssect, $n_ns, $cond) = @_;
my ($space, $n_a, $n_a_aaaa, $n_p_aaaa, $ansect); my ($space, $n_a, $n_a_aaaa, $n_p_aaaa, $ansect);
$ansect = $sz_query + 1 + $sz_type + $sz_class; $ansect = $sz_query + $sz_type + $sz_class;
$space = $sz_msg - $sz_header - $ansect - $nssect; $space = $sz_msg - $sz_header - $ansect - $nssect;
$n_a = atmost(int($space / $sz_rr_a), $n_ns); $n_a = atmost(int($space / $sz_rr_a), $n_ns);
INTERNET-DRAFT August 2006 RESPSIZE INTERNET-DRAFT February 2007 RESPSIZE
$n_a_aaaa = atmost(int($space $n_a_aaaa = atmost(int($space
/ ($sz_rr_a + $sz_rr_aaaa)), $n_ns); / ($sz_rr_a + $sz_rr_aaaa)), $n_ns);
$n_p_aaaa = atmost(int(($space - $sz_rr_a * $n_ns) $n_p_aaaa = atmost(int(($space - $sz_rr_a * $n_ns)
/ $sz_rr_aaaa), $n_ns); / $sz_rr_aaaa), $n_ns);
printf "For %s size query (%d byte):\n", $cond, $sz_query; printf "For %s size query (%d byte):\n", $cond, $sz_query;
printf " only A is considered: "; printf " only A is considered: ";
printf "# of A is %d (%s)\n", $n_a, &judge($n_a, $n_ns); printf "# of A is %d (%s)\n", $n_a, &judge($n_a, $n_ns);
printf " A and AAAA are considered: "; printf " A and AAAA are considered: ";
printf "# of A+AAAA is %d (%s)\n", printf "# of A+AAAA is %d (%s)\n",
skipping to change at page 11, line 5 skipping to change at page 11, line 5
7 - IANA Considerations 7 - IANA Considerations
This document does not call for changes or additions to any IANA This document does not call for changes or additions to any IANA
registry. registry.
8 - Acknowledgement 8 - Acknowledgement
The authors thank Peter Koch, Rob Austein, Joe Abley, and Mark Andrews The authors thank Peter Koch, Rob Austein, Joe Abley, and Mark Andrews
for their valuable comments and suggestions. for their valuable comments and suggestions.
INTERNET-DRAFT August 2006 RESPSIZE INTERNET-DRAFT February 2007 RESPSIZE
This work was supported by the US National Science Foundation (research This work was supported by the US National Science Foundation (research
grant SCI-0427144) and DNS-OARC. grant SCI-0427144) and DNS-OARC.
9 - References 9 - References
[RFC1034] Mockapetris, P.V., "Domain names - Concepts and Facilities", [RFC1034] Mockapetris, P.V., "Domain names - Concepts and Facilities",
RFC1034, November 1987. RFC1034, November 1987.
[RFC1035] Mockapetris, P.V., "Domain names - Implementation and [RFC1035] Mockapetris, P.V., "Domain names - Implementation and
skipping to change at page 12, line 4 skipping to change at page 12, line 4
Redwood City, CA 94063 Redwood City, CA 94063
+1 650 423 1301 +1 650 423 1301
vixie@isc.org vixie@isc.org
Akira Kato Akira Kato
University of Tokyo, Information Technology Center University of Tokyo, Information Technology Center
2-11-16 Yayoi Bunkyo 2-11-16 Yayoi Bunkyo
Tokyo 113-8658, JAPAN Tokyo 113-8658, JAPAN
+81 3 5841 2750 +81 3 5841 2750
kato@wide.ad.jp kato@wide.ad.jp
INTERNET-DRAFT August 2006 RESPSIZE INTERNET-DRAFT February 2007 RESPSIZE
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors retain contained in BCP 78, and except as set forth therein, the authors retain
all their rights. all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR
IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in this 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 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 might not be available; nor does it represent that it has made any
 End of changes. 20 change blocks. 
35 lines changed or deleted 35 lines changed or added

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