Document Action: 'IPv6 Host Configuration of DNS Server Information Approaches' to Informational RFC

[The IESG <[e-mail]>]

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 mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ietf-announce