idnits 2.17.1 draft-ietf-dnsop-respsize-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 557. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 568. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 575. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 581. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 36 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 14 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 18, 2007) is 5973 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2671 (Obsoleted by RFC 6891) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force P. Vixie 3 Internet-Draft Internet Systems Consortium 4 Intended status: Informational A. Kato 5 Expires: June 20, 2008 The University of Tokyo/WIDE 6 Project 7 December 18, 2007 9 DNS Referral Response Size Issues 10 draft-ietf-dnsop-respsize-09 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on June 20, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 With a mandated default minimum maximum UDP message size of 512 44 octets, the DNS protocol presents some special problems for zones 45 wishing to expose a moderate or high number of authority servers (NS 46 RRs). This document explains the operational issues caused by, or 47 related to this response size limit, and suggests ways to optimize 48 the use of this limited space. Guidance is offered to DNS server 49 implementors and to DNS zone operators. 51 1. Introduction 53 1.1. Introduction and Overview 55 The DNS standard limits UDP message size to 512 octets (see [RFC1035] 56 4.2.1). Even though this limitation was due to the required minimum 57 IP reassembly limit for IPv4, it became a hard DNS protocol limit and 58 is not implicitly relaxed by changes in a network layer protocol, for 59 example to IPv6. 61 The EDNS protocol extension starting with version 0 permits larger 62 responses by mutual agreement of the requester and responder (see 63 [RFC2671] 2.3, 4.5), and it is recommended to support EDNS. The 512 64 octets UDP message size limit will remain in practical effect until 65 virtually all DNS servers and resolvers support EDNS. 67 Since DNS responses include a copy of the request, the space 68 available for response data is somewhat less than the full 512 69 octets. Negative responses are quite small, but for positive and 70 referral responses, every octet must be carefully and sparingly 71 allocated. While the response size of positive responses is also a 72 concern[RFC3226], this document specifically addresses referral 73 response size. 75 1.2. Requirements Language 77 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 78 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 79 document are to be interpreted as described in RFC 2119 [RFC2119]. 81 2. Delegation Details 83 2.1. Relevant Protocol Elements 85 A delegation response will include the following elements: 87 Header Section: fixed length (12 octets) 88 Question Section: original query (name, class, type) 89 Answer Section: empty, or a CNAME/DNAME chain 90 Authority Section: NS RRset (nameserver names) 91 Additional Section: A and AAAA RRsets (nameserver addresses) 93 If the total size of the UDP response exceeds 512 octets or 94 advertised size in EDNS, and if the data that does not fit was 95 "required", then the TC bit will be set (indicating truncation). 96 This will usually cause the requester to retry using TCP, depending 97 on what information was desired and what information was omitted. 98 For example, truncation in the authority section is of no interest to 99 a stub resolver who only plans to consume the answer section. If a 100 retry using TCP is needed, the total cost of the transaction is much 101 higher. See [RFC1123] 6.1.3.2 for details on the requirement that 102 UDP be attempted before falling back to TCP. 104 RRsets are never sent partially unless the TC bit is set to indicate 105 truncation. When the TC bit is set, the final apparent RRset in the 106 final non-empty section must be considered "possibly damaged" (see 107 [RFC1035] 6.2, [RFC2181] 9). 109 With or without truncation, the glue present in the additional data 110 section should be considered "possibly incomplete", and requesters 111 should be prepared to re-query for any damaged or missing RRsets. 112 Note that truncation of the additional data section might not be 113 signaled via the TC bit since additional data is often optional (see 114 discussion in [RFC4472] B). 116 DNS label compression allows the component labels of a domain name to 117 be instantiated exactly once per DNS message, and then referenced 118 with a two-octet "pointer" from other locations in that same DNS 119 message (see [RFC1035] 4.1.4). If all nameserver names in a message 120 share a common parent (for example, all ending in ".ROOT- 121 SERVERS.NET"), then more space will be available for incompressible 122 data (such as nameserver addresses). 124 The query name can be as long as 255 octets of network data. In this 125 worst case scenario, the question section will be 259 octets in size, 126 which would leave only 240 octets for the authority and additional 127 sections (after deducting 12 octets for the fixed length header) in a 128 referral. 130 2.2. Advice to Zone Owners 132 Average and maximum question section sizes can be predicted by the 133 zone owner, since they will know what names actually exist, and can 134 measure which ones are queried for most often. Note that if the zone 135 contains any wildcards, it is possible for maximum length queries to 136 require positive responses, but that it is reasonable to expect 137 truncation and TCP retry in that case. For cost and performance 138 reasons, the majority of requests should be satisfied without 139 truncation or TCP retry. 141 Some queries to non-existing names can be large, but this is not a 142 problem because negative responses need not contain any answer, 143 authority or additional records. See [RFC2308] 2.1 for more 144 information about the format of negative responses. 146 The minimum useful number of name servers is two, for redundancy (see 147 [RFC1034] 4.1). A zone's name servers should be reachable by all IP 148 protocols versions (e.g., IPv4 and IPv6) in common use. As long as 149 the servers are well managed, the server serving IPv6 might be 150 different from the server serving IPv4 sharing the same server name. 151 It is important to ensure that a zone should have servers reachable 152 by all IP protocol in common use (e.g., IPv4 and IPv6). 154 The best case is no truncation at all. This is because many 155 requesters will retry using TCP immediately, or will automatically 156 requery for RRsets that are possibly truncated, without considering 157 whether the omitted data was actually necessary. 159 Anycasting[RFC3258] is a useful tool for performance and reliability 160 without increasing the size of referral response. 162 While it is irrelevant to the response size issue, all zones have to 163 be served via IPv4 as well to avoid name space 164 fragmentation[RFC3901]. 166 2.3. Advice to Server Implementors 168 Each NS RR for a zone will add 12 fixed octets (name, type, class, 169 ttl, and rdlen) plus 2 to 255 variable octets (for the NSDNAME). 170 Each A RR will require 16 octets, and each AAAA RR will require 28 171 octets. 173 While DNS distinguishes between necessary and optional resource 174 records, this distinction is according to protocol elements necessary 175 to signify facts, and takes no official notice of protocol content 176 necessary to ensure correct operation. For example, a nameserver 177 name that is in or below the zone cut being described by a delegation 178 is "necessary content", since there is no way to reach that zone 179 unless the parent zone's delegation includes "glue records" 180 describing that name server's addresses. 182 Recall that the TC bit is only set when the required RRset can not be 183 included in its entirety (see [RFC2181] 9). Even when some of the 184 RRsets to be included in the additional section are not fit in the 185 response size, the TC bit isn't set. These RRsets may be important 186 for a referral. Some DNS implementations try to resolve these 187 missing glue records separately which will introduce extra queries 188 and extra time to resolve a given name. 190 A delegation response should prioritize glue records as follows. 192 first: 193 All glue RRsets for one name server whose name is in or below the 194 zone being delegated, or which has multiple address RRsets 195 (currently A and AAAA), or preferably both; 196 second: 197 Alternate between adding all glue RRsets for any name servers 198 whose names are in or below the zone being delegated, and all 199 glue RRsets for any name servers who have multiple address RRsets 200 (currently A and AAAA); 201 thence: 202 All other glue RRsets, in any order. 204 Whenever there are multiple candidates for a position in this 205 priority scheme, one should be chosen on a round-robin or fully 206 random basis. The goal of this priority scheme is to offer 207 "necessary" glue first, avoiding silent truncation for this glue if 208 possible. 210 If any "necessary content" is silently truncated, then it is 211 advisable that the TC bit be set in order to force a TCP retry, 212 rather than have the zone be unreachable. Note that a parent 213 server's proper response to a query for in-child glue or below-child 214 glue is a referral rather than an answer, and that this referral must 215 be able to contain the in-child or below-child glue, and that in 216 outlying cases, only EDNS or TCP will be large enough to contain that 217 data. 219 3. Analysis 221 An instrumented protocol trace of a best case delegation response is 222 shown in Figure 1. Note that 13 servers are named, and 13 addresses 223 are given. This query was artificially designed to exactly reach the 224 512 octets limit. 226 ;; flags: qr rd; QUERY: 1, ANS: 0, AUTH: 13, ADDIT: 13 227 ;; QUERY SECTION: 228 ;; [23456789.123456789.123456789.\ 229 123456789.123456789.123456789.com A IN] ;; @80 231 ;; AUTHORITY SECTION: 232 com. 86400 NS E.GTLD-SERVERS.NET. ;; @112 233 com. 86400 NS F.GTLD-SERVERS.NET. ;; @128 234 com. 86400 NS G.GTLD-SERVERS.NET. ;; @144 235 com. 86400 NS H.GTLD-SERVERS.NET. ;; @160 236 com. 86400 NS I.GTLD-SERVERS.NET. ;; @176 237 com. 86400 NS J.GTLD-SERVERS.NET. ;; @192 238 com. 86400 NS K.GTLD-SERVERS.NET. ;; @208 239 com. 86400 NS L.GTLD-SERVERS.NET. ;; @224 240 com. 86400 NS M.GTLD-SERVERS.NET. ;; @240 241 com. 86400 NS A.GTLD-SERVERS.NET. ;; @256 242 com. 86400 NS B.GTLD-SERVERS.NET. ;; @272 243 com. 86400 NS C.GTLD-SERVERS.NET. ;; @288 244 com. 86400 NS D.GTLD-SERVERS.NET. ;; @304 246 ;; ADDITIONAL SECTION: 247 A.GTLD-SERVERS.NET. 86400 A 192.5.6.30 ;; @320 248 B.GTLD-SERVERS.NET. 86400 A 192.33.14.30 ;; @336 249 C.GTLD-SERVERS.NET. 86400 A 192.26.92.30 ;; @352 250 D.GTLD-SERVERS.NET. 86400 A 192.31.80.30 ;; @368 251 E.GTLD-SERVERS.NET. 86400 A 192.12.94.30 ;; @384 252 F.GTLD-SERVERS.NET. 86400 A 192.35.51.30 ;; @400 253 G.GTLD-SERVERS.NET. 86400 A 192.42.93.30 ;; @416 254 H.GTLD-SERVERS.NET. 86400 A 192.54.112.30 ;; @432 255 I.GTLD-SERVERS.NET. 86400 A 192.43.172.30 ;; @448 256 J.GTLD-SERVERS.NET. 86400 A 192.48.79.30 ;; @464 257 K.GTLD-SERVERS.NET. 86400 A 192.52.178.30 ;; @480 258 L.GTLD-SERVERS.NET. 86400 A 192.41.162.30 ;; @496 259 M.GTLD-SERVERS.NET. 86400 A 192.55.83.30 ;; @512 261 ;; MSG SIZE sent: 80 rcvd: 512 263 Figure 1 265 For longer query names, the number of address records supplied will 266 be lower. Furthermore, it is only by using a common parent name 267 (which is "GTLD-SERVERS.NET" in this example) that all 13 addresses 268 are able to fit, due to the use of DNS compression pointers in the 269 last 12 occurrences of the parent domain name. The following outputs 270 shown in Figure 2 and Figure 3 from a response simulator in 271 Appendix A written in perl[PERL] demonstrate these properties. 273 % perl respsize.pl a.dns.br b.dns.br c.dns.br d.dns.br 274 a.dns.br requires 10 bytes 275 b.dns.br requires 4 bytes 276 c.dns.br requires 4 bytes 277 d.dns.br requires 4 bytes 278 # of NS: 4 279 For maximum size query (255 byte): 280 only A is considered: # of A is 4 (green) 281 A and AAAA are considered: # of A+AAAA is 3 (yellow) 282 preferred-glue A is assumed: # of A is 4, # of AAAA is 3 (yellow) 283 For average size query (64 byte): 284 only A is considered: # of A is 4 (green) 285 A and AAAA are considered: # of A+AAAA is 4 (green) 286 preferred-glue A is assumed: # of A is 4, # of AAAA is 4 (green) 288 Figure 2 290 % perl respsize.pl ns-ext.isc.org ns.psg.com ns.ripe.net ns.eu.int 291 ns-ext.isc.org requires 16 bytes 292 ns.psg.com requires 12 bytes 293 ns.ripe.net requires 13 bytes 294 ns.eu.int requires 11 bytes 295 # of NS: 4 296 For maximum size query (255 byte): 297 only A is considered: # of A is 4 (green) 298 A and AAAA are considered: # of A+AAAA is 3 (yellow) 299 preferred-glue A is assumed: # of A is 4, # of AAAA is 2 (yellow) 300 For average size query (64 byte): 301 only A is considered: # of A is 4 (green) 302 A and AAAA are considered: # of A+AAAA is 4 (green) 303 preferred-glue A is assumed: # of A is 4, # of AAAA is 4 (green) 305 Figure 3 307 Here we use the term "green" if all address records could fit, or 308 "yellow" if two or more could fit, or "orange" if only one could fit, 309 or "red" if no address record could fit. It's clear that without a 310 common parent for nameserver names, much space would be lost. For 311 these examples we use an average/common name size of 15 octets, 312 befitting our assumption of GTLD-SERVERS.NET as our common parent 313 name. 315 We're assuming a medium query name size of 64 since that is the 316 typical size seen in trace data at the time of this writing. If 317 Internationalized Domain Name (IDN) or any other technology which 318 results in larger query names be deployed significantly in advance of 319 EDNS, then new measurements and new estimates will have to be made. 321 4. Conclusions 323 The current practice of giving all nameserver names a common parent 324 (such as GTLD-SERVERS.NET or ROOT-SERVERS.NET) saves space in DNS 325 responses and allows for more nameservers to be enumerated than would 326 otherwise be possible, since the common parent domain name only 327 appears once in a DNS message and is referred to via "compression 328 pointers" thereafter. 330 If all nameserver names for a zone share a common parent, then it is 331 operationally advisable to make all servers for the zone thus served 332 also be authoritative for the zone of that common parent. For 333 example, the root name servers (?.ROOT-SERVERS.NET) can answer 334 authoritatively for the ROOT-SERVERS.NET zone. This is to ensure 335 that the zone's servers always have the zone's nameservers' glue 336 available when delegating, and will be able to respond with answers 337 rather than referrals if a requester who wants that glue comes back 338 asking for it. In this case the name server will likely be a 339 "stealth server" -- authoritative but unadvertised in the glue zone's 340 NS RRset. See [RFC1996] 2 for more information about stealth 341 servers. 343 Thirteen (13) is the effective maximum number of nameserver names 344 usable with traditional (non-extended) DNS, assuming a common parent 345 domain name, and given that implicit referral response truncation is 346 undesirable in the average case. 348 More than one address records in a protocol family per a server is 349 inadvisable since the necessary glue RRsets (A or AAAA) are 350 atomically indivisible, and will be larger than a single resource 351 record. Larger RRsets are more likely to lead to or encounter 352 truncation. 354 More than one address records across protocol families is less likely 355 to lead to or encounter truncation, partly because multiprotocol 356 clients, which are required to handle larger RRsets such as AAAA RRs, 357 are more likely to speak EDNS which can use a larger UDP response 358 size limit, and partly because the resource records (A and AAAA) are 359 in different RRsets and are therefore divisible from each other. 361 Name server names which are at or below the zone they serve are more 362 sensitive to referral response truncation, and glue records for them 363 should be considered "more important" than other glue records, in the 364 assembly of referral responses. 366 If a zone is served by thirteen (13) name servers having a common 367 parent name (such as ?.ROOT-SERVERS.NET) and each such name server 368 has a single address record in some protocol family (e.g., an A RR), 369 then all thirteen name servers or any subset thereof could have 370 address records in a second protocol family by adding a second 371 address record (e.g., an AAAA RR) without reducing the reachability 372 of the zone thus served. 374 5. Security Considerations 376 The recommendations contained in this document have no known security 377 implications. 379 6. IANA Considerations 381 This document does not call for changes or additions to any IANA 382 registry. 384 7. Acknowledgement 386 The authors thank Peter Koch, Rob Austein, Joe Abley, Mark Andrews, 387 Kenji Rikitake, Stephane Bortzmeyerand, Olafur Gudmundsson, and 388 Alfred Hines for their valuable comments and suggestions. 390 This work was supported by the US National Science Foundation 391 (research grant SCI-0427144) and DNS-OARC. 393 8. Normative References 395 [PERL] Wall, L., Christiansen, T., and j. Orwant, "Programing 396 Perl", July 2000. 398 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 399 STD 13, RFC 1034, November 1987. 401 [RFC1035] Mockapetris, P., "Domain names - implementation and 402 specification", STD 13, RFC 1035, November 1987. 404 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 405 and Support", STD 3, RFC 1123, October 1989. 407 [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone 408 Changes (DNS NOTIFY)", RFC 1996, August 1996. 410 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 411 Requirement Levels", BCP 14, RFC 2119, March 1997. 413 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 414 Specification", RFC 2181, July 1997. 416 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS 417 NCACHE)", RFC 2308, March 1998. 419 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", 420 RFC 2671, August 1999. 422 [RFC3226] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver 423 message size requirements", RFC 3226, December 2001. 425 [RFC3258] Hardie, T., "Distributing Authoritative Name Servers via 426 Shared Unicast Addresses", RFC 3258, April 2002. 428 [RFC3901] Durand, A. and J. Ihren, "DNS IPv6 Transport Operational 429 Guidelines", BCP 91, RFC 3901, September 2004. 431 [RFC4472] Durand, A., Ihren, J., and P. Savola, "Operational 432 Considerations and Issues with IPv6 DNS", RFC 4472, 433 April 2006. 435 Appendix A. The response simulator program 437 #!/usr/bin/perl 438 # 439 # SYNOPSIS 440 # respsize.pl [ -z zone ] fqdn_ns1 fqdn_ns2 ... 441 # if all queries are assumed to have a same zone suffix, 442 # such as "jp" in JP TLD servers, specify it in -z option 443 # 444 use strict; 445 use Getopt::Std; 447 my ($sz_msg) = (512); 448 my ($sz_header, $sz_ptr, $sz_rr_a, $sz_rr_aaaa) = (12, 2, 16, 28); 449 my ($sz_type, $sz_class, $sz_ttl, $sz_rdlen) = (2, 2, 4, 2); 450 my (%namedb, $name, $nssect, %opts, $optz); 451 my $n_ns = 0; 453 getopt('z', %opts); 454 if (defined($opts{'z'})) { 455 server_name_len($opts{'z'}); # just register it 457 } 459 foreach $name (@ARGV) { 460 my $len; 461 $n_ns++; 462 $len = server_name_len($name); 463 print "$name requires $len bytes\n"; 464 $nssect += $sz_ptr + $sz_type + $sz_class + $sz_ttl 465 + $sz_rdlen + $len; 466 } 467 print "# of NS: $n_ns\n"; 468 arsect(255, $nssect, $n_ns, "maximum"); 469 arsect(64, $nssect, $n_ns, "average"); 471 sub server_name_len { 472 my ($name) = @_; 473 my (@labels, $len, $n, $suffix); 475 $name =~ tr/A-Z/a-z/; 476 @labels = split(/\./, $name); 477 $len = length(join('.', @labels)) + 2; 478 for ($n = 0; $#labels >= 0; $n++, shift @labels) { 479 $suffix = join('.', @labels); 480 return length($name) - length($suffix) + $sz_ptr 481 if (defined($namedb{$suffix})); 482 $namedb{$suffix} = 1; 483 } 484 return $len; 485 } 487 sub arsect { 488 my ($sz_query, $nssect, $n_ns, $cond) = @_; 489 my ($space, $n_a, $n_a_aaaa, $n_p_aaaa, $ansect); 490 $ansect = $sz_query + $sz_type + $sz_class; 491 $space = $sz_msg - $sz_header - $ansect - $nssect; 492 $n_a = atmost(int($space / $sz_rr_a), $n_ns); 493 $n_a_aaaa = atmost(int($space 494 / ($sz_rr_a + $sz_rr_aaaa)), $n_ns); 495 $n_p_aaaa = atmost(int(($space - $sz_rr_a * $n_ns) 496 / $sz_rr_aaaa), $n_ns); 497 printf "For %s size query (%d byte):\n", $cond, $sz_query; 498 printf " only A is considered: "; 499 printf "# of A is %d (%s)\n", $n_a, &judge($n_a, $n_ns); 500 printf " A and AAAA are considered: "; 501 printf "# of A+AAAA is %d (%s)\n", 502 $n_a_aaaa, &judge($n_a_aaaa, $n_ns); 503 printf " preferred-glue A is assumed: "; 504 printf "# of A is %d, # of AAAA is %d (%s)\n", 505 $n_a, $n_p_aaaa, &judge($n_p_aaaa, $n_ns); 506 } 508 sub judge { 509 my ($n, $n_ns) = @_; 510 return "green" if ($n >= $n_ns); 511 return "yellow" if ($n >= 2); 512 return "orange" if ($n == 1); 513 return "red"; 514 } 516 sub atmost { 517 my ($a, $b) = @_; 518 return 0 if ($a < 0); 519 return $b if ($a > $b); 520 return $a; 521 } 523 Authors' Addresses 525 Paul Vixie 526 Internet Systems Consortium 527 950 Charter Street 528 Redwood City, CA 94063 529 US 531 Phone: +1 650 423 1300 532 Email: paul@vix.com 534 Akira Kato 535 The University of Tokyo/WIDE Project 536 Information Technology Center, 2-11-16 Yayoi 537 Bunkyo, Tokyo 113-8658 538 JP 540 Phone: +81 3 5841 2750 541 Email: kato@wide.ad.jp 543 Full Copyright Statement 545 Copyright (C) The IETF Trust (2007). 547 This document is subject to the rights, licenses and restrictions 548 contained in BCP 78, and except as set forth therein, the authors 549 retain all their rights. 551 This document and the information contained herein are provided on an 552 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 553 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 554 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 555 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 556 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 557 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 559 Intellectual Property 561 The IETF takes no position regarding the validity or scope of any 562 Intellectual Property Rights or other rights that might be claimed to 563 pertain to the implementation or use of the technology described in 564 this document or the extent to which any license under such rights 565 might or might not be available; nor does it represent that it has 566 made any independent effort to identify any such rights. Information 567 on the procedures with respect to rights in RFC documents can be 568 found in BCP 78 and BCP 79. 570 Copies of IPR disclosures made to the IETF Secretariat and any 571 assurances of licenses to be made available, or the result of an 572 attempt made to obtain a general license or permission for the use of 573 such proprietary rights by implementers or users of this 574 specification can be obtained from the IETF on-line IPR repository at 575 http://www.ietf.org/ipr. 577 The IETF invites any interested party to bring to its attention any 578 copyrights, patents or patent applications, or other proprietary 579 rights that may cover technology that may be required to implement 580 this standard. Please address the information to the IETF at 581 ietf-ipr@ietf.org. 583 Acknowledgment 585 Funding for the RFC Editor function is provided by the IETF 586 Administrative Support Activity (IASA).