The IESG has approved the following document: - 'IPv6 Host Configuration of DNS Server Information Approaches ' <draft-ietf-dnsop-ipv6-dns-configuration-06.txt> as an Informational RFC This document is the product of the Domain Name System Operations Working Group. The IESG contact persons are David Kessens and Bert Wijnen. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsop-ipv6-dns-configuration-06.t xt Technical Summary This document describes three approaches for IPv6 recursive DNS server address configuration. It details the operational attributes of three solutions: RA option, DHCPv6 option, and Well-known anycast addresses for recursive DNS servers. Working Group Summary This document is a product of the dnsop working group. Protocol Quality This document was reviewed by David Kessens for the IESG. IESG Note This document describes three different approaches for the configuration of DNS name resolution server information in IPv6 hosts. There is not an IETF consensus on which approach is preferred. The analysis in this document was developed by the proponents for each approach and does not represent an IETF consensus. The 'RA option' and 'Well-known anycast' approaches described in this document are not standardized. Consequently the analysis for these approaches might not be completely applicable to any specific proposal that might be proposed in the future. Note to RFC Editor In 'Abstract': DELETE: Therefore, this document will give the audience a guideline for IPv6 host DNS configuration. --- In section '3.1 RA Option': DELETE: However, it is worth noting that some link layers, such as Wireless LANs (e.g., IEEE 802.11 a/b/g), do not support reliable multicast, which means that they cannot guarantee the timely delivery of RA messages [25]-[28]. This is discussed in Appendix A. --- In section '3.1.1 Advantages': DELETE: This works well on links that support broadcast reliably (e.g., Ethernet LANs) but not necessarily on other links (e.g., Wireless LANs): Refer to Appendix A. --- Same section, directly after the sentences that should be deleted: OLD: Also, this works NEW: This works --- In section '3.1.3 Observations': OLD: needed, but exclude public WLAN hot spots. NEW: needed. --- DELETE: Note The observation section is based on what the proponents of each approach think makes a good overall solution. --- In section '3.2.1 Advantages': DELETE: This capability is important in some network deployments such as service provider networks or WiFi hot spots. --- In section '3.2.3 Observations': OLD: on a cell phone network NEW: in a mobile phone network --- In section '3.3.1 Advantages': OLD: Another advantage is that the approach needs to configure DNS servers as a router, but nothing else. NEW: Another advantage is that this approach only needs configuration of the DNS server as a router (or configuration of a proxy router). --- At the end of section '3.3.2 Disadvantages': ADD: In addition, routers at the boundary of the "site" might need the configuration of route filters to prevent providing DNS services to parties outside the "site" and the possibility of denial of service attacks on the internal DNS infrastructure. --- In section '6.3 Well-known Anycast Addresses': OLD: Well-known anycast addresses does not require configuration security since there is no protocol [9]. The DNS server with the preconfigured addresses are still reasonably reliable, if local environment is reasonably secure, that is, there is no active attackers receiving queries to the anycast addresses of the servers and reply to them. NEW: The Well-known anycast addresses approach is not a protocol thus there is no need to secure the protocol itself. However, denial of service attacks on the DNS resolver system might be easier to achieve as the anycast addresses used are by definition well known. --- DELETE: 'Appendix A. Link-layer Multicast Acknowledgements for RA Option'. _______________________________________________ IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
