📄 draft-ietf-dnsop-ipv6-dns-configuration-06.txt
字号:
Jeong Expires November 6, 2005 [Page 27]Internet-Draft IPv6 Host Configuration of DNS Server May 20058. Acknowledgements This draft has greatly benefited from inputs by David Meyer, Rob Austein, Tatuya Jinmei, Pekka Savola, Tim Chown, Luc Beloeil, Christian Huitema, Thomas Narten, Pascal Thubert, and Greg Daley. Also, Tony Bonanno proofread this draft. The authors appreciate their contribution.Jeong Expires November 6, 2005 [Page 28]Internet-Draft IPv6 Host Configuration of DNS Server May 20059. References9.1 Normative References [1] Bradner, S., "IETF Rights in Contributions", RFC 3667, February 2004. [2] Bradner, S., "Intellectual Property Rights in IETF Technology", RFC 3668, February 2004. [3] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [4] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. [5] Droms, R., Ed., "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [6] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6", RFC 3736, April 2004. [7] Droms, R., Ed., "DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, December 2003.9.2 Informative References [8] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, "IPv6 DNS Discovery based on Router Advertisement", draft-jeong-dnsop-ipv6-dns-discovery-04.txt (Work in Progress), February 2005. [9] Ohta, M., "Preconfigured DNS Server Addresses", draft-ohta-preconfigured-dns-01.txt (Work in Progress), February 2004. [10] Venaas, S., Chown, T., and B. Volz, "Information Refresh Time Option for DHCPv6", draft-ietf-dhc-lifetime-03.txt (Work in Progress), January 2005. [11] Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting Service", RFC 1546, November 1993. [12] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003. [13] Lind, M., Ed., "Scenarios and Analysis for Introduction IPv6Jeong Expires November 6, 2005 [Page 29]Internet-Draft IPv6 Host Configuration of DNS Server May 2005 into ISP Networks", RFC 4029, March 2005. [14] Arkko, J., Ed., "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. [15] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001. [16] Bound, J., Ed., "IPv6 Enterprise Network Scenarios", draft-ietf-v6ops-ent-scenarios-05.txt (Work in Progress), July 2004. [17] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003. [18] Wasserman, M., Ed., "Recommendations for IPv6 in 3GPP Standards", RFC 3314, September 2002. [19] Soininen, J., Ed., "Transition Scenarios for 3GPP Networks", RFC 3574, August 2003. [20] Wiljakka, J., Ed., "Analysis on IPv6 Transition in 3GPP Networks", draft-ietf-v6ops-3gpp-analysis-11.txt (Work in Progress), October 2004. [21] 3GPP TS 23.060 V5.4.0, "General Packet Radio Service (GPRS); Service description; Stage 2 (Release 5)", December 2002. [22] 3GPP TS 24.008 V5.8.0, "Mobile radio interface Layer 3 specification; Core network protocols; Stage 3 (Release 5)", June 2003. [23] Chown, T., Venaas, S., and A. Vijayabhaskar, "Renumbering Requirements for Stateless DHCPv6", draft-ietf-dhc-stateless-dhcpv6-renumbering-02.txt (Work in Progress), October 2004. [24] Huitema, C., Ed., "Unmanaged Networks IPv6 Transition Scenarios", RFC 3750, April 2004. [25] ANSI/IEEE Std 802.11, "Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", March 1999. [26] 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 Expires November 6, 2005 [Page 30]Internet-Draft IPv6 Host Configuration of DNS Server May 2005 [27] 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. [28] 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. [29] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999. [30] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", draft-ietf-dnsop-dnssec-operational-practices-03.txt (Work in Progress), December 2004. [31] Guette, G. and O. Courtay, "Requirements for Automated Key Rollover in DNSSEC", draft-ietf-dnsop-key-rollover-requirements-02.txt (Work in Progress), January 2005. [32] Park, S., Madanapalli, S., and T. Jinmei, "Considerations on M and O Flags of IPv6 Router Advertisement", draft-ietf-ipv6-ra-mo-flags-01.txt (Work in Progress), March 2005.Author's Address Jaehoon Paul Jeong (editor) ETRI/Department of Computer Science and Engineering University of Minnesota 117 Pleasant Street SE Minneapolis, MN 55455 US Phone: +1 651 587 7774 Fax: +1 612 625 2002 Email: jjeong@cs.umn.edu URI: http://www.cs.umn.edu/~jjeong/Jeong Expires November 6, 2005 [Page 31]Internet-Draft IPv6 Host Configuration of DNS Server May 2005Appendix A. Link-layer Multicast Acknowledgements for RA Option One benefit of an RA option [8] is to be able to multicast the advertisements, reducing the need for duplicated unicast communications. However, some link-layers may not support this as well as others. Consider, for example, WLAN networks where multicast is unreliable. The unreliability problem is caused by lack of ACK for multicast, especially on the path from the Access Point (AP) to the Station (STA), which is specific to CSMA/CA of WLAN, such as IEEE 802.11 a/b/g [25]-[28]. That is, a multicast packet is unacknowledged on the path from the AP to the STA, but acknowledged in the reverse direction from the STA to the AP [25]. For example, when a router is placed at wired network connected to an AP, a host may sometimes not receive RA message advertised through the AP. Therefore, the RA option solution might not work well on a congested medium that uses unreliable multicast for RA. The fact that this problem has not been addressed in Neighbor Discovery [3] indicates that the extra link-layer acknowledgements have not been considered a serious problem till now. A possible mitigation technique could be to map all-nodes link- local multicast address to the link-layer broadcast address, and to rely on the ND retransmissions for message delivery in order to achieve more reliability.Jeong Expires November 6, 2005 [Page 32]Internet-Draft IPv6 Host Configuration of DNS Server May 2005Intellectual Property Statement 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.Disclaimer of Validity 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 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.Copyright Statement Copyright (C) The Internet Society (2005). 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.Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society.Jeong Expires November 6, 2005 [Page 33]
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -