idnits 2.17.1 draft-jeong-dnsop-ipv6-dns-discovery-12.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 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 528. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 539. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 546. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 552. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 (May 16, 2007) is 6162 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '6' is defined on line 427, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 430, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 433, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 446, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 450, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 454, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 458, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2461 (ref. '2') (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2462 (ref. '3') (Obsoleted by RFC 4862) -- Obsolete informational reference (is this intentional?): RFC 3315 (ref. '6') (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3736 (ref. '7') (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3775 (ref. '10') (Obsoleted by RFC 6275) == Outdated reference: A later version (-06) exists of draft-ietf-dnsop-reflectors-are-evil-03 Summary: 3 errors (**), 0 flaws (~~), 9 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Jeong, Ed. 3 Internet-Draft ETRI/University of Minnesota 4 Intended status: Standards Track S. Park 5 Expires: November 17, 2007 SAMSUNG Electronics 6 L. Beloeil 7 France Telecom R&D 8 S. Madanapalli 9 SAMSUNG ISO 10 May 16, 2007 12 IPv6 Router Advertisement Option for DNS Configuration 13 draft-jeong-dnsop-ipv6-dns-discovery-12.txt 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on November 17, 2007. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2007). 44 Abstract 46 This document specifies a new IPv6 Router Advertisement option to 47 allow IPv6 routers to advertise DNS recursive server addresses to 48 IPv6 hosts. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1. Applicability Statements . . . . . . . . . . . . . . . . . 3 54 1.2. Coexistence of RDNSS Option and DHCP Option . . . . . . . 3 55 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 5. Neighbor Discovery Extension . . . . . . . . . . . . . . . . . 5 59 5.1. Recursive DNS Server Option . . . . . . . . . . . . . . . 5 60 5.2. Procedure of DNS Configuration . . . . . . . . . . . . . . 6 61 5.2.1. Procedure in IPv6 Host . . . . . . . . . . . . . . . . 6 62 6. Implementation Considerations . . . . . . . . . . . . . . . . 7 63 6.1. DNS Server List Management . . . . . . . . . . . . . . . . 7 64 6.2. Synchronization between DNS Server List and Resolver 65 Repository . . . . . . . . . . . . . . . . . . . . . . . . 8 66 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 67 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 68 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 69 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 10.1. Normative References . . . . . . . . . . . . . . . . . . . 10 71 10.2. Informative References . . . . . . . . . . . . . . . . . . 10 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 73 Intellectual Property and Copyright Statements . . . . . . . . . . 13 75 1. Introduction 77 Neighbor Discovery (ND) for IP Version 6 and IPv6 Stateless Address 78 Autoconfiguration provide ways to configure either fixed or mobile 79 nodes with one or more IPv6 addresses, default routes and some other 80 parameters [2][3]. To support the access to additional services in 81 the Internet that are identified by a DNS name, such as a web server, 82 the configuration of at least one recursive DNS server is also needed 83 for DNS name resolution. 85 It is infeasible for nomadic hosts, such as laptops, to have to enter 86 a DNS resolver each time they connect to a different wireless LAN 87 (WLAN) such as IEEE 802.11 a/b/g [12]-[15]. Normally, DHCP [6]-[8] 88 is used to locate such resolvers. This document provides an 89 alternate, experimental mechanism which uses a new IPv6 Router 90 Advertisement (RA) option to allow IPv6 routers to advertise DNS 91 recursive server addresses to IPv6 hosts. 93 1.1. Applicability Statements 95 The only standards-track DNS configuration mechanism in the IETF is 96 DHCP, and its support in hosts and routers is necessary for reasons 97 of interoperability. 99 RA-based DNS configuration is a useful, optional alternative in 100 networks where an IPv6 host's address is autoconfigured through IPv6 101 stateless address autoconfiguration, and where the delays in 102 acquiring server addresses and communicating with the servers are 103 critical. RA-based DNS configuration allows the host to acquire the 104 nearest server addresses on every link. Furthermore, it learns these 105 addresses from the same RA message that provides configuration 106 information for the link, thereby avoiding an additional protocol 107 run. This can be beneficial in some mobile environments, such as 108 with Mobile IPv6 [10]. 110 The advantages and disadvantages of the RA-based approach are 111 discussed in [9] along with other approaches, such as the DHCP and 112 Well-known anycast addresses approaches. 114 1.2. Coexistence of RDNSS Option and DHCP Option 116 The RDNSS option and DHCP option can be used together [9]. To order 117 the RA and DHCP approaches, the O (Other stateful configuration) flag 118 can be used in the RA message [2]. If no RDNSS option is included, 119 an IPv6 host may perform DNS configuration through DHCPv6 [6]-[8] 120 regardless of whether the O flag is set or not. 122 2. Definitions 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 126 document are to be interpreted as described in [1]. 128 3. Terminology 130 This document uses the terminology described in [2] and [3]. In 131 addition, four new terms are defined below: 133 o Recursive DNS Server (RDNSS): Server which provides a recursive 134 DNS resolution service for translating domain names into IP 135 addresses as defined in [4] and [5]. 137 o RDNSS Option: IPv6 RA Option to deliver the RDNSS information to 138 the IPv6 hosts [2]. 140 o DNS Server List: Data structure for managing DNS Server 141 Information existing in IPv6 protocol stack in addition to 142 Neighbor Cache and Destination Cache for Neighbor Discovery [2]. 144 o Resolver Repository: Configuration repository with RDNSS addresses 145 which a DNS resolver on the host uses for DNS name resolution, 146 such as Unix resolver file (i.e., /etc/resolv.conf) and Windows 147 registry. 149 4. Overview 151 This document defines a new ND option called RDNSS option that 152 contains the addresses of recursive DNS servers. Existing ND 153 transport mechanisms (i.e., advertisements and solicitations) are 154 used. This works in the same way that hosts learn about routers and 155 prefixes. An IPv6 host can configure the IPv6 addresses of one or 156 more RDNSSes via RA message periodically sent by router or solicited 157 by a Router Solicitation (RS). 159 Through the RDNSS option along with the prefix information option 160 based on the ND protocol ([2] and [3]), an IPv6 host can perform its 161 network configuration of its IPv6 address and RDNSS simultaneously 162 without needing a separate message exchange for the RDNSS 163 information. The RA option for RDNSS can be used on any network that 164 supports the use of ND. 166 This approach requires RDNSS information to be configured in the 167 routers sending the advertisements. The configuration of RDNSS 168 addresses in the routers can be done by manual configuration. The 169 automatic configuration or redistribution of RDNSS information is 170 possible by running a DHCPv6 client running on the router [6]-[8]. 171 The automatic configuration of RDNSS addresses in the routers is out 172 of scope in this document. 174 5. Neighbor Discovery Extension 176 The IPv6 DNS configuration mechanism in this document needs a new ND 177 option in Neighbor Discovery, Recursive DNS Server (RDNSS) option. 179 5.1. Recursive DNS Server Option 181 RDNSS option contains one or more IPv6 addresses of recursive DNS 182 servers. All of the addresses share the same lifetime value. If it 183 is desirable to have different lifetime values, multiple RDNSS 184 options can be used. Figure 1 shows the format of RDNSS option. 186 0 1 2 3 187 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | Type | Length | Reserved | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | Lifetime | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | | 194 : Addresses of IPv6 Recursive DNS Servers : 195 | | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 Figure 1: Recursive DNS Server (RDNSS) Option Format 200 Fields: 202 Type 8-bit identifier of the option type (TBD: IANA) 203 Option Name Type 204 RDNSS option (TBD) 206 Length 8-bit unsigned integer. The length of the 207 option (including the type and length fields) 208 in units of 8 octets. The minimum value is 0x03 209 if one IPv6 address is contained in the option. 210 Every additional RDNSS address increases the 211 length by 0x02. The length field is used by 212 the receiver to determine the number of IPv6 213 addresses in the option. 215 Lifetime 32-bit unsigned integer. The maximum time, in 216 seconds (relative to the time the packet is sent), 217 over which this RDNSS MAY be used for name 218 resolution. Hosts MAY send a Router Solicitation 219 to ensure the RDNSS information is fresh before 220 the interval expires. In order to provide fixed 221 hosts with the stable DNS service and allow mobile 222 hosts to prefer local RDNSSes to remote RDNSSes, 223 the value of lifetime should be at least as long 224 as the Maximum RA Interval (MaxRtrAdvInterval) in 225 RFC 2461, and be at most as long as two times 226 MaxRtrAdvInterval; Lifetime SHOULD be bounded as 227 follows: 228 MaxRtrAdvInterval<=Lifetime<=2*MaxRtrAdvInterval. 229 A value of all one bits (0xffffffff) represents 230 infinity. A value of zero means that the RDNSS 231 MUST no longer be used. 233 Addresses of IPv6 Recursive DNS Servers 234 One or more 128-bit IPv6 addresses of the 235 recursive DNS servers. The number of addresses 236 is determined by the Length field. That is, 237 the number of addresses is equal to 238 (Length - 1) / 2. 240 5.2. Procedure of DNS Configuration 242 The procedure of DNS configuration through RDNSS option is the same 243 as any other ND option [2]. 245 5.2.1. Procedure in IPv6 Host 247 When an IPv6 host receives RDNSS option through RA, it checks whether 248 the option is valid; 250 o If the RDNSS option is present, the host SHOULD copy the option's 251 value into the DNS Server List and the Resolver Repository as long 252 as the value of Length field is greater than or equal to the 253 minimum value (0x03). The host MAY ignore additional RDNSS 254 addresses within an RDNSS option and/or additional RDNSS options 255 within an RA when it has gathered a sufficient number of RDNSSes. 257 o If the RDNSS option is present but invalid (e.g., it has the 258 length less than 0x03), the host SHOULD discard the option. 260 6. Implementation Considerations 262 Note 264 This non-normative section gives some hints for implementing the 265 processing of RDNSS option in IPv6 host. 267 For the configuration and management of RDNSS information, the 268 advertised RDNSS addresses can be stored and managed in both the DNS 269 Server List and the Resolver Repository. 271 In environments where the RDNSS information is stored in user space 272 and ND runs in the kernel, it is necessary to synchronize the DNS 273 Server List for RDNSSes in kernel space and the Resolver Repository 274 in user space. For the synchronization, the implementation where ND 275 works in the kernel should provide the write operation for updating 276 RDNSS information from the kernel to the Resolver Repository. One 277 simple approach to perform this is to have a daemon around (or a 278 program that is called at the defined intervals) that keeps 279 monitoring the lifetime of RDNSSes all the time. Whenever there is 280 an expired entry in the DNS Server List, the daemon can delete the 281 corresponding entry from the Resolver Repository. 283 6.1. DNS Server List Management 285 The kernel or user-space process (depending on where RAs are 286 processed) should maintain a data structure called DNS Server List 287 which keeps the list of RDNSSes. Each entry of DNS Server List 288 consists of RDNSS address and Expiration-time as follows: 290 o RDNSS address: IPv6 address of Recursive DNS Server which is 291 available for recursive DNS resolution service in the network 292 advertising the RDNSS option; such a network is called site in 293 this document. 295 o Expiration-time: Expiration time field giving the time when this 296 entry becomes invalid. Expiration-time is set to the value of 297 Lifetime field of RDNSS option plus the current system time. 298 Whenever a new RDNSS option with the same address is received, 299 this field is updated to have a new expiration time. When 300 Expiration-time becomes less than the current system time, this 301 entry is regared as expired. 303 Note 305 An RDNSS MUST be used only as long as both the RA router lifetime and 306 the RDNSS option lifetime have not expired. The reason is that the 307 RDNSS may not be currently reachable or may not provide service to 308 the host's current address (e.g., due to the network ingress 309 filtering [16][17]). 311 6.2. Synchronization between DNS Server List and Resolver Repository 313 When an IPv6 host receives the information of multiple RDNSSes within 314 a site through an RA message with RDNSS option(s), it stores the 315 RDNSS addresses in order into both the DNS Server List and the 316 Resolver Repository. The processing of the RDNSS option included in 317 RA message is as follows: 319 Step (a): Receive and parse RDNSS option(s). For the RDNSS 320 addresses in each RDNSS option, perform Step (b) through Step (d). 321 Note that Step (e) is performed whenever an entry expires in the 322 DNS Server List. 324 Step (b): For each RDNSS address, check the following: If the 325 RDNSS address already exists in the DNS Server List and the RDNSS 326 option's "Lifetime" field is set to zero, delete the corresponding 327 RDNSS entry from both the DNS Server List and the Resolver 328 Repository in order to let the RDNSS be not used any more for 329 certain reasons in network management, e.g., the breakdown of the 330 RDNSS or a renumbering situation. The processing of this RDNSS 331 address is finished here. Otherwise, go to Step (c). 333 Step (c): For each RDNSS address, if it already exists in the DNS 334 Server List, then just update the value of "Expiration-time" field 335 to have a new expiration time with the RDNSS option's "Lifetime" 336 field and the current system time. Otherwise, go to Step (d). 338 Step (d): For each RDNSS address, if it does not exist in the DNS 339 Server List, register the RDNSS address and lifetime with the DNS 340 Server List and then insert the RDNSS address in front of the 341 Resolver Repository. In the case where the data structure for the 342 DNS Server List is full of RDNSS entries, delete from the DNS 343 Server List the entry with the smallest expiration time that will 344 expire first. The corresponding RDNSS address is also deleted 345 from the Resolver Repository. In the order in the RDNSS option, 346 position the newly added RDNSS addresses in the front of the 347 Resolver Repository so that the RDNSS addresses may be preferred 348 according to their order in the RDNSS option for the DNS name 349 resolution. The processing of these RDNSS addresses is finished 350 here. Note that, in the case where there are several routers 351 advertising RDNSS option(s) in a subnet, the RDNSSes announced 352 lately are more preferred. 354 Step (e): Delete each expired entry from DNS Server List and the 355 RDNSS address corresponding to the entry from the Resolver 356 Repository. 358 7. Security Considerations 360 The security of RA option for RDNSS might be worse than ND protocol 361 security [2]. However, any new vulnerability is not known yet in 362 this RA option. In this context, it can be claimed that the 363 vulnerability of ND is not worse and is a subset of the attacks that 364 any node attached to a LAN can do independently of ND. A malicious 365 node on a LAN can promiscuously receive packets for any router's MAC 366 address and send packets with the router's MAC address as the source 367 MAC address in the L2 header. As a result, the L2 switches send 368 packets addressed to the router to the malicious node. Also, this 369 attack can send redirects that tell the hosts to send their traffic 370 somewhere else. The malicious node can send unsolicited RA or NA 371 replies, answer RS or NS requests, etc. Also, an attacker could 372 configure a host to send out RA with a fraudulent RDNSS address, 373 which is presumably an easier avenue of attack than becoming a rogue 374 router and having to process all traffic for the subnet. It is 375 necessary to disable the RA RDNSS option in both routers and clients 376 administratively to avoid this problem. All of this can be done 377 independently of implementing ND. Therefore, it can be claimed that 378 the RA option for RDNSS has vulnerabilities similar to those existing 379 in current mechanisms. 381 If Secure Neighbor Discovery (SEND) protocol is used as the security 382 mechanism for ND, all the ND options including RDNSS option are also 383 automatically included in the signatures [11], so the RDNSS transport 384 is integrity-protected. However, since any valid SEND node can still 385 insert RDNSS options, SEND cannot verify who is or is not authorized 386 to send the options. 388 8. IANA Considerations 390 The IANA is requested to assign a new IPv6 Neighbor Discovery Option 391 type for the RDNSS option defined in this document. 393 Option Name Type 394 RDNSS option (TBD) 396 The IANA registry for these options is: 398 http://www.iana.org/assignments/icmpv6-parameters 400 9. Acknowledgements 402 This draft has greatly benefited from inputs by Robert Hinden, Pekka 403 Savola, Iljitsch van Beijnum, Brian Haberman and Tim Chown. The 404 authors appreciate their contribution. 406 10. References 408 10.1. Normative References 410 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 411 Levels", BCP 14, RFC 2119, March 1997. 413 [2] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery 414 for IP Version 6 (IPv6)", RFC 2461, December 1998. 416 [3] Thomson, S. and T. Narten, "IPv6 Stateless Address 417 Autoconfiguration", RFC 2462, December 1998. 419 10.2. Informative References 421 [4] Mockapetris, P., "Domain Names - Concepts and Facilities", 422 RFC 1034, November 1987. 424 [5] Mockapetris, P., "Domain Names - Implementation and 425 Specification", RFC 1035, November 1987. 427 [6] Droms, R., Ed., "Dynamic Host Configuration Protocol for IPv6 428 (DHCPv6)", RFC 3315, July 2003. 430 [7] Droms, R., "Stateless Dynamic Host Configuration Protocol 431 (DHCP) Service for IPv6", RFC 3736, April 2004. 433 [8] Droms, R., Ed., "DNS Configuration options for Dynamic Host 434 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 435 December 2003. 437 [9] Jeong, J., Ed., "IPv6 Host Configuration of DNS Server 438 Information Approaches", RFC 4339, February 2006. 440 [10] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 441 IPv6", RFC 3775, June 2004. 443 [11] Arkko, J., Ed., "SEcure Neighbor Discovery (SEND)", RFC 3971, 444 March 2005. 446 [12] ANSI/IEEE Std 802.11, "Part 11: Wireless LAN Medium Access 447 Control (MAC) and Physical Layer (PHY) Specifications", 448 March 1999. 450 [13] IEEE Std 802.11a, "Part 11: Wireless LAN Medium Access Control 451 (MAC) and Physical Layer (PHY) specifications: High-speed 452 Physical Layer in the 5 GHZ Band", September 1999. 454 [14] IEEE Std 802.11b, "Part 11: Wireless LAN Medium Access Control 455 (MAC) and Physical Layer (PHY) specifications: Higher-Speed 456 Physical Layer Extension in the 2.4 GHz Band", September 1999. 458 [15] IEEE P802.11g/D8.2, "Part 11: Wireless LAN Medium Access 459 Control (MAC) and Physical Layer (PHY) specifications: Further 460 Higher Data Rate Extension in the 2.4 GHz Band", April 2003. 462 [16] Damas, J. and F. Neves, "Preventing Use of Nameservers in 463 Reflector Attacks", 464 draft-ietf-dnsop-reflectors-are-evil-03.txt (Work in Progress), 465 February 2007. 467 [17] Ferguson, P. and D. Senie, "Network Ingress Filtering: 468 Defeating Denial of Service Attacks which employ IP Source 469 Address Spoofing", BCP 38, RFC 2827, May 2000. 471 Authors' Addresses 473 Jaehoon Paul Jeong (editor) 474 ETRI/Department of Computer Science and Engineering 475 University of Minnesota 476 117 Pleasant Street SE 477 Minneapolis, MN 55455 478 USA 480 Phone: +1 651 587 7774 481 Fax: +1 612 625 0572 482 Email: jjeong@cs.umn.edu 483 URI: http://www.cs.umn.edu/~jjeong/ 484 Soohong Daniel Park 485 Mobile Platform Laboratory 486 SAMSUNG Electronics 487 416 Maetan-3dong, Yeongtong-Gu 488 Suwon, Gyeonggi-Do 443-742 489 Korea 491 Phone: +82 31 200 4508 492 Email: soohong.park@samsung.com 494 Luc Beloeil 495 France Telecom R&D 496 42, rue des coutures 497 BP 6243 498 14066 CAEN Cedex 4 499 France 501 Phone: +33 02 3175 9391 502 Email: luc.beloeil@francetelecom.com 504 Syam Madanapalli 505 SAMSUNG India Software Operations 506 J. P. Techno Park, 3/1 507 Millers Road 508 Bangalore 560052 509 India 511 Phone: +91 80 51197777 512 Email: smadanapalli@gmail.com 514 Full Copyright Statement 516 Copyright (C) The IETF Trust (2007). 518 This document is subject to the rights, licenses and restrictions 519 contained in BCP 78, and except as set forth therein, the authors 520 retain all their rights. 522 This document and the information contained herein are provided on an 523 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 524 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 525 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 526 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 527 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 528 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 530 Intellectual Property 532 The IETF takes no position regarding the validity or scope of any 533 Intellectual Property Rights or other rights that might be claimed to 534 pertain to the implementation or use of the technology described in 535 this document or the extent to which any license under such rights 536 might or might not be available; nor does it represent that it has 537 made any independent effort to identify any such rights. Information 538 on the procedures with respect to rights in RFC documents can be 539 found in BCP 78 and BCP 79. 541 Copies of IPR disclosures made to the IETF Secretariat and any 542 assurances of licenses to be made available, or the result of an 543 attempt made to obtain a general license or permission for the use of 544 such proprietary rights by implementers or users of this 545 specification can be obtained from the IETF on-line IPR repository at 546 http://www.ietf.org/ipr. 548 The IETF invites any interested party to bring to its attention any 549 copyrights, patents or patent applications, or other proprietary 550 rights that may cover technology that may be required to implement 551 this standard. Please address the information to the IETF at 552 ietf-ipr@ietf.org. 554 Acknowledgment 556 Funding for the RFC Editor function is provided by the IETF 557 Administrative Support Activity (IASA).