diff options
author | Kozlov Dmitry <dima@server> | 2011-08-23 18:02:22 +0400 |
---|---|---|
committer | Kozlov Dmitry <dima@server> | 2011-08-23 18:02:22 +0400 |
commit | 9bc3fa4216fb2ad043232584b5a5e134e64830ed (patch) | |
tree | 910b5a0809a272d8525ff1ed2c1265b7f7d53c3d /rfc/rfc5006.txt | |
parent | e281cbf20eb2e8f36ef5037e138fdf3798f1897d (diff) | |
download | accel-ppp-9bc3fa4216fb2ad043232584b5a5e134e64830ed.tar.gz accel-ppp-9bc3fa4216fb2ad043232584b5a5e134e64830ed.zip |
ppp: ipv6: multiple prefixes, route option, rdnss option implementation
Diffstat (limited to 'rfc/rfc5006.txt')
-rw-r--r-- | rfc/rfc5006.txt | 675 |
1 files changed, 675 insertions, 0 deletions
diff --git a/rfc/rfc5006.txt b/rfc/rfc5006.txt new file mode 100644 index 0000000..056f149 --- /dev/null +++ b/rfc/rfc5006.txt @@ -0,0 +1,675 @@ + + + + + + +Network Working Group J. Jeong, Ed. +Request for Comments: 5006 ETRI/University of Minnesota +Category: Experimental S. Park + SAMSUNG Electronics + L. Beloeil + France Telecom R&D + S. Madanapalli + Ordyn Technologies + September 2007 + + + IPv6 Router Advertisement Option for DNS Configuration + +Status of This Memo + + This memo defines an Experimental Protocol for the Internet + community. It does not specify an Internet standard of any kind. + Discussion and suggestions for improvement are requested. + Distribution of this memo is unlimited. + +Abstract + + This document specifies a new IPv6 Router Advertisement option to + allow IPv6 routers to advertise DNS recursive server addresses to + IPv6 hosts. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 1.1. Applicability Statements . . . . . . . . . . . . . . . . . 2 + 1.2. Coexistence of RDNSS Option and DHCP Option . . . . . . . 2 + 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 5. Neighbor Discovery Extension . . . . . . . . . . . . . . . . . 4 + 5.1. Recursive DNS Server Option . . . . . . . . . . . . . . . 4 + 5.2. Procedure of DNS Configuration . . . . . . . . . . . . . . 5 + 5.2.1. Procedure in IPv6 Host . . . . . . . . . . . . . . . . 5 + 6. Implementation Considerations . . . . . . . . . . . . . . . . 6 + 6.1. DNS Server List Management . . . . . . . . . . . . . . . . 6 + 6.2. Synchronization between DNS Server List and Resolver + Repository . . . . . . . . . . . . . . . . . . . . . . . . 7 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 + 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 + 10.1. Normative References . . . . . . . . . . . . . . . . . . . 9 + 10.2. Informative References . . . . . . . . . . . . . . . . . . 9 + + + +Jeong, et al. Experimental [Page 1] + +RFC 5006 IPv6 RA Option for DNS Configuration September 2007 + + +1. Introduction + + Neighbor Discovery (ND) for IP Version 6 and IPv6 Stateless Address + Autoconfiguration provide ways to configure either fixed or mobile + nodes with one or more IPv6 addresses, default routers and some other + parameters [2][3]. To support the access to additional services in + the Internet that are identified by a DNS name, such as a web server, + the configuration of at least one recursive DNS server is also needed + for DNS name resolution. + + It is infeasible for nomadic hosts, such as laptops, to be configured + manually with a DNS resolver each time they connect to a different + wireless LAN (WLAN) such as IEEE 802.11 a/b/g [12]-[15]. Normally, + DHCP [6]-[8] is used to locate such resolvers. This document + provides an alternate, experimental mechanism which uses a new IPv6 + Router Advertisement (RA) option to allow IPv6 routers to advertise + DNS recursive server addresses to IPv6 hosts. + +1.1. Applicability Statements + + The only standards-track DNS configuration mechanism in the IETF is + DHCP, and its support in hosts and routers is necessary for reasons + of interoperability. + + RA-based DNS configuration is a useful, optional alternative in + networks where an IPv6 host's address is autoconfigured through IPv6 + stateless address autoconfiguration, and where the delays in + acquiring server addresses and communicating with the servers are + critical. RA-based DNS configuration allows the host to acquire the + nearest server addresses on every link. Furthermore, it learns these + addresses from the same RA message that provides configuration + information for the link, thereby avoiding an additional protocol + run. This can be beneficial in some mobile environments, such as + with Mobile IPv6 [10]. + + The advantages and disadvantages of the RA-based approach are + discussed in [9] along with other approaches, such as the DHCP and + well-known anycast addresses approaches. + +1.2. Coexistence of RDNSS Option and DHCP Option + + The RDNSS (Recursive DNS Server) option and DHCP option can be used + together [9]. To order the RA and DHCP approaches, the O (Other + stateful configuration) flag can be used in the RA message [2]. If + no RDNSS option is included in the RA messages, an IPv6 host may + perform DNS configuration through DHCPv6 [6]-[8] regardless of + whether the O flag is set or not. + + + + +Jeong, et al. Experimental [Page 2] + +RFC 5006 IPv6 RA Option for DNS Configuration September 2007 + + +2. Definitions + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [1]. + +3. Terminology + + This document uses the terminology described in [2] and [3]. In + addition, four new terms are defined below: + + o Recursive DNS Server (RDNSS): Server which provides a recursive + DNS resolution service for translating domain names into IP + addresses as defined in [4] and [5]. + + o RDNSS Option: IPv6 RA option to deliver the RDNSS information to + IPv6 hosts [2]. + + o DNS Server List: A data structure for managing DNS Server + Information in the IPv6 protocol stack in addition to the Neighbor + Cache and Destination Cache for Neighbor Discovery [2]. + + o Resolver Repository: Configuration repository with RDNSS addresses + that a DNS resolver on the host uses for DNS name resolution; for + example, the Unix resolver file (i.e., /etc/resolv.conf) and + Windows registry. + +4. Overview + + This document defines a new ND option called RDNSS option that + contains the addresses of recursive DNS servers. Existing ND + transport mechanisms (i.e., advertisements and solicitations) are + used. This works in the same way that hosts learn about routers and + prefixes. An IPv6 host can configure the IPv6 addresses of one or + more RDNSSes via RA messages periodically sent by a router or + solicited by a Router Solicitation (RS). + + Through the RDNSS option, along with the prefix information option + based on the ND protocol ([2] and [3]), an IPv6 host can perform + network configuration of its IPv6 address and RDNSS simultaneously + without needing a separate message exchange for the RDNSS + information. The RA option for RDNSS can be used on any network that + supports the use of ND. + + This approach requires RDNSS information to be configured in the + routers sending the advertisements. The configuration of RDNSS + addresses in the routers can be done by manual configuration. The + automatic configuration or redistribution of RDNSS information is + + + +Jeong, et al. Experimental [Page 3] + +RFC 5006 IPv6 RA Option for DNS Configuration September 2007 + + + possible by running a DHCPv6 client on the router [6]-[8]. The + automatic configuration of RDNSS addresses in routers is out of scope + for this document. + +5. Neighbor Discovery Extension + + The IPv6 DNS configuration mechanism in this document needs a new ND + option in Neighbor Discovery: the Recursive DNS Server (RDNSS) + option. + +5.1. Recursive DNS Server Option + + The RDNSS option contains one or more IPv6 addresses of recursive DNS + servers. All of the addresses share the same lifetime value. If it + is desirable to have different lifetime values, multiple RDNSS + options can be used. Figure 1 shows the format of the RDNSS option. + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Lifetime | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + : Addresses of IPv6 Recursive DNS Servers : + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 1: Recursive DNS Server (RDNSS) Option Format + + Fields: + + Type 8-bit identifier of the RDNSS option type as assigned + by the IANA: 25 + + Length 8-bit unsigned integer. The length of the option + (including the Type and Length fields) is in units of + 8 octets. The minimum value is 3 if one IPv6 address + is contained in the option. Every additional RDNSS + address increases the length by 2. The Length field + is used by the receiver to determine the number of + IPv6 addresses in the option. + + + + + + + + +Jeong, et al. Experimental [Page 4] + +RFC 5006 IPv6 RA Option for DNS Configuration September 2007 + + + Lifetime 32-bit unsigned integer. The maximum time, in + seconds (relative to the time the packet is sent), + over which this RDNSS address MAY be used for name + resolution. Hosts MAY send a Router Solicitation to + ensure the RDNSS information is fresh before the + interval expires. In order to provide fixed hosts + with stable DNS service and allow mobile hosts to + prefer local RDNSSes to remote RDNSSes, the value of + Lifetime should be at least as long as the Maximum RA + Interval (MaxRtrAdvInterval) in RFC 4861, and be at + most as long as two times MaxRtrAdvInterval; Lifetime + SHOULD be bounded as follows: MaxRtrAdvInterval <= + Lifetime <= 2*MaxRtrAdvInterval. A value of all one + bits (0xffffffff) represents infinity. A value of + zero means that the RDNSS address MUST no longer be + used. + + Addresses of IPv6 Recursive DNS Servers + One or more 128-bit IPv6 addresses of the recursive + DNS servers. The number of addresses is determined + by the Length field. That is, the number of + addresses is equal to (Length - 1) / 2. + +5.2. Procedure of DNS Configuration + + The procedure of DNS configuration through the RDNSS option is the + same as with any other ND option [2]. + +5.2.1. Procedure in IPv6 Host + + When an IPv6 host receives an RDNSS option through RA, it checks + whether the option is valid. + + o If the RDNSS option is valid, the host SHOULD copy the option's + value into the DNS Server List and the Resolver Repository as long + as the value of the Length field is greater than or equal to the + minimum value (3). The host MAY ignore additional RDNSS addresses + within an RDNSS option and/or additional RDNSS options within an + RA when it has gathered a sufficient number of RDNSS addresses. + + o If the RDNSS option is invalid (e.g., the Length field has a value + less than 3), the host SHOULD discard the option. + + + + + + + + + +Jeong, et al. Experimental [Page 5] + +RFC 5006 IPv6 RA Option for DNS Configuration September 2007 + + +6. Implementation Considerations + + Note: This non-normative section gives some hints for implementing + the processing of the RDNSS option in an IPv6 host. + + For the configuration and management of RDNSS information, the + advertised RDNSS addresses can be stored and managed in both the DNS + Server List and the Resolver Repository. + + In environments where the RDNSS information is stored in user space + and ND runs in the kernel, it is necessary to synchronize the DNS + Server List of RDNSS addresses in kernel space and the Resolver + Repository in user space. For the synchronization, an implementation + where ND works in the kernel should provide a write operation for + updating RDNSS information from the kernel to the Resolver + Repository. One simple approach is to have a daemon (or a program + that is called at defined intervals) that keeps monitoring the + lifetime of RDNSS addresses all the time. Whenever there is an + expired entry in the DNS Server List, the daemon can delete the + corresponding entry from the Resolver Repository. + +6.1. DNS Server List Management + + The kernel or user-space process (depending on where RAs are + processed) should maintain a data structure called a DNS Server List + which keeps the list of RDNSS addresses. Each entry in the DNS + Server List consists of an RDNSS address and Expiration-time as + follows: + + o RDNSS address: IPv6 address of the Recursive DNS Server, which is + available for recursive DNS resolution service in the network + advertising the RDNSS option; such a network is called site in + this document. + + o Expiration-time: The time when this entry becomes invalid. + Expiration-time is set to the value of the Lifetime field of the + RDNSS option plus the current system time. Whenever a new RDNSS + option with the same address is received, this field is updated to + have a new expiration time. When Expiration-time becomes less + than the current system time, this entry is regarded as expired. + + Note: An RDNSS address MUST be used only as long as both the RA + router lifetime and the RDNSS option lifetime have not expired. + The reason is that the RDNSS may not be currently reachable or may + not provide service to the host's current address (e.g., due to + network ingress filtering [16][17]). + + + + + +Jeong, et al. Experimental [Page 6] + +RFC 5006 IPv6 RA Option for DNS Configuration September 2007 + + +6.2. Synchronization between DNS Server List and Resolver Repository + + When an IPv6 host receives the information of multiple RDNSS + addresses within a site through an RA message with RDNSS option(s), + it stores the RDNSS addresses (in order) into both the DNS Server + List and the Resolver Repository. The processing of the RDNSS + option(s) included in an RA message is as follows: + + Step (a): Receive and parse the RDNSS option(s). For the RDNSS + addresses in each RDNSS option, perform Step (b) through Step (d). + Note that Step (e) is performed whenever an entry expires in the + DNS Server List. + + Step (b): For each RDNSS address, check the following: If the + RDNSS address already exists in the DNS Server List and the RDNSS + option's Lifetime field is set to zero, delete the corresponding + RDNSS entry from both the DNS Server List and the Resolver + Repository in order to prevent the RDNSS address from being used + any more for certain reasons in network management, e.g., the + breakdown of the RDNSS or a renumbering situation. The processing + of this RDNSS address is finished here. Otherwise, go to Step + (c). + + Step (c): For each RDNSS address, if it already exists in the DNS + Server List, then just update the value of the Expiration-time + field according to the procedure specified in the second bullet of + Section 6.1. Otherwise, go to Step (d). + + Step (d): For each RDNSS address, if it does not exist in the DNS + Server List, register the RDNSS address and lifetime with the DNS + Server List and then insert the RDNSS address in front of the + Resolver Repository. In the case where the data structure for the + DNS Server List is full of RDNSS entries, delete from the DNS + Server List the entry with the shortest expiration time (i.e., the + entry that will expire first). The corresponding RDNSS address is + also deleted from the Resolver Repository. In the order in the + RDNSS option, position the newly added RDNSS addresses in front of + the Resolver Repository so that the new RDNSS addresses may be + preferred according to their order in the RDNSS option for the DNS + name resolution. The processing of these RDNSS addresses is + finished here. Note that, in the case where there are several + routers advertising RDNSS option(s) in a subnet, the RDNSSes that + have been announced recently are preferred. + + Step (e): Delete each expired entry from the DNS Server List, and + delete the RDNSS address corresponding to the entry from the + Resolver Repository. + + + + +Jeong, et al. Experimental [Page 7] + +RFC 5006 IPv6 RA Option for DNS Configuration September 2007 + + +7. Security Considerations + + The security of the RA option for RDNSS might be worse than ND + protocol security [2]. However, any new vulnerability in this RA + option is not known yet. In this context, it can be claimed that the + vulnerability of ND is not worse and is a subset of the attacks that + any node attached to a LAN can do independently of ND. A malicious + node on a LAN can promiscuously receive packets for any router's MAC + address and send packets with the router's MAC address as the source + MAC address in the L2 header. As a result, L2 switches send packets + addressed to the router to the malicious node. Also, this attack can + send redirects that tell the hosts to send their traffic somewhere + else. The malicious node can send unsolicited RA or Neighbor + Advertisement (NA) replies, answer RS or Neighbor Solicitation (NS) + requests, etc. Also, an attacker could configure a host to send out + an RA with a fraudulent RDNSS address, which is presumably an easier + avenue of attack than becoming a rogue router and having to process + all traffic for the subnet. It is necessary to disable the RA RDNSS + option in both routers and clients administratively to avoid this + problem. All of this can be done independently of implementing ND. + Therefore, it can be claimed that the RA option for RDNSS has + vulnerabilities similar to those existing in current mechanisms. + + If the Secure Neighbor Discovery (SEND) protocol is used as a + security mechanism for ND, all the ND options including the RDNSS + option are automatically included in the signatures [11], so the + RDNSS transport is integrity-protected. However, since any valid + SEND node can still insert RDNSS options, SEND cannot verify who is + or is not authorized to send the options. + +8. IANA Considerations + + The IANA has assigned a new IPv6 Neighbor Discovery Option type for + the RDNSS option defined in this document. + + Option Name Type + RDNSS option 25 + + The IANA registry for these options is: + + http://www.iana.org/assignments/icmpv6-parameters + +9. Acknowledgements + + This document has greatly benefited from inputs by Robert Hinden, + Pekka Savola, Iljitsch van Beijnum, Brian Haberman and Tim Chown. + The authors appreciate their contributions. + + + + +Jeong, et al. Experimental [Page 8] + +RFC 5006 IPv6 RA Option for DNS Configuration September 2007 + + +10. References + +10.1. Normative References + + [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [2] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, + "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, + September 2007. + + [3] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address + Autoconfiguration", RFC 4862, September 2007. + +10.2. Informative References + + [4] Mockapetris, P., "Domain Names - Concepts and Facilities", + RFC 1034, November 1987. + + [5] Mockapetris, P., "Domain Names - Implementation and + Specification", RFC 1035, November 1987. + + [6] Droms, R., Ed., "Dynamic Host Configuration Protocol for IPv6 + (DHCPv6)", RFC 3315, July 2003. + + [7] Droms, R., "Stateless Dynamic Host Configuration Protocol + (DHCP) Service for IPv6", RFC 3736, April 2004. + + [8] Droms, R., Ed., "DNS Configuration options for Dynamic Host + Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, + December 2003. + + [9] Jeong, J., Ed., "IPv6 Host Configuration of DNS Server + Information Approaches", RFC 4339, February 2006. + + [10] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in + IPv6", RFC 3775, June 2004. + + [11] Arkko, J., Ed., "SEcure Neighbor Discovery (SEND)", RFC 3971, + March 2005. + + [12] ANSI/IEEE Std 802.11, "Part 11: Wireless LAN Medium Access + Control (MAC) and Physical Layer (PHY) Specifications", + March 1999. + + [13] IEEE Std 802.11a, "Part 11: Wireless LAN Medium Access Control + (MAC) and Physical Layer (PHY) specifications: High-speed + Physical Layer in the 5 GHZ Band", September 1999. + + + +Jeong, et al. Experimental [Page 9] + +RFC 5006 IPv6 RA Option for DNS Configuration September 2007 + + + [14] IEEE Std 802.11b, "Part 11: Wireless LAN Medium Access Control + (MAC) and Physical Layer (PHY) specifications: Higher-Speed + Physical Layer Extension in the 2.4 GHz Band", September 1999. + + [15] IEEE P802.11g/D8.2, "Part 11: Wireless LAN Medium Access + Control (MAC) and Physical Layer (PHY) specifications: Further + Higher Data Rate Extension in the 2.4 GHz Band", April 2003. + + [16] Damas, J. and F. Neves, "Preventing Use of Recursive + Nameservers in Reflector Attacks", Work in Progress, July 2007. + + [17] Ferguson, P. and D. Senie, "Network Ingress Filtering: + Defeating Denial of Service Attacks which employ IP Source + Address Spoofing", BCP 38, RFC 2827, May 2000. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Jeong, et al. Experimental [Page 10] + +RFC 5006 IPv6 RA Option for DNS Configuration September 2007 + + +Authors' Addresses + + Jaehoon Paul Jeong (editor) + ETRI/Department of Computer Science and Engineering + University of Minnesota + 117 Pleasant Street SE + Minneapolis, MN 55455 + USA + + Phone: +1 651 587 7774 + Fax: +1 612 625 0572 + EMail: jjeong@cs.umn.edu + URI: http://www.cs.umn.edu/~jjeong/ + + + Soohong Daniel Park + Mobile Convergence Laboratory + SAMSUNG Electronics + 416 Maetan-3dong, Yeongtong-Gu + Suwon, Gyeonggi-Do 443-742 + Korea + + Phone: +82 31 200 4508 + EMail: soohong.park@samsung.com + + + Luc Beloeil + France Telecom R&D + 42, rue des coutures + BP 6243 + 14066 CAEN Cedex 4 + France + + Phone: +33 02 3175 9391 + EMail: luc.beloeil@orange-ftgroup.com + + + Syam Madanapalli + Ordyn Technologies + 1st Floor, Creator Building, ITPL + Bangalore - 560066 + India + + Phone: +91-80-40383000 + EMail: smadanapalli@gmail.com + + + + + + +Jeong, et al. Experimental [Page 11] + +RFC 5006 IPv6 RA Option for DNS Configuration September 2007 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2007). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND + THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS + OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF + THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + 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 might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + + + + + + + + + + + +Jeong, et al. Experimental [Page 12] + |