+++ /dev/null
-
-draft-ietf-dnsop-inaddr-required-06.txt
-
-INTERNET-DRAFT D. Senie
-Category: BCP Amaranth Networks Inc.
-Expires in six months February 2005
-
- Encouraging the use of DNS IN-ADDR Mapping
-
-Status of this Memo
-
- By submitting this Internet-Draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware
- have been or will be disclosed, and any of which he or she becomes
- aware will be disclosed, in accordance with Section 6 of RFC 3668.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- <http://www.ietf.org/ietf/1id-abstracts.txt>http://www.ietf.org/ietf/1id-abstracts.txt
-
- The list of Internet-Draft Shadow Directories can be accessed at
- <http://www.ietf.org/shadow.html>http://www.ietf.org/shadow.html
-
-Abstract
-
- Mapping of addresses to names has been a feature of DNS. Many sites,
- implement it, many others don't. Some applications attempt to use it
- as a part of a security strategy. The goal of this document is to
- encourage proper deployment of address to name mappings, and provide
- guidance for their use.
-
-Copyright Notice
-
- Copyright (C) The Internet Society. (2005)
-
-1. Introduction
-
- The Domain Name Service has provision for providing mapping of IP
- addresses to host names. It is common practice to ensure both name to
- address, and address to name mappings are provided for networks. This
- practice, while documented, has never been required, though it is
- generally encouraged. This document both encourages the presence of
-
-
-
-Senie [Page 1]
-
-
-
-
-
-Internet-Draft Encouraging the use of DNS IN-ADDR Mapping February 2005
-
-
- these mappings and discourages reliance on such mappings for security
- checks.
-
- 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 RFC 2119 [RFC2119].
-
-2. Discussion
-
-
- From the early days of the Domain Name Service [RFC883] a special
- domain has been set aside for resolving mappings of IP addresses to
- domain names. This was refined in [RFC1035], describing the .IN-
- ADDR.ARPA in use today. For the in the IPv6 address space, .IP6.ARPA
- was added [RFC3152]. This document uses IPv4 CIDR block sizes and
- allocation strategy where there are differences and uses IPv4
- terminology. Aside from these differences, this document can and
- should be applied to both address spaces.
-
- The assignment of blocks of IP address space was delegated to three
- regional registries. Guidelines for the registries are specified in
- [RFC2050], which requires regional registries to maintain IN-ADDR
- records on the large blocks of space issued to ISPs and others.
-
- ARIN's policy requires ISPs to maintain IN-ADDR for /16 or larger
- allocations. For smaller allocations, ARIN can provide IN-ADDR for
- /24 and shorter prefixes. [ARIN]. APNIC provides methods for ISPs to
- update IN-ADDR, however the present version of its policy document
- for IPv4 [APNIC] dropped the IN-ADDR requirements that were in draft
- copies of this document. As of this writing, it appears APNIC has no
- actual policy on IN-ADDR. RIPE appears to have the strongest policy
- in this area [RIPE302] indicating Local Internet Registries should
- provide IN-ADDR services, and delegate those as appropriate when
- address blocks are delegated.
-
- As we can see, the regional registries have their own policies for
- recommendations and/or requirements for IN-ADDR maintenance. It
- should be noted, however, that many address blocks were allocated
- before the creation of the regional registries, and thus it is
- unclear whether any of the policies of the registries are binding on
- those who hold blocks from that era.
-
- Registries allocate address blocks on CIDR [RFC1519] boundaries.
- Unfortunately the IN-ADDR zones are based on classful allocations.
- Guidelines [RFC2317] for delegating on non-octet-aligned boundaries
- exist, but are not always implemented.
-
-3. Examples of impact of missing IN-ADDR
-
-
-
-Senie [Page 2]
-
-
-
-
-
-Internet-Draft Encouraging the use of DNS IN-ADDR Mapping February 2005
-
-
- These are some examples of problems that may be introduced by
- reliance on IN-ADDR.
-
- Some applications use DNS lookups for security checks. To ensure
- validity of claimed names, some applications will look up IN-ADDR
- records to get names, and then look up the resultant name to see if
- it maps back to the address originally known. Failure to resolve
- matching names is seen as a potential security concern.
-
- Some FTP sites will flat-out reject users, even for anonymous FTP, if
- the IN-ADDR lookup fails or if the result of the IN-ADDR lookup when
- itself resolved, does not match. Some Telnet servers also implement
- this check.
-
- Web sites are in some cases using IN-ADDR checks to verify whether
- the client is located within a certain geopolitical entity. This
- approach has been employed for downloads of crypto software, for
- example, where export of that software is prohibited to some locales.
- Credit card anti-fraud systems also use these methods for geographic
- placement purposes.
-
- The popular TCP Wrappers program found on most Unix and Linux systems
- has options to enforce IN-ADDR checks and to reject any client that
- does not resolve. This program also has a way to check to see that
- the name given by a PTR record then resolves back to the same IP
- address. This method provdes more comfort but no appreciable
- additional security.
-
- Some anti-spam (anti junk email) systems use IN-ADDR to verify the
- presence of a PTR record, or validate the PTR value points back to
- the same address.
-
- Many web servers look up the IN-ADDR of visitors to be used in log
- analysis. This adds to the server load, but in the case of IN-ADDR
- unavailability, it can lead to delayed responses for users.
-
- Traceroutes with descriptive IN-ADDR naming proves useful when
- debugging problems spanning large areas. When this information is
- missing, the traceroutes take longer, and it takes additional steps
- to determine that network is the cause of problems.
-
- Wider-scale implementation of IN-ADDR on dialup, wireless access and
- other such client-oriented portions of the Internet would result in
- lower latency for queries (due to lack of negative caching), and
- lower name server load and DNS traffic.
-
-4. Recommendations
-
-
-
-
-Senie [Page 3]
-
-
-
-
-
-Internet-Draft Encouraging the use of DNS IN-ADDR Mapping February 2005
-
-
- 4.1 Delegation Recommendations
-
-
- Regional Registries and any Local Registries to whom they delegate
- should establish and convey a policy to those to whom they delegate
- blocks that IN-ADDR mappings are recommended. Policies should
- recommend those receiving delegations to provide IN-ADDR service
- and/or delegate to downstream customers.
-
- Network operators should define and implement policies and procedures
- which delegate IN-ADDR to their clients who wish to run their own IN-
- ADDR DNS services, and provide IN-ADDR services for those who do not
- have the resources to do it themselves. Delegation mechanisms should
- permit the downstream customer to implement and comply with IETF
- recommendations application of IN-ADDR to CIDR [RFC2317].
-
- All IP address space assigned and in use should be resolved by IN-
- ADDR records. All PTR records must use canonical names.
-
- All IP addresses in use within a block should have an IN-ADDR
- mapping. Those addresses not in use, and those that are not valid for
- use (zeros or ones broadcast addresses within a CIDR block) need not
- have mappings.
-
- It should be noted that due to CIDR, many addresses that appear to be
- otherwise valid host addresses may actually be zeroes or ones
- broadcast addresses. As such, attempting to audit a site's degree of
- compliance may only be done with knowledge of the internal subnet
- architecture of the site. It can be assumed, however, any host that
- originates an IP packet necessarily will have a valid host address,
- and must therefore have an IN-ADDR mapping.
-
-4.2 Application Recommendations
-
-
- Applications SHOULD NOT rely on IN-ADDR for proper operation. The use
- of IN-ADDR, sometimes in conjunction with a lookup of the name
- resulting from the PTR record provides no real security, can lead to
- erroneous results and generally just increases load on DNS servers.
- Further, in cases where address block holders fail to properly
- configure IN-ADDR, users of those blocks are penalized.
-
-5. Security Considerations
-
- This document has no negative impact on security. While it could be
- argued that lack of PTR record capabilities provides a degree of
- anonymity, this is really not valid. Trace routes, whois lookups and
- other sources will still provide methods for discovering identity.
-
-
-
-Senie [Page 4]
-
-
-
-
-
-Internet-Draft Encouraging the use of DNS IN-ADDR Mapping February 2005
-
-
- By recommending applications avoid using IN-ADDR as a security
- mechanism this document points out that this practice, despite its
- use by many applications, is an ineffective form of security.
- Applications should use better mechanisms of authentication.
-
-6. IANA Considerations
-
- There are no IANA considerations for this document.
-
-7. References
-
-7.1 Normative References
-
- [RFC883] P.V. Mockapetris, "Domain names: Implementation
- specification," RFC883, November 1983.
-
- [RFC1035] P.V. Mockapetris, "Domain Names: Implementation
- Specification," RFC 1035, November 1987.
-
- [RFC1519] V. Fuller, et. al., "Classless Inter-Domain Routing (CIDR):
- an Address Assignment and Aggregation Strategy," RFC 1519, September
- 1993.
-
- [RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3",
- RFC 2026, BCP 9, October 1996.
-
- [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
- Requirement Levels", RFC 2119, BCP 14, March 1997.
-
- [RFC2050] K. Hubbard, et. al., "Internet Registry IP Allocation
- Guidelines", RFC2050, BCP 12, Novebmer 1996.
-
- [RFC2317] H. Eidnes, et. al., "Classless IN-ADDR.ARPA delegation,"
- RFC 2317, March 1998.
-
- [RFC3152] R. Bush, "Delegation of IP6.ARPA," RFC 3152, BCP 49, August
- 2001.
-
-7.2 Informative References
-
- [ARIN] "ISP Guidelines for Requesting Initial IP Address Space," date
- unknown,
-<http://www.arin.net/regserv/initial-isp.html>http://www.arin.net/regserv/initial-isp.html
-
- [APNIC] "Policies For IPv4 Address Space Management in the Asia
- Pacific Region," APNIC-086, 13 January 2003.
-
- [RIPE302] "Policy for Reverse Address Delegation of IPv4 and IPv6
- Address Space in the RIPE NCC Service Region", RIPE-302, April 26,
-
-
-
-Senie [Page 5]
-
-
-
-
-
-Internet-Draft Encouraging the use of DNS IN-ADDR Mapping February 2005
-
-
- 2004.
-<http://www.ripe.net//ripe/docs/rev-del.html>http://www.ripe.net//ripe/docs/rev-del.html
-
-
-
-8. Acknowledgements
-
- Thanks to Peter Koch and Gary Miller for their input, and to many
- people who encouraged me to write this document.
-
-9. Author's Address
-
- Daniel Senie
- Amaranth Networks Inc.
- 324 Still River Road
- Bolton, MA 01740
-
- Phone: (978) 779-5100
-
- EMail: <mailto:dts@senie.com>dts@senie.com
-
-10. Full Copyright Statement
-
- Copyright (C) The Internet Society (2004). 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 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
-
-
-
-Senie [Page 6]
-
-
-
-
-
-Internet-Draft Encouraging the use of DNS IN-ADDR Mapping February 2005
-
-
- 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>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 <mailto:ietf-ipr@ietf.org>ietf-ipr@ietf.org.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Senie [Page 7]
-
-
-
-
-
-
-
--- /dev/null
+
+
+
+
+
+
+INTERNET-DRAFT D. Senie
+Category: BCP Amaranth Networks Inc.
+Expires in six months July 2005
+
+ Encouraging the use of DNS IN-ADDR Mapping
+ draft-ietf-dnsop-inaddr-required-07.txt
+
+Status of this Memo
+
+ By submitting this Internet-Draft, each author represents that any
+ applicable patent or other IPR claims of which he or she is aware
+ have been or will be disclosed, and any of which he or she becomes
+ aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that
+ other groups may also distribute working documents as Internet-
+ Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress."
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.txt
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html
+
+Abstract
+
+ Mapping of addresses to names has been a feature of DNS. Many sites,
+ implement it, many others don't. Some applications attempt to use it
+ as a part of a security strategy. The goal of this document is to
+ encourage proper deployment of address to name mappings, and provide
+ guidance for their use.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society. (2005)
+
+1. Introduction
+
+ The Domain Name Service has provision for providing mapping of IP
+ addresses to host names. It is common practice to ensure both name to
+ address, and address to name mappings are provided for networks. This
+ practice, while documented, has never been required, though it is
+ generally encouraged. This document both encourages the presence of
+
+
+
+Senie [Page 1]
+\f
+Internet-Draft Encouraging the use of DNS IN-ADDR Mapping July 2005
+
+
+ these mappings and discourages reliance on such mappings for security
+ checks.
+
+ 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 RFC 2119 [RFC2119].
+
+2. Discussion
+
+
+ From the early days of the Domain Name Service [RFC883] a special
+ domain has been set aside for resolving mappings of IP addresses to
+ domain names. This was refined in [RFC1035], describing the .IN-
+ ADDR.ARPA in use today. For the in the IPv6 address space, .IP6.ARPA
+ was added [RFC3152]. This document uses IPv4 CIDR block sizes and
+ allocation strategy where there are differences and uses IPv4
+ terminology. Aside from these differences, this document can and
+ should be applied to both address spaces.
+
+ The assignment of blocks of IP address space was delegated to three
+ regional registries. Guidelines for the registries are specified in
+ [RFC2050], which requires regional registries to maintain IN-ADDR
+ records on the large blocks of space issued to ISPs and others.
+
+ ARIN's policy requires ISPs to maintain IN-ADDR for /16 or larger
+ allocations. For smaller allocations, ARIN can provide IN-ADDR for
+ /24 and shorter prefixes. [ARIN]. APNIC provides methods for ISPs to
+ update IN-ADDR, however the present version of its policy document
+ for IPv4 [APNIC] dropped the IN-ADDR requirements that were in draft
+ copies of this document. As of this writing, it appears APNIC has no
+ actual policy on IN-ADDR. RIPE appears to have the strongest policy
+ in this area [RIPE302] indicating Local Internet Registries should
+ provide IN-ADDR services, and delegate those as appropriate when
+ address blocks are delegated.
+
+ As we can see, the regional registries have their own policies for
+ recommendations and/or requirements for IN-ADDR maintenance. It
+ should be noted, however, that many address blocks were allocated
+ before the creation of the regional registries, and thus it is
+ unclear whether any of the policies of the registries are binding on
+ those who hold blocks from that era.
+
+ Registries allocate address blocks on CIDR [RFC1519] boundaries.
+ Unfortunately the IN-ADDR zones are based on classful allocations.
+ Guidelines [RFC2317] for delegating on non-octet-aligned boundaries
+ exist, but are not always implemented.
+
+3. Examples of impact of missing IN-ADDR
+
+
+
+Senie [Page 2]
+\f
+Internet-Draft Encouraging the use of DNS IN-ADDR Mapping July 2005
+
+
+ These are some examples of problems that may be introduced by
+ reliance on IN-ADDR.
+
+ Some applications use DNS lookups for security checks. To ensure
+ validity of claimed names, some applications will look up IN-ADDR
+ records to get names, and then look up the resultant name to see if
+ it maps back to the address originally known. Failure to resolve
+ matching names is seen as a potential security concern.
+
+ Some FTP sites will flat-out reject users, even for anonymous FTP, if
+ the IN-ADDR lookup fails or if the result of the IN-ADDR lookup when
+ itself resolved, does not match. Some Telnet servers also implement
+ this check.
+
+ Web sites are in some cases using IN-ADDR checks to verify whether
+ the client is located within a certain geopolitical entity. This
+ approach has been employed for downloads of crypto software, for
+ example, where export of that software is prohibited to some locales.
+ Credit card anti-fraud systems also use these methods for geographic
+ placement purposes.
+
+ The popular TCP Wrappers program found on most Unix and Linux systems
+ has options to enforce IN-ADDR checks and to reject any client that
+ does not resolve. This program also has a way to check to see that
+ the name given by a PTR record then resolves back to the same IP
+ address. This method provdes more comfort but no appreciable
+ additional security.
+
+ Some anti-spam (anti junk email) systems use IN-ADDR to verify the
+ presence of a PTR record, or validate the PTR value points back to
+ the same address.
+
+ Many web servers look up the IN-ADDR of visitors to be used in log
+ analysis. This adds to the server load, but in the case of IN-ADDR
+ unavailability, it can lead to delayed responses for users.
+
+ Traceroutes with descriptive IN-ADDR naming proves useful when
+ debugging problems spanning large areas. When this information is
+ missing, the traceroutes take longer, and it takes additional steps
+ to determine that network is the cause of problems.
+
+ Wider-scale implementation of IN-ADDR on dialup, wireless access and
+ other such client-oriented portions of the Internet would result in
+ lower latency for queries (due to lack of negative caching), and
+ lower name server load and DNS traffic.
+
+4. Recommendations
+
+
+
+
+Senie [Page 3]
+\f
+Internet-Draft Encouraging the use of DNS IN-ADDR Mapping July 2005
+
+
+ 4.1 Delegation Recommendations
+
+
+ Regional Registries and any Local Registries to whom they delegate
+ should establish and convey a policy to those to whom they delegate
+ blocks that IN-ADDR mappings are recommended. Policies should
+ recommend those receiving delegations to provide IN-ADDR service
+ and/or delegate to downstream customers.
+
+ Network operators should define and implement policies and procedures
+ which delegate IN-ADDR to their clients who wish to run their own IN-
+ ADDR DNS services, and provide IN-ADDR services for those who do not
+ have the resources to do it themselves. Delegation mechanisms should
+ permit the downstream customer to implement and comply with IETF
+ recommendations application of IN-ADDR to CIDR [RFC2317].
+
+ All IP address space assigned and in use should be resolved by IN-
+ ADDR records. All PTR records must use canonical names.
+
+ All IP addresses in use within a block should have an IN-ADDR
+ mapping. Those addresses not in use, and those that are not valid for
+ use (zeros or ones broadcast addresses within a CIDR block) need not
+ have mappings.
+
+ It should be noted that due to CIDR, many addresses that appear to be
+ otherwise valid host addresses may actually be zeroes or ones
+ broadcast addresses. As such, attempting to audit a site's degree of
+ compliance may only be done with knowledge of the internal subnet
+ architecture of the site. It can be assumed, however, any host that
+ originates an IP packet necessarily will have a valid host address,
+ and must therefore have an IN-ADDR mapping.
+
+4.2 Application Recommendations
+
+
+ Applications SHOULD NOT rely on IN-ADDR for proper operation. The use
+ of IN-ADDR, sometimes in conjunction with a lookup of the name
+ resulting from the PTR record provides no real security, can lead to
+ erroneous results and generally just increases load on DNS servers.
+ Further, in cases where address block holders fail to properly
+ configure IN-ADDR, users of those blocks are penalized.
+
+5. Security Considerations
+
+ This document has no negative impact on security. While it could be
+ argued that lack of PTR record capabilities provides a degree of
+ anonymity, this is really not valid. Trace routes, whois lookups and
+ other sources will still provide methods for discovering identity.
+
+
+
+Senie [Page 4]
+\f
+Internet-Draft Encouraging the use of DNS IN-ADDR Mapping July 2005
+
+
+ By recommending applications avoid using IN-ADDR as a security
+ mechanism this document points out that this practice, despite its
+ use by many applications, is an ineffective form of security.
+ Applications should use better mechanisms of authentication.
+
+6. IANA Considerations
+
+ There are no IANA considerations for this document.
+
+7. References
+
+7.1 Normative References
+
+ [RFC883] P.V. Mockapetris, "Domain names: Implementation
+ specification," RFC883, November 1983.
+
+ [RFC1035] P.V. Mockapetris, "Domain Names: Implementation
+ Specification," RFC 1035, November 1987.
+
+ [RFC1519] V. Fuller, et. al., "Classless Inter-Domain Routing (CIDR):
+ an Address Assignment and Aggregation Strategy," RFC 1519, September
+ 1993.
+
+ [RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3",
+ RFC 2026, BCP 9, October 1996.
+
+ [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
+ Requirement Levels", RFC 2119, BCP 14, March 1997.
+
+ [RFC2050] K. Hubbard, et. al., "Internet Registry IP Allocation
+ Guidelines", RFC2050, BCP 12, Novebmer 1996.
+
+ [RFC2317] H. Eidnes, et. al., "Classless IN-ADDR.ARPA delegation,"
+ RFC 2317, March 1998.
+
+ [RFC3152] R. Bush, "Delegation of IP6.ARPA," RFC 3152, BCP 49, August
+ 2001.
+
+7.2 Informative References
+
+ [ARIN] "ISP Guidelines for Requesting Initial IP Address Space," date
+ unknown, http://www.arin.net/regserv/initial-isp.html
+
+ [APNIC] "Policies For IPv4 Address Space Management in the Asia
+ Pacific Region," APNIC-086, 13 January 2003.
+
+ [RIPE302] "Policy for Reverse Address Delegation of IPv4 and IPv6
+ Address Space in the RIPE NCC Service Region", RIPE-302, April 26,
+
+
+
+Senie [Page 5]
+\f
+Internet-Draft Encouraging the use of DNS IN-ADDR Mapping July 2005
+
+
+ 2004. http://www.ripe.net//ripe/docs/rev-del.html
+
+
+
+8. Acknowledgements
+
+ Thanks to Peter Koch and Gary Miller for their input, and to many
+ people who encouraged me to write this document.
+
+9. Author's Address
+
+ Daniel Senie
+ Amaranth Networks Inc.
+ 324 Still River Road
+ Bolton, MA 01740
+
+ Phone: (978) 779-5100
+
+ EMail: dts@senie.com
+
+10. Full 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.
+
+ 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.
+
+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.
+
+
+
+
+Senie [Page 6]
+\f
+Internet-Draft Encouraging the use of DNS IN-ADDR Mapping July 2005
+
+
+ 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.
+
+ Internet-Drafts are working documents of the
+ Internet Engineering Task Force (IETF), its areas, and its
+ working groups. Note that other groups may also distribute
+ working documents as Internet-Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of
+ six months and may be updated, replaced, or obsoleted by
+ other documents at any time. It is inappropriate to use
+ Internet-Drafts as reference material or to cite them other
+ than as "work in progress."
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/1id-abstracts.html
+
+ The list of Internet-Draft Shadow Directories can be
+ accessed at http://www.ietf.org/shadow.html
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Senie [Page 7]
+\f
+++ /dev/null
-DNS Operations WG
-Internet-Draft J. Jeong (ed.)
- ETRI/University of Minnesota
-
-Expires: August 2005 19 February 2005
-
-
- IPv6 Host Configuration of DNS Server Information Approaches
- draft-ietf-dnsop-ipv6-dns-configuration-05.txt
-
-
-Status of this Memo
-
- This document is an Internet-Draft and is subject to all provisions
- of section 3 of RFC 3667. By submitting this Internet-Draft, each
- author represents that any applicable patent or other IPR claims of
- which he or she is aware have been or will be disclosed, and any of
- which he or she become aware will be disclosed, in accordance with
- RFC 3668.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as
- Internet-Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six
- months and may be updated, replaced, or obsoleted by other
- documents at any time. It is inappropriate to use Internet-Drafts
- as reference material or to cite them other than as "work in
- progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/1id-abstracts.html
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html"
-
- This Internet-Draft will expire on August 19, 2005.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2005). All Rights Reserved.
-
-Abstract
-
- 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.
-
-
-
-Jeong, et al. Expires - August 2005 [Page 1]
-\f
-Internet-Draft IPv6 Host Configuration of DNS Server February 2005
-
-
- Additionally, it suggests four deployment scenarios considering
- multi-solution resolution. Therefore, this document will give the
- audience a guideline for IPv6 DNS configuration to select the
- approaches suitable for their host DNS configuration.
-
-Table of Contents
-
- 1. Introduction...................................................3
- 2. Terminology....................................................3
- 3. IPv6 DNS Configuration Approaches..............................3
- 3.1. RA Option..................................................3
- 3.1.1. Advantages...........................................4
- 3.1.2. Disadvantages........................................5
- 3.1.3. Observations.........................................6
- 3.2. DHCPv6 Option..............................................6
- 3.2.1. Advantages...........................................8
- 3.2.2. Disadvantages........................................8
- 3.2.3. Observations.........................................9
- 3.3. Well-known Anycast Addresses...............................9
- 3.3.1. Advantages..........................................10
- 3.3.2. Disadvantages.......................................10
- 3.3.3. Observations........................................11
- 4. Interworking among IPv6 DNS Configuration Approaches..........11
- 5. Deployment Scenarios..........................................12
- 5.1. ISP Network...............................................13
- 5.1.1. RA Option Approach..................................13
- 5.1.2. DHCPv6 Option Approach..............................13
- 5.1.3. Well-known Addresses Approach.......................14
- 5.2. Enterprise Network........................................14
- 5.3. 3GPP Network..............................................15
- 5.3.1. Currently Available Mechanisms and Recommendations..15
- 5.3.2. RA Extension........................................16
- 5.3.3. Stateless DHCPv6....................................17
- 5.3.4. Well-known Addresses................................18
- 5.3.5. Recommendations.....................................18
- 5.4. Unmanaged Network.........................................18
- 5.4.1. Case A: Gateway does not provide IPv6 at all........18
- 5.4.2. Case B: A dual-stack gateway connected to a dual-stack
- ISP.................................................19
- 5.4.3. Case C: A dual-stack gateway connected to an IPv4-only
- ISP.................................................19
- 5.4.4. Case D: A gateway connected to an IPv6-only ISP.....19
- 6. Security Considerations.......................................19
- 7. Acknowledgements..............................................20
- 8. Normative References..........................................20
- 9. Informative References........................................21
- 10. Appendix A - Link-layer Multicast Acknowledgements with RA
- Option.......................................................23
-
-
-Jeong, et al. Expires - August 2005 [Page 2]
-\f
-Internet-Draft IPv6 Host Configuration of DNS Server February 2005
-
-
- 11. Authors' Addresses...........................................23
- 12. Intellectual Property Statement..............................25
- 13. Full Copyright Statement.....................................25
- Acknowledgement..................................................26
-
-1. Introduction
-
- Neighbor Discovery (ND) for IP Version 6 and IPv6 Stateless Address
- Autoconfiguration provide the ways to configure either fixed or
- mobile nodes with one or more IPv6 addresses, default routes and
- some other parameters [3][4]. 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.
-
- This document describes three approaches of recursive DNS server
- address configuration for IPv6 host: (a) RA option [8], (b) DHCPv6
- option [5]-[7], and (c) Well-known anycast addresses for recursive
- DNS servers [9]. Also, it suggests the applicable scenarios for
- four kinds of networks: (a) ISP network, (b) Enterprise network,
- (c) 3GPP network, and (d) Unmanaged network.
-
- This document is just an analysis of each possible approach, and
- does not make any recommendation on particular one or on a
- combination of particular ones. Some approaches may even not be
- adopted at all as a result of further discussion.
-
- Therefore, the objective of this document is to help the audience
- select the approaches suitable for IPv6 host configuration of
- recursive DNS server.
-
-2. Terminology
-
- This document uses the terminology described in [3]-[9]. In
- addition, a new term is defined below:
-
- Recursive DNS Server (RDNSS) A Recursive DNS Server is a name
- server that offers the recursive
- service of DNS name resolution.
-
-3. IPv6 DNS Configuration Approaches
-
- In this section, the operational attributes of three solutions are
- described in detail.
-
-3.1. RA Option
-
-
-
-
-Jeong, et al. Expires - August 2005 [Page 3]
-\f
-Internet-Draft IPv6 Host Configuration of DNS Server February 2005
-
-
- RA approach is to define a new ND option called RDNSS option that
- contains a recursive DNS server address. Existing ND transport
- mechanisms (i.e., advertisements and solicitations) are used. This
- works in the same way that nodes learn about routers and prefixes.
- An IPv6 host can configure the IPv6 addresses of one or more
- RDNSSes via RA message periodically sent by router or solicited by
- a Router Solicitation (RS) [8].
-
- This approach needs RDNSS information to be configured in the
- routers doing the advertisements. The configuration of RDNSS
- address can be performed manually by operator or other ways, such
- as automatic configuration through DHCPv6 client running on the
- router. When advertising more than one RDNSS option, an RA message
- includes as many RDNSS options as RDNSSes.
-
- Through ND protocol and RDNSS option along with prefix information
- option, an IPv6 host can perform its network configuration of its
- IPv6 address and RDNSS simultaneously [3][4]. The RA option for
- RDNSS can be used on any network that supports the use of ND.
-
- However, it is worth noting that some link layers (e.g., WLAN) need
- to acknowledge multicast packets, which may increase the amount of
- link-layer traffic [25]-[28]. This is discussed in Appendix A.
-
- The RA approach is useful in some mobile environments where the
- addresses of the RDNSSes are changing because the RA option
- includes a lifetime field that allows client to use RDNSSes nearer
- to the client. This can be configured to a value that will require
- the client to time out the entry and switch over to another RDNSS
- address [8]. However, from the viewpoint of implementation, the
- lifetime would seem to make matters a bit more complex. Instead of
- just writing DNS configuration file, such as resolv.conf for the
- list of RDNSS addresses, we have to have a daemon around (or a
- program that is called at the defined intervals) that keeps
- monitoring the lifetime of RDNSSes all the time.
-
- The preference value of RDNSS, included in RDNSS option, allows
- IPv6 hosts to select primary RDNSS among several RDNSSes; this can
- be used for load balancing of RDNSSes [8].
-
-3.1.1. Advantages
-
- The RA option for RDNSS has a number of advantages. These include:
-
- 1) The RA option is an extension of existing ND/Autoconfig
- mechanisms [3][4], and does not require a change in the base ND
- protocol.
-
-
-
-Jeong, et al. Expires - August 2005 [Page 4]
-\f
-Internet-Draft IPv6 Host Configuration of DNS Server February 2005
-
-
- 2) This approach, like ND, works well on a variety of link types
- including point-to-point links, point-to-multipoint, and
- multi-point (i.e., Ethernet LANs), etc. RFC2461 [3] states,
- however, that there may be some link types on which ND is not
- possible; on such links, some other mechanisms will be needed for
- DNS configuration.
-
- 3) All of the information a host needs to run the basic Internet
- applications such as the email, web, ftp, etc., can be obtained
- with the addition of this option to ND and address autoconfiguration
- The use of a single mechanism is more reliable and easier to provide
- than when the RDNSS information is learned via another protocol
- mechanism. Debugging problems when multiple protocol mechanisms are
- being used is harder and much more complex.
-
- 4) This mechanism works over a broad range of scenarios and
- leverages IPv6 ND. 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. Also, this works well
- on links that are high performance (e.g., Ethernet LANs) and low
- performance (e.g., Cellular networks). In the latter case,
- combining the RDNSS information with the other information in the
- RA, the host can learn all of the information needed to use most
- Internet applications, such as the web in a single packet. This
- not only saves bandwidth where this is an issue, but also minimizes
- the delay needed to learn the RDNSS information.
-
- 5) The RA approach could be used as a model for other similar types
- of configuration information. New RA options for other server
- addresses, such as NTP server address, that are common to all
- clients on a subnet would be easy to define.
-
-3.1.2. Disadvantages
-
- 1) ND is mostly implemented in the kernel part of operating system.
- Therefore, if ND supports the configuration of some additional
- services, such as DNS servers, ND should be extended in the kernel
- part, and complemented by a user-land process. DHCPv6, however,
- has more flexibility for the extension of service discovery because
- it is an application layer protocol.
-
- 2) The current ND framework should be modified due to the
- synchronization between another ND cache for RDNSSes in the kernel
- space and the DNS configuration file in the user space. Because it
- is unacceptable to write and rewrite the DNS configuration file
- (e.g., resolv.conf) from the kernel, another approach is needed.
- One simple approach to solve this is to have a daemon listening to
-
-
-
-Jeong, et al. Expires - August 2005 [Page 5]
-\f
-Internet-Draft IPv6 Host Configuration of DNS Server February 2005
-
-
- what the kernel conveys, and to have the daemon do these steps, but
- such a daemon is not needed with the current ND framework.
-
- 3) It is necessary to configure RDNSS addresses at least at one
- router on every link where this information needs to be configured
- by RA option.
-
-3.1.3. Observations
-
- The proposed RDNSS RA option along with the IPv6 ND and
- Autoconfiguration allows a host to obtain all of the information it
- needs to access the basic Internet services like the web, email,
- ftp, etc. This is preferable in the environments where hosts use
- RAs to autoconfigure their addresses and all the hosts on the
- subnet share the same router and server addresses. If the
- configuration information can be obtained from a single mechanism,
- it is preferable because it does not add additional delay, and it
- uses a minimum of bandwidth. The environments like this include
- the homes, public cellular networks, and enterprise environments
- where no per host configuration is needed, but exclude public WLAN
- hot spots.
-
- DHCPv6 is preferable where it is being used for address
- configuration and if there is a need for host specific
- configuration [5]-[7]. The environments like this are most likely
- the enterprise environments where the local administration chooses
- to have per host configuration control.
-
- Note: the observation section is based on what the proponents of
- each approach think makes a good overall solution.
-
-3.2. DHCPv6 Option
-
- DHCPv6 [5] includes the "DNS Recursive Name Server" option, through
- which a host can obtain a list of IP addresses of recursive DNS
- servers [7]. The DNS Recursive Name Server option carries a list
- of IPv6 addresses of RDNSSes to which the host may send DNS queries.
- The DNS servers are listed in the order of preference for use by
- the DNS resolver on the host.
-
- The DNS Recursive Name Server option can be carried in any DHCPv6
- Reply message, in response to either a Request or an Information
- request message. Thus, the DNS Recursive Name Server option can be
- used either when DHCPv6 is used for address assignment, or when
- DHCPv6 is used only for other configuration information as
- stateless DHCPv6 [6].
-
-
-
-
-Jeong, et al. Expires - August 2005 [Page 6]
-\f
-Internet-Draft IPv6 Host Configuration of DNS Server February 2005
-
-
- Stateless DHCPv6 can be deployed either using DHCPv6 servers
- running on general-purpose computers, or on router hardware.
- Several router vendors currently implement stateless DHCPv6 servers.
- Deploying stateless DHCPv6 in routers has the advantage that no
- special hardware is required, and should work well for networks
- where DHCPv6 is needed for very straightforward configuration of
- network devices.
-
- However, routers can also act as DHCPv6 relay agents. In this case,
- the DHCPv6 server need not be on the router - it can be on a
- general purpose computer. This has the potential to give the
- operator of the DHCPv6 server more flexibility in how the DHCPv6
- server responds to individual clients - clients can easily be given
- different configuration information based on their identity, or for
- any other reason. Nothing precludes adding this flexibility to a
- router, but generally in current practice, DHCP servers running on
- general-purpose hosts tend to have more configuration options than
- those that are embedded in routers.
-
- DHCPv6 currently provides a mechanism for reconfiguring DHCPv6
- clients that use stateful configuration assignment. To do this,
- the DHCPv6 server sends a Reconfigure message to the client. The
- client validates the Reconfigure message, and then contacts the
- DHCPv6 server to obtain updated configuration information. Using
- this mechanism, it is currently possible to propagate new
- configuration information to DHCPv6 clients as this information
- changes.
-
- The DHC Working Group is currently studying an additional mechanism
- through which configuration information, including the list of
- RDNSSes, can be updated. The lifetime option for DHCPv6 [10]
- assigns a lifetime to configuration information obtained through
- DHCPv6. At the expiration of the lifetime, the host contacts the
- DHCPv6 server to obtain updated configuration information,
- including the list of RDNSSes. This lifetime gives the network
- administrator another mechanism to configure hosts with new RDNSSes
- by controlling the time at which the host refreshes the list.
-
- The DHC Working Group has also discussed the possibility of
- defining an extension to DHCPv6 that would allow the use of
- multicast to provide configuration information to multiple hosts
- with a single DHCPv6 message. Because of the lack of deployment
- experience, the WG has deferred consideration of multicast DHCPv6
- configuration at this time. Experience with DHCPv4 has not
- identified a requirement for multicast message delivery, even in
- large service provider networks with tens of thousands of hosts
- that may initiate a DHCPv4 message exchange simultaneously.
-
-
-
-Jeong, et al. Expires - August 2005 [Page 7]
-\f
-Internet-Draft IPv6 Host Configuration of DNS Server February 2005
-
-
-3.2.1. Advantages
-
- The DHCPv6 option for RDNSS has a number of advantages. These
- include:
-
- 1) DHCPv6 currently provides a general mechanism for conveying
- network configuration information to clients. So configuring
- DHCPv6 servers allows the network administrator to configure
- RDNSSes along with the addresses of other network services, as well
- as location-specific information like time zones.
-
- 2) As a consequence, when the network administrator goes to
- configure DHCPv6, all the configuration information can be managed
- through a single service, typically with a single user interface
- and a single configuration database.
-
- 3) DHCPv6 allows for the configuration of a host with information
- specific to that host, so that hosts on the same link can be
- configured with different RDNSSes as well as other configuration
- information. This capability is important in some network
- deployments such as service provider networks or WiFi hot spots.
-
- 4) A mechanism exists for extending DHCPv6 to support the
- transmission of additional configuration that has not yet been
- anticipated.
-
- 5) Hosts that require other configuration information such as the
- addresses of SIP servers and NTP servers are likely to need DHCPv6
- for other configuration information.
-
- 6) The specification for configuration of RDNSSes through DHCPv6 is
- available as an RFC. No new protocol extensions such as new
- options are necessary.
-
- 7) Interoperability among independent implementations has been
- demonstrated.
-
-3.2.2. Disadvantages
-
- The DHCPv6 option for RDNSS has a few disadvantages. These
- include:
-
- 1) Update currently requires message from server (however, see
- [10]).
-
- 2) Because DNS information is not contained in RA message, the host
- must receive two messages from the router, and must transmit at
- least one message to the router. On networks where bandwidth is at
-
-
-Jeong, et al. Expires - August 2005 [Page 8]
-\f
-Internet-Draft IPv6 Host Configuration of DNS Server February 2005
-
-
- a premium, this is a disadvantage, although on most networks it is
- not a practical concern.
-
- 3) Increased latency for initial configuration - in addition to
- waiting for an RA message, the client must now exchange packets
- with a DHCPv6 server; even if it is locally installed on a router,
- this will slightly extend the time required to configure the client.
- For clients that are moving rapidly from one network to another,
- this will be a disadvantage.
-
-3.2.3. Observations
-
- In the general case, on general-purpose networks, stateless DHCPv6
- provides significant advantages and no significant disadvantages.
- Even in the case where bandwidth is at a premium and low latency is
- desired, if hosts require other configuration information in
- addition to a list of RDNSSes or if hosts must be configured
- selectively, those hosts will use DHCPv6 and the use of the DHCPv6
- DNS recursive name server option will be advantageous.
-
- However, we are aware of some applications where it would be
- preferable to put the RDNSS information into an RA packet; for
- example, on a cell phone network, where bandwidth is at a premium
- and extremely low latency is desired. The final DNS configuration
- draft should be written so as to allow these special applications
- to be handled using DNS information in the RA packet.
-
-3.3. Well-known Anycast Addresses
-
- Anycast uses the same routing system as unicast [11]. However,
- administrative entities are local ones. The local entities may
- accept unicast routes (including default routes) to anycast servers
- from adjacent entities. The administrative entities should not
- advertise their peers routes to their internal anycast servers, if
- they want to prohibit external access from some peers to the
- servers. If some advertisement is inevitable (such as the case
- with default routes), the packets to the servers should be blocked
- at the boundary of the entities. Thus, for this anycast, not only
- unicast routing but also unicast ND protocols can be used as is.
-
- First of all, the well-known anycast addresses approach is much
- different from that discussed at IPv6 Working Group in the past [9].
- It should be noted that "anycast" in this memo is simpler than that
- of RFC1546 [11] and RFC3513 [12] where it is assumed to be
- prohibited to have multiple servers on a single link sharing an
- anycast address. That is, on a link, anycast address is assumed to
- be unique. DNS clients today already have redundancy by having
- multiple well-known anycast addresses configured as RDNSS addresses.
-
-
-Jeong, et al. Expires - August 2005 [Page 9]
-\f
-Internet-Draft IPv6 Host Configuration of DNS Server February 2005
-
-
- There is no point in having multiple RDNSSes sharing an anycast
- address on a single link.
-
- The approach with well-known anycast addresses is to set multiple
- well-known anycast addresses in clients' resolver configuration
- files from the beginning, say, as factory default. Thus, there is
- no transport mechanism and no packet format [9].
-
- An anycast address is an address shared by multiple servers (in
- this case, the servers are RDNSSes). Request from a client to the
- anycast address is routed to a server selected by the routing
- system. However, it is a bad idea to mandate "site" boundary on
- anycast addresses, because most users just do not have their own
- servers and want to access their ISPs' across their site boundaries.
- Larger sites may also depend on their ISPs or may have their own
- RDNSSes within "site" boundaries.
-
-3.3.1. Advantages
-
- The basic advantage of the well-known addresses approach is that it
- uses no transport mechanism. Thus,
-
- 1) There is no delay to get the response and no further delay by
- packet losses.
-
- 2) The approach can be combined with any other configuration
- mechanisms, such as RA-based approach and DHCP based approach, as
- well as factory default configuration.
-
- 3) The approach works over any environment where DNS works.
-
- Another advantage is that the approach needs to configure DNS
- servers as a router, but nothing else. Considering that DNS
- servers do need configuration, the amount of overall configuration
- effort is proportional to the number of the DNS servers and scales
- linearly. It should be noted that, in the simplest case where a
- subscriber to an ISP does not have any DNS server, the subscriber
- naturally accesses DNS servers of the ISP even though the
- subscriber and the ISP do nothing and there is no protocol to
- exchange DNS server information between the subscriber and the ISP.
-
-3.3.2. Disadvantages
-
- Well-known anycast addresses approach requires that DNS servers (or
- routers near it as a proxy) act as routers to advertise their
- anycast addresses to the routing system, which requires some
- configuration (see the last paragraph of the previous section on
- the scalability of the effort).
-
-
-Jeong, et al. Expires - August 2005 [Page 10]
-\f
-Internet-Draft IPv6 Host Configuration of DNS Server February 2005
-
-
-
-3.3.3. Observations
-
- If other approaches are used in addition, the well-known anycast
- addresses should also be set in RA or DHCP configuration files to
- reduce the configuration effort of users.
-
- The redundancy by multiple RDNSSes is better provided by multiple
- servers having different anycast addresses than multiple servers
- sharing the same anycast address because the former approach allows
- stale servers to still generate routes to their anycast addresses.
- Thus, in a routing domain (or domains sharing DNS servers), there
- will be only one server having an anycast address unless the domain
- is so large that load distribution is necessary.
-
- Small ISPs will operate one RDNSS at each anycast address which is
- shared by all the subscribers. Large ISPs may operate multiple
- RDNSSes at each anycast address to distribute and reduce load,
- where boundary between RDNSSes may be fixed (redundancy is still
- provided by multiple addresses) or change dynamically. DNS packets
- with the well-known anycast addresses are not expected (though not
- prohibited) to cross ISP boundaries, as ISPs are expected to be
- able to take care of themselves.
-
- Because "anycast" in this memo is simpler than that of RFC1546 [11]
- and RFC3513 [12] where it is assumed to be administratively
- prohibited to have multiple servers on a single link sharing an
- anycast address, anycast in this memo should be implemented as
- UNICAST of RFC2461 [3] and RFC3513 [12]. As a result, ND-related
- instability disappears. Thus, anycast in well-known anycast
- addresses approach can and should use the anycast address as a
- source unicast (according to RFC3513 [12]) address of packets of
- UDP and TCP responses. With TCP, if route flips and packets to an
- anycast address are routed to a new server, it is expected that the
- flip is detected by ICMP or sequence number inconsistency and the
- TCP connection is reset and retried.
-
-4. Interworking among IPv6 DNS Configuration Approaches
-
- Three approaches can work together for IPv6 host configuration of
- RDNSS. This section shows a consideration on how these approaches
- can interwork each other.
-
- For ordering between RA and DHCP approaches, O (Other stateful
- configuration) flag in RA message can be used [8]. If no RDNSS
- option is included, an IPv6 host may perform DNS configuration
- through DHCPv6 [5]-[7] regardless of whether the O flag is set or
- not.
-
-
-Jeong, et al. Expires - August 2005 [Page 11]
-\f
-Internet-Draft IPv6 Host Configuration of DNS Server February 2005
-
-
-
- The well-known anycast addresses approach fully interworks with the
- other approaches. That is, the other approaches can remove the
- configuration effort on servers by using the well-known addresses
- as the default configuration. Moreover, the clients preconfigured
- with the well-known anycast addresses can be further configured to
- use other approaches to override the well-known addresses, if the
- configuration information from other approaches are available.
- That is, all the clients should have the well-known anycast
- addresses preconfigured, in the case where there are no other
- mechanisms available. In order to fly anycast approach with the
- other solutions, there are three options as follows:
-
- 1) The first option is that well-known addresses are used as last
- resort, when an IPv6 host can not get RDNSS information through RA
- and DHCP. The well-known anycast addresses have to be preconfigured
- in IPv6 hosts' resolver configuration files.
-
- 2) The second is that an IPv6 host can configure well-known
- addresses as the most preferable in its configuration file even
- though either RA option or DHCP option is available.
-
- 3) The last is that the well-known anycast addresses can be set in
- RA or DHCP configuration to reduce configuration effort of users.
- According to either RA or DHCP mechanism, the well-known addresses
- can be obtained by IPv6 host. Because this approach is the most
- convenient for users, the last option is recommended.
-
- Note: this section does not necessarily mean this document suggests
- adopting all these three approaches and making them interwork in
- the way described here. In fact, some approaches may even not be
- adopted at all as a result of further discussion.
-
-5. Deployment Scenarios
-
- Regarding the DNS configuration on the IPv6 host, several
- mechanisms are being considered at the DNSOP Working Group such as
- RA option, DHCPv6 option and well-known preconfigured anycast
- addresses as of today, and this document is a final result from the
- long thread. In this section, we suggest four applicable scenarios
- of three approaches for IPv6 DNS configuration.
-
- Note: in the applicable scenarios, authors do not implicitly push
- any specific approaches into the restricted environments. No
- enforcement is in each scenario and all mentioned scenarios are
- probable. The main objective of this work is to provide a useful
- guideline for IPv6 DNS configuration.
-
-
-
-Jeong, et al. Expires - August 2005 [Page 12]
-\f
-Internet-Draft IPv6 Host Configuration of DNS Server February 2005
-
-
-5.1. ISP Network
-
- A characteristic of ISP network is that multiple Customer Premises
- Equipment (CPE) devices are connected to IPv6 PE (Provider Edge)
- routers and each PE connects multiple CPE devices to the backbone
- network infrastructure [13]. The CPEs may be hosts or routers.
-
- In the case where the CPE is a router, there is a customer network
- that is connected to the ISP backbone through the CPE. Typically,
- each customer network gets a different IPv6 prefix from an IPv6 PE
- router, but the same RDNSS configuration will be distributed.
-
- This section discusses how the different approaches to distributing
- DNS information are compared in an ISP network.
-
-5.1.1. RA Option Approach
-
- When the CPE is a host, the RA option for RDNSS can be used to
- allow the CPE to get RDNSS information as well as /64 prefix
- information for stateless address autoconfiguration at the same
- time when the host is attached to a new subnet [8]. Because an
- IPv6 host must receive at least one RA message for stateless
- address autoconfiguration and router configuration, the host could
- receive RDNSS configuration information in that RA without the
- overhead of an additional message exchange.
-
- When the CPE is a router, the CPE may accept the RDNSS information
- from the RA on the interface connected to the ISP, and copy that
- information into the RAs advertised in the customer network.
-
- This approach is more valuable in the mobile host scenario, in
- which the host must receive at least an RA message for detecting a
- new network, than in other scenarios generally although
- administrator should configure RDNSS information on the routers.
- Secure ND [14] can provide extended security when using RA message.
-
-5.1.2. DHCPv6 Option Approach
-
- DHCPv6 can be used for RDNSS configuration through the use of the
- DNS option, and can provide other configuration information in the
- same message with RDNSS configuration [5]-[7]. DHCPv6 DNS option
- is already in place for DHCPv6 as RFC 3646 [7] and DHCPv6-lite
- or stateless DHCP [6] is nowhere as complex as a full DHCPv6
- implementation. DHCP is a client-server model protocol, so ISP can
- handle user identification on its network intentionally, and also
- authenticated DHCP [15] can be used for secure message exchange.
-
-
-
-
-Jeong, et al. Expires - August 2005 [Page 13]
-\f
-Internet-Draft IPv6 Host Configuration of DNS Server February 2005
-
-
- The expected model for deployment of IPv6 service by ISPs is to
- assign a prefix to each customer, which will be used by the
- customer gateway to assign a /64 prefix to each network in the
- customer's network. Prefix delegation with DHCP (DHCPv6 PD) has
- already been adopted by ISPs for automating the assignment of the
- customer prefix to the customer gateway [17]. DNS configuration
- can be carried in the same DHCPv6 message exchange used for DHCPv6
- to efficiently provide that information, along with any other
- configuration information needed by the customer gateway or
- customer network. This service model can be useful to Home or SOHO
- subscribers. The Home or SOHO gateway, which is a customer gateway
- for ISP, can then pass that RDNSS configuration information to the
- hosts in the customer network through DHCP.
-
-5.1.3. Well-known Addresses Approach
-
- Well-known anycast addresses approach is also a feasible and simple
- mechanism for ISP [9]. The use of well-known anycast addresses
- avoids some of the security risks in rogue messages sent through an
- external protocol like RA or DHCPv6. The configuration of hosts
- for the use of well-known anycast addresses requires no protocol or
- manual configuration, but the configuration of routing for the
- anycast addresses requires intervention on the part of the network
- administrator. Also, the number of special addresses would be
- equal to the number of RDNSSes that could be made available to
- subscribers.
-
-5.2. Enterprise Network
-
- Enterprise network is defined as a network that has multiple
- internal links, one or more router connections, to one or more
- Providers and is actively managed by a network operations entity
- [16]. An enterprise network can get network prefixes from ISP by
- either manual configuration or prefix delegation [17]. In most
- cases, because an enterprise network manages its own DNS domains,
- it operates its own DNS servers for the domains. These DNS servers
- within enterprise network process recursive DNS name resolution
- requests from IPv6 hosts as RDNSSes. The RDNSS configuration in
- the enterprise network can be performed like in Section 4, in which
- three approaches can be used together as follows:
-
- 1) IPv6 host can decide which approach is or may be used in its
- subnet with O flag in RA message [8]. As the first option in
- Section 4, well-known anycast addresses can be used as a last
- resort when RDNSS information can not be obtained through either RA
- option or DHCP option. This case needs IPv6 hosts to preconfigure
- the well-known anycast addresses in their DNS configuration files.
-
-
-
-Jeong, et al. Expires - August 2005 [Page 14]
-\f
-Internet-Draft IPv6 Host Configuration of DNS Server February 2005
-
-
- 2) When the enterprise prefers well-known anycast approach to the
- others, IPv6 hosts should preconfigure the well-known anycast
- addresses like in the first option.
-
- 3) The last option, a more convenient and transparent way, does not
- need IPv6 hosts to preconfigure the well-known anycast addresses
- because the addresses are delivered to IPv6 hosts through either RA
- option or DHCPv6 option as if they were unicast addresses. This
- way is most recommended for the sake of user's convenience.
-
-5.3. 3GPP Network
-
- IPv6 DNS configuration is a missing part of IPv6 autoconfiguration
- and an important part of the basic IPv6 functionality in the 3GPP
- User Equipment (UE). Higher level description of the 3GPP
- architecture can be found in [18], and transition to IPv6 in 3GPP
- networks is analyzed in [19] and [20].
-
- In 3GPP architecture, there is a dedicated link between the UE and
- the GGSN called the Packet Data Protocol (PDP) Context. This link
- is created through the PDP Context activation procedure [21].
- There is a separate PDP context type for IPv4 and IPv6 traffic. If
- a 3GPP UE user is communicating using IPv6 (having an active IPv6
- PDP context), it can not be assumed that (s)he has simultaneously
- active IPv4 PDP context, and DNS queries could be done using IPv4.
- A 3GPP UE can thus be an IPv6 node, and it needs to somehow
- discover the address of the RDNSS. Before IP-based services (e.g.,
- web browsing or e-mail) can be used, the IPv6 (and IPv4) RDNSS
- addresses need to be discovered in the 3GPP UE.
-
- Section 5.3.1 briefly summarizes currently available mechanisms in
- 3GPP networks and recommendations. 5.3.2 analyzes the Router
- Advertisement based solution, 5.3.3 analyzes the Stateless DHCPv6
- mechanism, and 5.3.4 analyzes the Well-known addresses approach.
- Section 5.3.5 finally summarizes the recommendations.
-
-5.3.1. Currently Available Mechanisms and Recommendations
-
- 3GPP has defined a mechanism, in which RDNSS addresses can be
- received in the PDP context activation (a control plane mechanism).
- That is called the Protocol Configuration Options Information
- Element (PCO-IE) mechanism [22]. The RDNSS addresses can also be
- received over the air (using text messages), or typed in manually
- in the UE. Note that the two last mechanisms are not very well
- scalable. The UE user most probably does not want to type IPv6
- RDNSS addresses manually in his/her UE. The use of well-known
- addresses is briefly discussed in section 5.3.4.
-
-
-
-Jeong, et al. Expires - August 2005 [Page 15]
-\f
-Internet-Draft IPv6 Host Configuration of DNS Server February 2005
-
-
- It is seen that the mechanisms above most probably are not
- sufficient for the 3GPP environment. IPv6 is intended to operate
- in a zero-configuration manner, no matter what the underlying
- network infrastructure is. Typically, the RDNSS address is needed
- to make an IPv6 node operational - and the DNS configuration should
- be as simple as the address autoconfiguration mechanism. It must
- also be noted that there will be additional IP interfaces in some
- near future 3GPP UEs, e.g., WLAN, and 3GPP-specific DNS
- configuration mechanisms (such as PCO-IE [22]) do not work for
- those IP interfaces. In other words, a good IPv6 DNS configuration
- mechanism should also work in a multi-access network environment.
-
- From 3GPP point of view, the best IPv6 DNS configuration solution
- is feasible for a very large number of IPv6-capable UEs (can be
- even hundreds of millions in one operator's network), is automatic
- and thus requires no user action. It is suggested to standardize a
- lightweight, stateless mechanism that works in all network
- environments. The solution could then be used for 3GPP, 3GPP2,
- WLAN and other access network technologies. A light, stateless
- IPv6 DNS configuration mechanism is thus not only needed in 3GPP
- networks, but also 3GPP networks and UEs would certainly benefit
- from the new mechanism.
-
-5.3.2. RA Extension
-
- Router Advertisement extension [8] is a lightweight IPv6 DNS
- configuration mechanism that requires minor changes in 3GPP UE IPv6
- stack and Gateway GPRS Support Node (GGSN, the default router in
- the 3GPP architecture) IPv6 stack. This solution can be specified
- in the IETF (no action needed in the 3GPP) and taken in use in 3GPP
- UEs and GGSNs.
-
- In this solution, an IPv6-capable UE configures DNS information
- via RA message sent by its default router (GGSN), i.e., RDNSS
- option for recursive DNS server is included in the RA message.
- This solution is easily scalable for a very large number of UEs.
- The operator can configure the RDNSS addresses in the GGSN as a
- part of normal GGSN configuration. The IPv6 RDNSS address is
- received in the Router Advertisement, and an extra Round Trip Time
- (RTT) for asking RDNSS addresses can be avoided.
-
- If thinking about cons, this mechanism still requires
- standardization effort in the IETF, and the end nodes and routers
- need to support this mechanism. The equipment software update
- should, however, be pretty straightforward, and new IPv6 equipment
- could support RA extension already from the beginning.
-
-
-
-
-Jeong, et al. Expires - August 2005 [Page 16]
-\f
-Internet-Draft IPv6 Host Configuration of DNS Server February 2005
-
-
-5.3.3. Stateless DHCPv6
-
- DHCPv6-based solution needs the implementation of Stateless DHCP
- [6] and DHCPv6 DNS options [7] in the UE, and a DHCPv6 server in
- the operator's network. A possible configuration is such that the
- GGSN works as a DHCP relay.
-
- Pros for Stateless DHCPv6-based solution are
-
- 1) Stateless DHCPv6 is a standardized mechanism.
-
- 2) DHCPv6 can be used for receiving other configuration information
- than RDNSS addresses, e.g., SIP server addresses.
-
- 3) DHCPv6 works in different network environments.
-
- 4) When DHCPv6 service is deployed through a single, centralized
- server, the RDNSS configuration information can be updated by the
- network administrator at a single source.
-
- Some issues with DHCPv6 in 3GPP networks are listed below:
-
- 1) DHCPv6 requires an additional server in the network unless the
- (Stateless) DHCPv6 functionality is integrated into an existing
- router already, and it is one box more to be maintained.
-
- 2) DHCPv6 is not necessarily needed for 3GPP UE IPv6 addressing
- (3GPP Stateless Address Autoconfiguration is typically used), and
- not automatically implemented in 3GPP IPv6 UEs.
-
- 3) Scalability and reliability of DHCPv6 in very large 3GPP
- networks (with tens or hundreds of millions of UEs) may be an issue,
- at least the redundancy needs to be taken care of. However, if the
- DHCPv6 service is integrated into the network elements, such as
- router operating system, scalability and reliability is comparable
- with other DNS configuration approaches.
-
- 4) It is sub-optimal to utilize the radio resources in 3GPP
- networks for DHCPv6 messages if there is a simpler alternative
- available.
-
- a) Use of Stateless DHCPv6 adds one round trip delay to the case
- in which the UE can start transmitting data right after the
- Router Advertisement.
-
- 5) If the DNS information (suddenly) changes, Stateless DHCPv6 can
- not automatically update the UE, see [23].
-
-
-
-Jeong, et al. Expires - August 2005 [Page 17]
-\f
-Internet-Draft IPv6 Host Configuration of DNS Server February 2005
-
-
-5.3.4. Well-known Addresses
-
- Using well-known addresses is also a feasible and a light mechanism
- for 3GPP UEs. Those well-known addresses can be preconfigured in
- the UE software and the operator makes the corresponding
- configuration on the network side. So this is a very easy
- mechanism for the UE, but requires some configuration work in the
- network. When using well-known addresses, UE forwards queries to
- any of the preconfigured addresses. In the current proposal [9],
- IPv6 anycast addresses are suggested.
-
- Note: IPv6 DNS configuration proposal based on the use of
- well-known site-local addresses developed at the IPv6 Working Group
- was seen as a feasible mechanism for 3GPP UEs, but opposition by
- some people in the IETF and finally deprecating IPv6 site-local
- addresses made it impossible to standardize it. Note that this
- mechanism is implemented in some existing operating systems today
- (also in some 3GPP UEs) as a last resort of IPv6 DNS configuration.
-
-5.3.5. Recommendations
-
- It is suggested that a lightweight, stateless DNS configuration
- mechanism is specified as soon as possible. From 3GPP UE's and
- networks' point of view, Router Advertisement based mechanism looks
- most promising. The sooner a light, stateless mechanism is
- specified, the sooner we can get rid of using well-known site-local
- addresses for IPv6 DNS configuration.
-
-5.4. Unmanaged Network
-
- There are 4 deployment scenarios of interest in unmanaged networks
- [24]:
-
- 1) A gateway which does not provide IPv6 at all;
-
- 2) A dual-stack gateway connected to a dual-stack ISP;
-
- 3) A dual-stack gateway connected to an IPv4-only ISP; and
-
- 4) A gateway connected to an IPv6-only ISP.
-
-5.4.1. Case A: Gateway does not provide IPv6 at all
-
- In this case, the gateway does not provide IPv6; the ISP may or may
- not provide IPv6. Automatic or Configured tunnels are the
- recommended transition mechanisms for this scenario.
-
-
-
-
-Jeong, et al. Expires - August 2005 [Page 18]
-\f
-Internet-Draft IPv6 Host Configuration of DNS Server February 2005
-
-
- The case where dual-stack hosts behind an NAT, that need access to
- an IPv6 RDNSS, can not be entirely ruled out. The DNS
- configuration mechanism has to work over the tunnel, and the
- underlying tunneling mechanism could be implementing NAT traversal.
- The tunnel server assumes the role of a relay (both for DHCP and
- Well-known anycast addresses approaches).
-
- RA-based mechanism is relatively straightforward in its operation,
- assuming the tunnel server is also the IPv6 router emitting RAs.
- Well-known anycast addresses approach seems also simple in
- operation across the tunnel, but the deployment model using
- Well-known anycast addresses in a tunneled environment is unclear or
- not well understood.
-
-5.4.2. Case B: A dual-stack gateway connected to a dual-stack ISP
-
- This is similar to a typical IPv4 home user scenario, where DNS
- configuration parameters are obtained using DHCP. Except that
- Stateless DHCPv6 is used, as opposed to the IPv4 scenario where the
- DHCP server is stateful (maintains the state for clients).
-
-5.4.3. Case C: A dual-stack gateway connected to an IPv4-only ISP
-
- This is similar to Case B. If a gateway provides IPv6 connectivity
- by managing tunnels, then it is also supposed to provide access to
- an RDNSS. Like this, the tunnel for IPv6 connectivity originates
- from the dual-stack gateway instead of the host.
-
-5.4.4. Case D: A gateway connected to an IPv6-only ISP
-
- This is similar to Case B.
-
-6. Security Considerations
-
- As security requirements depend solely on applications and are
- different application by application, there can be no generic
- requirement defined at higher IP or lower application layer of DNS.
-
- However, it should be noted that cryptographic security requires
- configured secret information that full autoconfiguration and
- cryptographic security are mutually exclusive. People insisting on
- secure full autoconfiguration will get false security, false
- autoconfiguration or both.
-
- In some deployment scenarios [19], where cryptographic security is
- required for applications, the secret information for the
- cryptographic security is preconfigured through which application
- specific configuration data, including those for DNS, can be
-
-
-Jeong, et al. Expires - August 2005 [Page 19]
-\f
-Internet-Draft IPv6 Host Configuration of DNS Server February 2005
-
-
- securely configured. It should be noted that if applications
- requiring cryptographic security depend on DNS, the applications
- also require cryptographic security to DNS. Therefore, the full
- autoconfiguration of DNS is not acceptable.
-
- However, with full autoconfiguration, weaker but still reasonable
- security is being widely accepted and will continue to be
- acceptable. That is, with full autoconfiguration, which means
- there is no cryptographic security for the autoconfiguration, it is
- already assumed that the local environment is secure enough that
- the information from the local autoconfiguration server has
- acceptable security even without cryptographic security. Thus, the
- communication between the local DNS client and local DNS server has
- the acceptable security.
-
- In autoconfiguring recursive servers, DNSSEC may be overkill,
- because DNSSEC [29] needs the configuration and reconfiguration of
- clients at root key roll-over [30][31]. Even if additional keys
- for secure key roll-over are added at the initial configuration,
- they are as vulnerable as the original keys to some forms of
- attacks, such as social hacking. Another problem of using DNSSEC
- and autoconfiguration together is that DNSSEC requires secure time,
- which means secure communication with autoconfigured time servers,
- which requires configured secret information. Therefore, in order
- that the autoconfiguration may be secure, it requires configured
- secret information.
-
- If DNSSEC [29] is used and the signatures are verified on the
- client host, the misconfiguration of a DNS server may be simply
- denial of service. Also, if local routing environment is not
- reliable, clients may be directed to a false resolver with the same
- IP address as the true one.
-
- For security considerations of each approach, refer to the
- corresponding drafts [5]-[9].
-
-7. 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.
- The authors appreciate their contributions.
-
-8. Normative References
-
- [1] S. Bradner, "Intellectual Property Rights in IETF Technology",
- RFC 3668, February 2004.
-
-
-
-Jeong, et al. Expires - August 2005 [Page 20]
-\f
-Internet-Draft IPv6 Host Configuration of DNS Server February 2005
-
-
- [2] S. Bradner, "IETF Rights in Contributions", RFC 3667, February
- 2004.
-
- [3] T. Narten, E. Nordmark and W. Simpson, "Neighbor Discovery for
- IP Version 6 (IPv6)", RFC 2461, December 1998.
-
- [4] S. Thomson and T. Narten, "IPv6 Stateless Address
- Autoconfiguration", RFC 2462, December 1998.
-
- [5] R. Droms et al., "Dynamic Host Configuration Protocol for IPv6
- (DHCPv6)", RFC 3315, July 2003.
-
- [6] R. Droms, "Stateless Dynamic Host Configuration Protocol
- (DHCP) Service for IPv6", RFC 3736, April 2004.
-
- [7] R. Droms et al., "DNS Configuration options for Dynamic Host
- Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, December
- 2003.
-
-9. Informative References
-
- [8] J. Jeong, S. Park, L. Beloeil and S. Madanapalli, "IPv6 DNS
- Discovery based on Router Advertisement",
- draft-jeong-dnsop-ipv6-dns-discovery-04.txt, February 2005,
- Work in Progress.
-
- [9] M. Ohta, "Preconfigured DNS Server Addresses",
- draft-ohta-preconfigured-dns-01.txt, February 2004, Work in
- Progress.
-
- [10] S. Venaas, T. Chown and B. Volz, "Information Refresh Time
- Option for DHCPv6", draft-ietf-dhc-lifetime-03.txt, January
- 2005, Work in Progress.
-
- [11] C. Partridge, T. Mendez and W. Milliken, "Host Anycasting
- Service", RFC 1546, November 1993.
-
- [12] R. Hinden and S. Deering, "Internet Protocol Version 6 (IPv6)
- Addressing Architecture", RFC 3513, April 2003.
-
- [13] M. Lind et al., "Scenarios and Analysis for Introduction IPv6
- into ISP Networks",
- draft-ietf-v6ops-isp-scenarios-analysis-03.txt, June 2004,
- Work in Progress.
-
- [14] J. Arkko et al., "SEcure Neighbor Discovery (SEND)",
- draft-ietf-send-ndopt-06.txt, July 2004, Work in Progress.
-
-
-
-Jeong, et al. Expires - August 2005 [Page 21]
-\f
-Internet-Draft IPv6 Host Configuration of DNS Server February 2005
-
-
- [15] R. Droms and W. Arbaugh, "Authentication for DHCP Messages",
- RFC 3118, June 2001.
-
- [16] J. Bound et al., "IPv6 Enterprise Network Scenarios",
- draft-ietf-v6ops-ent-scenarios-05.txt, July 2004, Work in
- Progress.
-
- [17] O. Troan and R. Droms, "IPv6 Prefix Options for Dynamic Host
- Configuration Protocol (DHCP) version 6", RFC 3633, December
- 2003.
-
- [18] M. Wasserman, Ed., "Recommendations for IPv6 in 3GPP
- Standards", RFC 3314, September 2002.
-
- [19] J. Soininen, Ed., "Transition Scenarios for 3GPP Networks",
- RFC 3574, August 2003.
-
- [20] J. Wiljakka, Ed., "Analysis on IPv6 Transition in 3GPP
- Networks", draft-ietf-v6ops-3gpp-analysis-11.txt, October 2004,
- Work in Progress.
-
- [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] T. Chown, S. Venaas and A. Vijayabhaskar, "Renumbering
- Requirements for Stateless DHCPv6",
- draft-ietf-dhc-stateless-dhcpv6-renumbering-02.txt, October
- 2004, Work in Progress.
-
- [24] C. Huitema et al., "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.
-
- [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.
-
-
-
-Jeong, et al. Expires - August 2005 [Page 22]
-\f
-Internet-Draft IPv6 Host Configuration of DNS Server February 2005
-
-
- [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] D. Eastlake, "Domain Name System Security Extensions", RFC
- 2535, March 1999.
-
- [30] O. Kolkman and R. Gieben, "DNSSEC Operational Practices",
- draft-ietf-dnsop-dnssec-operational-practices-03.txt,
- December 2004.
-
- [31] G. Guette and O. Courtay, "Requirements for Automated Key
- Rollover in DNSSEC",
- draft-ietf-dnsop-key-rollover-requirements-02.txt, January
- 2005.
-
-10. Appendix A - Link-layer Multicast Acknowledgements with RA Option
-
- One benefit of RA option 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 [25]-[28]. Namely,
- 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.
-
- 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.
-
-11. Authors' Addresses
-
- Jaehoon Paul Jeong, Editor
- ETRI/University of Minnesota at Twin Cities
- 117 Pleasant Street SE
- Minneapolis, MN 55455
- USA
-
-
-Jeong, et al. Expires - August 2005 [Page 23]
-\f
-Internet-Draft IPv6 Host Configuration of DNS Server February 2005
-
-
-
- Phone: +1 651 587 7774
- EMail: jjeong@cs.umn.edu
-
- Ralph Droms
- Cisco Systems
- 1414 Massachusetts Ave.
- Boxboro, MA 01719
- USA
-
- Phone: +1 978 936 1674
- EMail: rdroms@cisco.com
-
- Robert M. Hinden
- Nokia
- 313 Fairchild Drive
- Mountain View, CA 94043
- USA
-
- Phone: +1 650 625 2004
- EMail: bob.hinden@nokia.com
-
- Ted Lemon
- Nominum, Inc.
- 950 Charter Street
- Redwood City, CA 94043
- USA
-
- EMail: Ted.Lemon@nominum.com
-
- Masataka Ohta
- Graduate School of Information Science and Engineering
- Tokyo Institute of Technology
- 2-12-1, O-okayama, Meguro-ku
- Tokyo 152-8552
- Japan
-
- Phone: +81 3 5734 3299
- Fax: +81 3 5734 3299
- EMail: mohta@necom830.hpcl.titech.ac.jp
-
- Soohong Daniel Park
- Mobile Platform Laboratory, SAMSUNG Electronics
- 416, Maetan-3dong, Paldal-gu, Suwon
- Gyeonggi-Do
- Korea
-
- Phone: +82 31 200 4508
-
-
-Jeong, et al. Expires - August 2005 [Page 24]
-\f
-Internet-Draft IPv6 Host Configuration of DNS Server February 2005
-
-
- EMail: soohong.park@samsung.com
-
- Suresh Satapati
- Cisco Systems, Inc.
- San Jose, CA 95134
- USA
-
- EMail: satapati@cisco.com
-
- Juha Wiljakka
- Nokia
- Visiokatu 3
- FIN-33720 TAMPERE
- Finland
-
- Phone: +358 7180 48372
- EMail: juha.wiljakka@nokia.com
-
-12. Intellectual 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.
-
-13. Full 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.
-
-
-Jeong, et al. Expires - August 2005 [Page 25]
-\f
-Internet-Draft IPv6 Host Configuration of DNS Server February 2005
-
-
-
- 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.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Jeong, et al. Expires - August 2005 [Page 26]
-\f
--- /dev/null
+
+
+
+DNS Operations WG J. Jeong, Ed.
+Internet-Draft ETRI/University of Minnesota
+Expires: November 6, 2005 May 5, 2005
+
+
+ IPv6 Host Configuration of DNS Server Information Approaches
+ draft-ietf-dnsop-ipv6-dns-configuration-06.txt
+
+Status of this Memo
+
+ This document is an Internet-Draft and is subject to all provisions
+ of Section 3 of RFC 3667. By submitting this Internet-Draft, each
+ author represents that any applicable patent or other IPR claims of
+ which he or she is aware have been or will be disclosed, and any of
+ which he or she become aware will be disclosed, in accordance with
+ RFC 3668.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that
+ other groups may also distribute working documents as Internet-
+ Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress."
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.txt.
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+ This Internet-Draft will expire on November 6, 2005.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2005).
+
+Abstract
+
+ 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. Additionally, it suggests the
+ deployment scenarios in four kinds of networks, such as ISP,
+ Enterprise, 3GPP, and Unmanaged networks, considering multi-solution
+ resolution. Therefore, this document will give the audience a
+
+
+
+Jeong Expires November 6, 2005 [Page 1]
+\f
+Internet-Draft IPv6 Host Configuration of DNS Server May 2005
+
+
+ guideline for IPv6 host DNS configuration.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jeong Expires November 6, 2005 [Page 2]
+\f
+Internet-Draft IPv6 Host Configuration of DNS Server May 2005
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
+ 3. IPv6 DNS Configuration Approaches . . . . . . . . . . . . . . 7
+ 3.1 RA Option . . . . . . . . . . . . . . . . . . . . . . . . 7
+ 3.1.1 Advantages . . . . . . . . . . . . . . . . . . . . . . 8
+ 3.1.2 Disadvantages . . . . . . . . . . . . . . . . . . . . 8
+ 3.1.3 Observations . . . . . . . . . . . . . . . . . . . . . 9
+ 3.2 DHCPv6 Option . . . . . . . . . . . . . . . . . . . . . . 9
+ 3.2.1 Advantages . . . . . . . . . . . . . . . . . . . . . . 11
+ 3.2.2 Disadvantages . . . . . . . . . . . . . . . . . . . . 12
+ 3.2.3 Observations . . . . . . . . . . . . . . . . . . . . . 12
+ 3.3 Well-known Anycast Addresses . . . . . . . . . . . . . . . 12
+ 3.3.1 Advantages . . . . . . . . . . . . . . . . . . . . . . 13
+ 3.3.2 Disadvantages . . . . . . . . . . . . . . . . . . . . 14
+ 3.3.3 Observations . . . . . . . . . . . . . . . . . . . . . 14
+ 4. Interworking among IPv6 DNS Configuration Approaches . . . . . 15
+ 5. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 16
+ 5.1 ISP Network . . . . . . . . . . . . . . . . . . . . . . . 16
+ 5.1.1 RA Option Approach . . . . . . . . . . . . . . . . . . 16
+ 5.1.2 DHCPv6 Option Approach . . . . . . . . . . . . . . . . 17
+ 5.1.3 Well-known Anycast Addresses Approach . . . . . . . . 17
+ 5.2 Enterprise Network . . . . . . . . . . . . . . . . . . . . 17
+ 5.3 3GPP Network . . . . . . . . . . . . . . . . . . . . . . . 18
+ 5.3.1 Currently Available Mechanisms and Recommendations . . 19
+ 5.3.2 RA Extension . . . . . . . . . . . . . . . . . . . . . 19
+ 5.3.3 Stateless DHCPv6 . . . . . . . . . . . . . . . . . . . 20
+ 5.3.4 Well-known Addresses . . . . . . . . . . . . . . . . . 21
+ 5.3.5 Recommendations . . . . . . . . . . . . . . . . . . . 21
+ 5.4 Unmanaged Network . . . . . . . . . . . . . . . . . . . . 22
+ 5.4.1 Case A: Gateway does not provide IPv6 at all . . . . . 22
+ 5.4.2 Case B: A dual-stack gateway connected to a
+ dual-stack ISP . . . . . . . . . . . . . . . . . . . . 22
+ 5.4.3 Case C: A dual-stack gateway connected to an
+ IPv4-only ISP . . . . . . . . . . . . . . . . . . . . 22
+ 5.4.4 Case D: A gateway connected to an IPv6-only ISP . . . 23
+ 6. Security Considerations . . . . . . . . . . . . . . . . . . . 24
+ 6.1 RA Option . . . . . . . . . . . . . . . . . . . . . . . . 25
+ 6.2 DHCPv6 Option . . . . . . . . . . . . . . . . . . . . . . 25
+ 6.3 Well-known Anycast Addresses . . . . . . . . . . . . . . . 25
+ 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 26
+ 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
+ 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
+ 9.1 Normative References . . . . . . . . . . . . . . . . . . . 29
+ 9.2 Informative References . . . . . . . . . . . . . . . . . . 29
+ Author's Address . . . . . . . . . . . . . . . . . . . . . . . 31
+ A. Link-layer Multicast Acknowledgements for RA Option . . . . . 32
+
+
+
+Jeong Expires November 6, 2005 [Page 3]
+\f
+Internet-Draft IPv6 Host Configuration of DNS Server May 2005
+
+
+ Intellectual Property and Copyright Statements . . . . . . . . 33
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jeong Expires November 6, 2005 [Page 4]
+\f
+Internet-Draft IPv6 Host Configuration of DNS Server May 2005
+
+
+1. Introduction
+
+ Neighbor Discovery (ND) for IP Version 6 and IPv6 Stateless Address
+ Autoconfiguration provide the ways to configure either fixed or
+ mobile nodes with one or more IPv6 addresses, default routes and some
+ other parameters [3][4]. 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.
+
+ This document describes three approaches of recursive DNS server
+ address configuration for IPv6 host: (a) RA option [8], (b) DHCPv6
+ option [5]-[7], and (c) Well-known anycast addresses for recursive
+ DNS servers [9]. Also, it suggests the applicable scenarios for four
+ kinds of networks: (a) ISP network, (b) Enterprise network, (c) 3GPP
+ network, and (d) Unmanaged network.
+
+ This document is just an analysis of each possible approach, and does
+ not make any recommendation on a particular one or on a combination
+ of particular ones. Some approaches may even not be adopted at all
+ as a result of further discussion.
+
+ Therefore, the objective of this document is to help the audience
+ select the approaches suitable for IPv6 host configuration of
+ recursive DNS servers.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jeong Expires November 6, 2005 [Page 5]
+\f
+Internet-Draft IPv6 Host Configuration of DNS Server May 2005
+
+
+2. Terminology
+
+ This document uses the terminology described in [3]-[9]. In
+ addition, a new term is defined below:
+
+ o Recursive DNS Server (RDNSS): A Recursive DNS Server is a name
+ server that offers the recursive service of DNS name resolution.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jeong Expires November 6, 2005 [Page 6]
+\f
+Internet-Draft IPv6 Host Configuration of DNS Server May 2005
+
+
+3. IPv6 DNS Configuration Approaches
+
+ In this section, the operational attributes of the three solutions
+ are described in detail.
+
+3.1 RA Option
+
+ The RA approach is to define a new ND option called the RDNSS option
+ that contains a recursive DNS server address. Existing ND transport
+ mechanisms (i.e., advertisements and solicitations) are used. This
+ works in the same way that nodes learn about routers and prefixes.
+ An IPv6 host can configure the IPv6 addresses of one or more RDNSSes
+ via RA message periodically sent by a router or solicited by a Router
+ Solicitation (RS) [8].
+
+ This approach needs RDNSS information to be configured in the routers
+ doing the advertisements. The configuration of RDNSS addresses can
+ be performed manually by an operator or other ways, such as automatic
+ configuration through a DHCPv6 client running on the router. When
+ advertising more than one RDNSS option, an RA message includes as
+ many RDNSS options as RDNSSes.
+
+ Through the ND protocol and RDNSS option along with a prefix
+ information option, an IPv6 host can perform its network
+ configuration of its IPv6 address and RDNSS simultaneously [3][4].
+ The RA option for RDNSS can be used on any network that supports the
+ use of ND.
+
+ 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.
+
+ The RA approach is useful in some mobile environments where the
+ addresses of the RDNSSes are changing because the RA option includes
+ a lifetime field that allows client to use RDNSSes nearer to the
+ client. This can be configured to a value that will require the
+ client to time out the entry and switch over to another RDNSS address
+ [8]. However, from the viewpoint of implementation, the lifetime
+ field would seem to make matters a bit more complex. Instead of just
+ writing to a DNS configuration file, such as resolv.conf for the list
+ of RDNSS addresses, we have to have a daemon around (or a program
+ that is called at the defined intervals) that keeps monitoring the
+ lifetime of RDNSSes all the time.
+
+ The preference value of RDNSS, included in the RDNSS option, allows
+ IPv6 hosts to select primary RDNSS among several RDNSSes; this can be
+ used for the load balancing of RDNSSes [8].
+
+
+
+Jeong Expires November 6, 2005 [Page 7]
+\f
+Internet-Draft IPv6 Host Configuration of DNS Server May 2005
+
+
+3.1.1 Advantages
+
+ The RA option for RDNSS has a number of advantages. These include:
+
+ 1. The RA option is an extension of existing ND/Autoconfig
+ mechanisms [3][4], and does not require a change in the base ND
+ protocol.
+
+ 2. This approach, like ND, works well on a variety of link types
+ including point-to-point links, point-to-multipoint, and
+ multipoint-to-multipoint (i.e., Ethernet LANs), etc. RFC 2461
+ [3] states, however, that there may be some link types on which
+ ND is not feasible; on such links, some other mechanisms will be
+ needed for DNS configuration.
+
+ 3. All of the information a host needs to run the basic Internet
+ applications such as the email, web, ftp, etc., can be obtained
+ with the addition of this option to ND and address
+ autoconfiguration. The use of a single mechanism is more
+ reliable and easier to provide than when the RDNSS information is
+ learned via another protocol mechanism. Debugging problems when
+ multiple protocol mechanisms are being used is harder and much
+ more complex.
+
+ 4. This mechanism works over a broad range of scenarios and
+ leverages IPv6 ND. 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. Also,
+ this works well on links that are high performance (e.g.,
+ Ethernet LANs) and low performance (e.g., Cellular networks). In
+ the latter case, by combining the RDNSS information with the
+ other information in the RA, the host can learn all of the
+ information needed to use most Internet applications, such as the
+ web in a single packet. This not only saves bandwidth where this
+ is an issue, but also minimizes the delay needed to learn the
+ RDNSS information.
+
+ 5. The RA approach could be used as a model for other similar types
+ of configuration information. New RA options for other server
+ addresses, such as NTP server address, that are common to all
+ clients on a subnet would be easy to define.
+
+
+3.1.2 Disadvantages
+
+ 1. ND is mostly implemented in the kernel of operating system.
+ Therefore, if ND supports the configuration of some additional
+ services, such as DNS servers, ND should be extended in the
+
+
+
+Jeong Expires November 6, 2005 [Page 8]
+\f
+Internet-Draft IPv6 Host Configuration of DNS Server May 2005
+
+
+ kernel, and complemented by a user-land process. DHCPv6,
+ however, has more flexibility for the extension of service
+ discovery because it is an application layer protocol.
+
+ 2. The current ND framework should be modified to facilitate the
+ synchronization between another ND cache for RDNSSes in the
+ kernel space and the DNS configuration file in the user space.
+ Because it is unacceptable to write and rewrite to the DNS
+ configuration file (e.g., resolv.conf) from the kernel, another
+ approach is needed. One simple approach to solve this is to have
+ a daemon listening to what the kernel conveys, and to have the
+ daemon do these steps, but such a daemon is not needed with the
+ current ND framework.
+
+ 3. It is necessary to configure RDNSS addresses at least at one
+ router on every link where this information needs to be
+ configured via the RA option.
+
+
+3.1.3 Observations
+
+ The proposed RDNSS RA option along with the IPv6 ND and
+ Autoconfiguration allows a host to obtain all of the information it
+ needs to access the basic Internet services like the web, email, ftp,
+ etc. This is preferable in the environments where hosts use RAs to
+ autoconfigure their addresses and all the hosts on the subnet share
+ the same router and server addresses. If the configuration
+ information can be obtained from a single mechanism, it is preferable
+ because it does not add additional delay, and it uses a minimum of
+ bandwidth. The environments like this include the homes, public
+ cellular networks, and enterprise environments where no per host
+ configuration is needed, but exclude public WLAN hot spots.
+
+ DHCPv6 is preferable where it is being used for address configuration
+ and if there is a need for host specific configuration [5]-[7]. The
+ environments like this are most likely to be the enterprise
+ environments where the local administration chooses to have per host
+ configuration control.
+
+Note
+
+ The observation section is based on what the proponents of each
+ approach think makes a good overall solution.
+
+3.2 DHCPv6 Option
+
+ DHCPv6 [5] includes the "DNS Recursive Name Server" option, through
+ which a host can obtain a list of IP addresses of recursive DNS
+
+
+
+Jeong Expires November 6, 2005 [Page 9]
+\f
+Internet-Draft IPv6 Host Configuration of DNS Server May 2005
+
+
+ servers [7]. The DNS Recursive Name Server option carries a list of
+ IPv6 addresses of RDNSSes to which the host may send DNS queries.
+ The DNS servers are listed in the order of preference for use by the
+ DNS resolver on the host.
+
+ The DNS Recursive Name Server option can be carried in any DHCPv6
+ Reply message, in response to either a Request or an Information
+ request message. Thus, the DNS Recursive Name Server option can be
+ used either when DHCPv6 is used for address assignment, or when
+ DHCPv6 is used only for other configuration information as stateless
+ DHCPv6 [6].
+
+ Stateless DHCPv6 can be deployed either using DHCPv6 servers running
+ on general-purpose computers, or on router hardware. Several router
+ vendors currently implement stateless DHCPv6 servers. Deploying
+ stateless DHCPv6 in routers has the advantage that no special
+ hardware is required, and should work well for networks where DHCPv6
+ is needed for very straightforward configuration of network devices.
+
+ However, routers can also act as DHCPv6 relay agents. In this case,
+ the DHCPv6 server need not be on the router - it can be on a general
+ purpose computer. This has the potential to give the operator of the
+ DHCPv6 server more flexibility in how the DHCPv6 server responds to
+ individual clients - clients can easily be given different
+ configuration information based on their identity, or for any other
+ reason. Nothing precludes adding this flexibility to a router, but
+ generally in current practice, DHCP servers running on general-
+ purpose hosts tend to have more configuration options than those that
+ are embedded in routers.
+
+ DHCPv6 currently provides a mechanism for reconfiguring DHCPv6
+ clients that use a stateful configuration assignment. To do this,
+ the DHCPv6 server sends a Reconfigure message to the client. The
+ client validates the Reconfigure message, and then contacts the
+ DHCPv6 server to obtain updated configuration information. Using
+ this mechanism, it is currently possible to propagate new
+ configuration information to DHCPv6 clients as this information
+ changes.
+
+ The DHC Working Group is currently studying an additional mechanism
+ through which configuration information, including the list of
+ RDNSSes, can be updated. The lifetime option for DHCPv6 [10] assigns
+ a lifetime to configuration information obtained through DHCPv6. At
+ the expiration of the lifetime, the host contacts the DHCPv6 server
+ to obtain updated configuration information, including the list of
+ RDNSSes. This lifetime gives the network administrator another
+ mechanism to configure hosts with new RDNSSes by controlling the time
+ at which the host refreshes the list.
+
+
+
+Jeong Expires November 6, 2005 [Page 10]
+\f
+Internet-Draft IPv6 Host Configuration of DNS Server May 2005
+
+
+ The DHC Working Group has also discussed the possibility of defining
+ an extension to DHCPv6 that would allow the use of multicast to
+ provide configuration information to multiple hosts with a single
+ DHCPv6 message. Because of the lack of deployment experience, the WG
+ has deferred consideration of multicast DHCPv6 configuration at this
+ time. Experience with DHCPv4 has not identified a requirement for
+ multicast message delivery, even in large service provider networks
+ with tens of thousands of hosts that may initiate a DHCPv4 message
+ exchange simultaneously.
+
+3.2.1 Advantages
+
+ The DHCPv6 option for RDNSS has a number of advantages. These
+ include:
+
+ 1. DHCPv6 currently provides a general mechanism for conveying
+ network configuration information to clients. So configuring
+ DHCPv6 servers allows the network administrator to configure
+ RDNSSes along with the addresses of other network services, as
+ well as location-specific information like time zones.
+
+ 2. As a consequence, when the network administrator goes to
+ configure DHCPv6, all the configuration information can be
+ managed through a single service, typically with a single user
+ interface and a single configuration database.
+
+ 3. DHCPv6 allows for the configuration of a host with information
+ specific to that host, so that hosts on the same link can be
+ configured with different RDNSSes as well as with other
+ configuration information. This capability is important in some
+ network deployments such as service provider networks or WiFi hot
+ spots.
+
+ 4. A mechanism exists for extending DHCPv6 to support the
+ transmission of additional configuration that has not yet been
+ anticipated.
+
+ 5. Hosts that require other configuration information such as the
+ addresses of SIP servers and NTP servers are likely to need
+ DHCPv6 for other configuration information.
+
+ 6. The specification for configuration of RDNSSes through DHCPv6 is
+ available as an RFC. No new protocol extensions such as new
+ options are necessary.
+
+ 7. Interoperability among independent implementations has been
+ demonstrated.
+
+
+
+
+Jeong Expires November 6, 2005 [Page 11]
+\f
+Internet-Draft IPv6 Host Configuration of DNS Server May 2005
+
+
+3.2.2 Disadvantages
+
+ The DHCPv6 option for RDNSS has a few disadvantages. These include:
+
+ 1. Update currently requires message from server (however, see
+ [10]).
+
+ 2. Because DNS information is not contained in RA messages, the host
+ must receive two messages from the router, and must transmit at
+ least one message to the router. On networks where bandwidth is
+ at a premium, this is a disadvantage, although on most networks
+ it is not a practical concern.
+
+ 3. Increased latency for initial configuration - in addition to
+ waiting for an RA message, the client must now exchange packets
+ with a DHCPv6 server; even if it is locally installed on a
+ router, this will slightly extend the time required to configure
+ the client. For clients that are moving rapidly from one network
+ to another, this will be a disadvantage.
+
+
+3.2.3 Observations
+
+ In the general case, on general-purpose networks, stateless DHCPv6
+ provides significant advantages and no significant disadvantages.
+ Even in the case where bandwidth is at a premium and low latency is
+ desired, if hosts require other configuration information in addition
+ to a list of RDNSSes or if hosts must be configured selectively,
+ those hosts will use DHCPv6 and the use of the DHCPv6 DNS recursive
+ name server option will be advantageous.
+
+ However, we are aware of some applications where it would be
+ preferable to put the RDNSS information into an RA packet; for
+ example, on a cell phone network, where bandwidth is at a premium and
+ extremely low latency is desired. The final DNS configuration draft
+ should be written so as to allow these special applications to be
+ handled using DNS information in the RA packet.
+
+3.3 Well-known Anycast Addresses
+
+ Anycast uses the same routing system as unicast [11]. However,
+ administrative entities are local ones. The local entities may
+ accept unicast routes (including default routes) to anycast servers
+ from adjacent entities. The administrative entities should not
+ advertise their peers routes to their internal anycast servers, if
+ they want to prohibit external access from some peers to the servers.
+ If some advertisement is inevitable (such as the case with default
+ routes), the packets to the servers should be blocked at the boundary
+
+
+
+Jeong Expires November 6, 2005 [Page 12]
+\f
+Internet-Draft IPv6 Host Configuration of DNS Server May 2005
+
+
+ of the entities. Thus, for this anycast, not only unicast routing
+ but also unicast ND protocols can be used as is.
+
+ First of all, the well-known anycast addresses approach is much
+ different from that discussed at IPv6 Working Group in the past [9].
+ It should be noted that "anycast" in this memo is simpler than that
+ of RFC 1546 [11] and RFC 3513 [12] where it is assumed to be
+ prohibited to have multiple servers on a single link sharing an
+ anycast address. That is, on a link, an anycast address is assumed
+ to be unique. DNS clients today already have redundancy by having
+ multiple well-known anycast addresses configured as RDNSS addresses.
+ There is no point in having multiple RDNSSes sharing an anycast
+ address on a single link.
+
+ The approach with well-known anycast addresses is to set multiple
+ well-known anycast addresses in clients' resolver configuration files
+ from the beginning, say, as factory default. Thus, there is no
+ transport mechanism and no packet format [9].
+
+ An anycast address is an address shared by multiple servers (in this
+ case, the servers are RDNSSes). A request from a client to the
+ anycast address is routed to a server selected by the routing system.
+ However, it is a bad idea to mandate "site" boundary on anycast
+ addresses, because most users just do not have their own servers and
+ want to access their ISPs' across their site boundaries. Larger
+ sites may also depend on their ISPs or may have their own RDNSSes
+ within "site" boundaries.
+
+3.3.1 Advantages
+
+ The basic advantage of the well-known addresses approach is that it
+ uses no transport mechanism. Thus,
+
+ 1. There is no delay to get the response and no further delay by
+ packet losses.
+
+ 2. The approach can be combined with any other configuration
+ mechanisms, such as the RA-based approach and DHCP based
+ approach, as well as the factory default configuration.
+
+ 3. The approach works over any environment where DNS works.
+
+ Another advantage is that the approach needs to configure DNS servers
+ as a router, but nothing else. Considering that DNS servers do need
+ configuration, the amount of overall configuration effort is
+ proportional to the number of the DNS servers and scales linearly.
+ It should be noted that, in the simplest case where a subscriber to
+ an ISP does not have any DNS server, the subscriber naturally
+
+
+
+Jeong Expires November 6, 2005 [Page 13]
+\f
+Internet-Draft IPv6 Host Configuration of DNS Server May 2005
+
+
+ accesses DNS servers of the ISP even though the subscriber and the
+ ISP do nothing and there is no protocol to exchange DNS server
+ information between the subscriber and the ISP.
+
+3.3.2 Disadvantages
+
+ Well-known anycast addresses approach requires that DNS servers (or
+ routers near it as a proxy) act as routers to advertise their anycast
+ addresses to the routing system, which requires some configuration
+ (see the last paragraph of the previous section on the scalability of
+ the effort).
+
+3.3.3 Observations
+
+ If other approaches are used in addition, the well-known anycast
+ addresses should also be set in RA or DHCP configuration files to
+ reduce the configuration effort of users.
+
+ The redundancy by multiple RDNSSes is better provided by multiple
+ servers having different anycast addresses than multiple servers
+ sharing the same anycast address because the former approach allows
+ stale servers to still generate routes to their anycast addresses.
+ Thus, in a routing domain (or domains sharing DNS servers), there
+ will be only one server having an anycast address unless the domain
+ is so large that load distribution is necessary.
+
+ Small ISPs will operate one RDNSS at each anycast address which is
+ shared by all the subscribers. Large ISPs may operate multiple
+ RDNSSes at each anycast address to distribute and reduce load, where
+ the boundary between RDNSSes may be fixed (redundancy is still
+ provided by multiple addresses) or change dynamically. DNS packets
+ with the well-known anycast addresses are not expected (though not
+ prohibited) to cross ISP boundaries, as ISPs are expected to be able
+ to take care of themselves.
+
+ Because "anycast" in this memo is simpler than that of RFC 1546 [11]
+ and RFC 3513 [12] where it is assumed to be administratively
+ prohibited to have multiple servers on a single link sharing an
+ anycast address, anycast in this memo should be implemented as
+ UNICAST of RFC 2461 [3] and RFC 3513 [12]. As a result, ND-related
+ instability disappears. Thus, anycast in well-known anycast
+ addresses approach can and should use the anycast address as a source
+ unicast (according to RFC 3513 [12]) address of packets of UDP and
+ TCP responses. With TCP, if a route flips and packets to an anycast
+ address are routed to a new server, it is expected that the flip is
+ detected by ICMP or sequence number inconsistency and the TCP
+ connection is reset and retried.
+
+
+
+
+Jeong Expires November 6, 2005 [Page 14]
+\f
+Internet-Draft IPv6 Host Configuration of DNS Server May 2005
+
+
+4. Interworking among IPv6 DNS Configuration Approaches
+
+ Three approaches can work together for IPv6 host configuration of
+ RDNSS. This section shows a consideration on how these approaches
+ can interwork each other.
+
+ For ordering between RA and DHCP approaches, the O (Other stateful
+ configuration) flag in RA message can be used [8][32]. If no RDNSS
+ option is included, an IPv6 host may perform DNS configuration
+ through DHCPv6 [5]-[7] regardless of whether the O flag is set or
+ not.
+
+ The well-known anycast addresses approach fully interworks with the
+ other approaches. That is, the other approaches can remove the
+ configuration effort on servers by using the well-known addresses as
+ the default configuration. Moreover, the clients preconfigured with
+ the well-known anycast addresses can be further configured to use
+ other approaches to override the well-known addresses, if the
+ configuration information from other approaches is available.
+ Otherwise, all the clients need to have the well-known anycast
+ addresses preconfigured. In order to use the anycast approach along
+ with two other approaches, there are three choices as follows:
+
+ 1. The first choice is that well-known addresses are used as last
+ resort, when an IPv6 host cannot get RDNSS information through RA
+ and DHCP. The well-known anycast addresses have to be
+ preconfigured in all of IPv6 hosts' resolver configuration files.
+
+ 2. The second is that an IPv6 host can configure well-known
+ addresses as the most preferable in its configuration file even
+ though either an RA option or DHCP option is available.
+
+ 3. The last is that the well-known anycast addresses can be set in
+ RA or DHCP configuration to reduce the configuration effort of
+ users. According to either the RA or DHCP mechanism, the well-
+ known addresses can be obtained by an IPv6 host. Because this
+ approach is the most convenient for users, the last option is
+ recommended.
+
+
+Note
+
+ This section does not necessarily mean this document suggests
+ adopting all these three approaches and making them interwork in the
+ way described here. In fact, some approaches may even not be adopted
+ at all as a result of further discussion.
+
+
+
+
+
+Jeong Expires November 6, 2005 [Page 15]
+\f
+Internet-Draft IPv6 Host Configuration of DNS Server May 2005
+
+
+5. Deployment Scenarios
+
+ Regarding the DNS configuration on the IPv6 host, several mechanisms
+ are being considered at the DNSOP Working Group such as RA option,
+ DHCPv6 option and well-known preconfigured anycast addresses as of
+ today, and this document is a final result from the long thread. In
+ this section, we suggest four applicable scenarios of three
+ approaches for IPv6 DNS configuration.
+
+Note
+
+ In the applicable scenarios, authors do not implicitly push any
+ specific approaches into the restricted environments. No enforcement
+ is in each scenario and all mentioned scenarios are probable. The
+ main objective of this work is to provide a useful guideline for IPv6
+ DNS configuration.
+
+5.1 ISP Network
+
+ A characteristic of ISP network is that multiple Customer Premises
+ Equipment (CPE) devices are connected to IPv6 PE (Provider Edge)
+ routers and each PE connects multiple CPE devices to the backbone
+ network infrastructure [13]. The CPEs may be hosts or routers.
+
+ In the case where the CPE is a router, there is a customer network
+ that is connected to the ISP backbone through the CPE. Typically,
+ each customer network gets a different IPv6 prefix from an IPv6 PE
+ router, but the same RDNSS configuration will be distributed.
+
+ This section discusses how the different approaches to distributing
+ DNS information are compared in an ISP network.
+
+5.1.1 RA Option Approach
+
+ When the CPE is a host, the RA option for RDNSS can be used to allow
+ the CPE to get RDNSS information as well as /64 prefix information
+ for stateless address autoconfiguration at the same time when the
+ host is attached to a new subnet [8]. Because an IPv6 host must
+ receive at least one RA message for stateless address
+ autoconfiguration and router configuration, the host could receive
+ RDNSS configuration information in that RA without the overhead of an
+ additional message exchange.
+
+ When the CPE is a router, the CPE may accept the RDNSS information
+ from the RA on the interface connected to the ISP, and copy that
+ information into the RAs advertised in the customer network.
+
+ This approach is more valuable in the mobile host scenario, in which
+
+
+
+Jeong Expires November 6, 2005 [Page 16]
+\f
+Internet-Draft IPv6 Host Configuration of DNS Server May 2005
+
+
+ the host must receive at least an RA message for detecting a new
+ network, than in other scenarios generally although administrator
+ should configure RDNSS information on the routers. Secure ND [14]
+ can provide extended security when using RA messages.
+
+5.1.2 DHCPv6 Option Approach
+
+ DHCPv6 can be used for RDNSS configuration through the use of the DNS
+ option, and can provide other configuration information in the same
+ message with RDNSS configuration [5]-[7]. The DHCPv6 DNS option is
+ already in place for DHCPv6 as RFC 3646 [7] and DHCPv6-lite or
+ stateless DHCP [6] is nowhere as complex as a full DHCPv6
+ implementation. DHCP is a client-server model protocol, so ISPs can
+ handle user identification on its network intentionally, and also
+ authenticated DHCP [15] can be used for secure message exchange.
+
+ The expected model for deployment of IPv6 service by ISPs is to
+ assign a prefix to each customer, which will be used by the customer
+ gateway to assign a /64 prefix to each network in the customer's
+ network. Prefix delegation with DHCP (DHCPv6 PD) has already been
+ adopted by ISPs for automating the assignment of the customer prefix
+ to the customer gateway [17]. DNS configuration can be carried in
+ the same DHCPv6 message exchange used for DHCPv6 to efficiently
+ provide that information, along with any other configuration
+ information needed by the customer gateway or customer network. This
+ service model can be useful to Home or SOHO subscribers. The Home or
+ SOHO gateway, which is a customer gateway for ISP, can then pass that
+ RDNSS configuration information to the hosts in the customer network
+ through DHCP.
+
+5.1.3 Well-known Anycast Addresses Approach
+
+ The well-known anycast addresses approach is also a feasible and
+ simple mechanism for ISP [9]. The use of well-known anycast
+ addresses avoids some of the security risks in rogue messages sent
+ through an external protocol like RA or DHCPv6. The configuration of
+ hosts for the use of well-known anycast addresses requires no
+ protocol or manual configuration, but the configuration of routing
+ for the anycast addresses requires intervention on the part of the
+ network administrator. Also, the number of special addresses would
+ be equal to the number of RDNSSes that could be made available to
+ subscribers.
+
+5.2 Enterprise Network
+
+ Enterprise network is defined as a network that has multiple internal
+ links, one or more router connections, to one or more Providers and
+ is actively managed by a network operations entity [16]. An
+
+
+
+Jeong Expires November 6, 2005 [Page 17]
+\f
+Internet-Draft IPv6 Host Configuration of DNS Server May 2005
+
+
+ enterprise network can get network prefixes from an ISP by either
+ manual configuration or prefix delegation [17]. In most cases,
+ because an enterprise network manages its own DNS domains, it
+ operates its own DNS servers for the domains. These DNS servers
+ within enterprise network process recursive DNS name resolution
+ requests from IPv6 hosts as RDNSSes. The RDNSS configuration in the
+ enterprise network can be performed like in Section 4, in which three
+ approaches can be used together as follows:
+
+ 1. An IPv6 host can decide which approach is or may be used in its
+ subnet with the O flag in RA message [8][32]. As the first
+ choice in Section 4, well-known anycast addresses can be used as
+ a last resort when RDNSS information cannot be obtained through
+ either an RA option or DHCP option. This case needs IPv6 hosts
+ to preconfigure the well-known anycast addresses in their DNS
+ configuration files.
+
+ 2. When the enterprise prefers the well-known anycast approach to
+ others, IPv6 hosts should preconfigure the well-known anycast
+ addresses like in the first choice.
+
+ 3. The last choice, a more convenient and transparent way, does not
+ need IPv6 hosts to preconfigure the well-known anycast addresses
+ because the addresses are delivered to IPv6 hosts via either the
+ RA option or DHCPv6 option as if they were unicast addresses.
+ This way is most recommended for the sake of user's convenience.
+
+
+5.3 3GPP Network
+
+ The IPv6 DNS configuration is a missing part of IPv6
+ autoconfiguration and an important part of the basic IPv6
+ functionality in the 3GPP User Equipment (UE). The higher level
+ description of the 3GPP architecture can be found in [18], and
+ transition to IPv6 in 3GPP networks is analyzed in [19] and [20].
+
+ In the 3GPP architecture, there is a dedicated link between the UE
+ and the GGSN called the Packet Data Protocol (PDP) Context. This
+ link is created through the PDP Context activation procedure [21].
+ There is a separate PDP context type for IPv4 and IPv6 traffic. If a
+ 3GPP UE user is communicating using IPv6 (having an active IPv6 PDP
+ context), it cannot be assumed that (s)he has simultaneously an
+ active IPv4 PDP context, and DNS queries could be done using IPv4. A
+ 3GPP UE can thus be an IPv6 node, and it needs to somehow discover
+ the address of the RDNSS. Before IP-based services (e.g., web
+ browsing or e-mail) can be used, the IPv6 (and IPv4) RDNSS addresses
+ need to be discovered in the 3GPP UE.
+
+
+
+
+Jeong Expires November 6, 2005 [Page 18]
+\f
+Internet-Draft IPv6 Host Configuration of DNS Server May 2005
+
+
+ Section 5.3.1 briefly summarizes currently available mechanisms in
+ 3GPP networks and recommendations. 5.3.2 analyzes the Router
+ Advertisement based solution, 5.3.3 analyzes the Stateless DHCPv6
+ mechanism, and 5.3.4 analyzes the Well-known addresses approach.
+ Section 5.3.5 finally summarizes the recommendations.
+
+5.3.1 Currently Available Mechanisms and Recommendations
+
+ 3GPP has defined a mechanism, in which RDNSS addresses can be
+ received in the PDP context activation (a control plane mechanism).
+ That is called the Protocol Configuration Options Information Element
+ (PCO-IE) mechanism [22]. The RDNSS addresses can also be received
+ over the air (using text messages), or typed in manually in the UE.
+ Note that the two last mechanisms are not very well scalable. The UE
+ user most probably does not want to type IPv6 RDNSS addresses
+ manually in his/her UE. The use of well-known addresses is briefly
+ discussed in section 5.3.4.
+
+ It is seen that the mechanisms above most probably are not sufficient
+ for the 3GPP environment. IPv6 is intended to operate in a zero-
+ configuration manner, no matter what the underlying network
+ infrastructure is. Typically, the RDNSS address is needed to make an
+ IPv6 node operational - and the DNS configuration should be as simple
+ as the address autoconfiguration mechanism. It must also be noted
+ that there will be additional IP interfaces in some near future 3GPP
+ UEs, e.g., WLAN, and 3GPP-specific DNS configuration mechanisms (such
+ as PCO-IE [22]) do not work for those IP interfaces. In other words,
+ a good IPv6 DNS configuration mechanism should also work in a multi-
+ access network environment.
+
+ From a 3GPP point of view, the best IPv6 DNS configuration solution
+ is feasible for a very large number of IPv6-capable UEs (can be even
+ hundreds of millions in one operator's network), is automatic and
+ thus requires no user action. It is suggested to standardize a
+ lightweight, stateless mechanism that works in all network
+ environments. The solution could then be used for 3GPP, 3GPP2, WLAN
+ and other access network technologies. A light, stateless IPv6 DNS
+ configuration mechanism is thus not only needed in 3GPP networks, but
+ also 3GPP networks and UEs would certainly benefit from the new
+ mechanism.
+
+5.3.2 RA Extension
+
+ Router Advertisement extension [8] is a lightweight IPv6 DNS
+ configuration mechanism that requires minor changes in the 3GPP UE
+ IPv6 stack and Gateway GPRS Support Node (GGSN, the default router in
+ the 3GPP architecture) IPv6 stack. This solution can be specified in
+ the IETF (no action needed in the 3GPP) and taken in use in 3GPP UEs
+
+
+
+Jeong Expires November 6, 2005 [Page 19]
+\f
+Internet-Draft IPv6 Host Configuration of DNS Server May 2005
+
+
+ and GGSNs
+
+ In this solution, an IPv6-capable UE configures DNS information via
+ RA message sent by its default router (GGSN), i.e., RDNSS option for
+ recursive DNS server is included in the RA message. This solution is
+ easily scalable for a very large number of UEs. The operator can
+ configure the RDNSS addresses in the GGSN as a part of normal GGSN
+ configuration. The IPv6 RDNSS address is received in the Router
+ Advertisement, and an extra Round Trip Time (RTT) for asking RDNSS
+ addresses can be avoided.
+
+ If thinking about the cons, this mechanism still requires
+ standardization effort in the IETF, and the end nodes and routers
+ need to support this mechanism. The equipment software update
+ should, however, be pretty straightforward, and new IPv6 equipment
+ could support RA extension already from the beginning.
+
+5.3.3 Stateless DHCPv6
+
+ DHCPv6-based solution needs the implementation of Stateless DHCP [6]
+ and DHCPv6 DNS options [7] in the UE, and a DHCPv6 server in the
+ operator's network. A possible configuration is such that the GGSN
+ works as a DHCP relay.
+
+ Pros for Stateless DHCPv6-based solution are
+
+ 1. Stateless DHCPv6 is a standardized mechanism.
+
+ 2. DHCPv6 can be used for receiving other configuration information
+ than RDNSS addresses, e.g., SIP server addresses.
+
+ 3. DHCPv6 works in different network environments.
+
+ 4. When DHCPv6 service is deployed through a single, centralized
+ server, the RDNSS configuration information can be updated by the
+ network administrator at a single source.
+
+ Some issues with DHCPv6 in 3GPP networks are listed below:
+
+ 1. DHCPv6 requires an additional server in the network unless the
+ (Stateless) DHCPv6 functionality is integrated into a router
+ already existing, and that means one box more to be maintained.
+
+ 2. DHCPv6 is not necessarily needed for 3GPP UE IPv6 addressing
+ (3GPP Stateless Address Autoconfiguration is typically used), and
+ not automatically implemented in 3GPP IPv6 UEs.
+
+
+
+
+
+Jeong Expires November 6, 2005 [Page 20]
+\f
+Internet-Draft IPv6 Host Configuration of DNS Server May 2005
+
+
+ 3. Scalability and reliability of DHCPv6 in very large 3GPP networks
+ (with tens or hundreds of millions of UEs) may be an issue, at
+ least the redundancy needs to be taken care of. However, if the
+ DHCPv6 service is integrated into the network elements, such as a
+ router operating system, scalability and reliability is
+ comparable with other DNS configuration approaches.
+
+ 4. It is sub-optimal to utilize the radio resources in 3GPP networks
+ for DHCPv6 messages if there is a simpler alternative available.
+
+ * The use of Stateless DHCPv6 adds one round trip delay to the
+ case in which the UE can start transmitting data right after
+ the Router Advertisement.
+
+ 5. If the DNS information (suddenly) changes, Stateless DHCPv6 can
+ not automatically update the UE, see [23].
+
+
+5.3.4 Well-known Addresses
+
+ Using well-known addresses is also a feasible and a light mechanism
+ for 3GPP UEs. Those well-known addresses can be preconfigured in the
+ UE software and the operator makes the corresponding configuration on
+ the network side. So this is a very easy mechanism for the UE, but
+ requires some configuration work in the network. When using well-
+ known addresses, UE forwards queries to any of the preconfigured
+ addresses. In the current proposal [9], IPv6 anycast addresses are
+ suggested.
+
+Note
+
+ The IPv6 DNS configuration proposal based on the use of well-known
+ site-local addresses developed at the IPv6 Working Group was seen as
+ a feasible mechanism for 3GPP UEs, but opposition by some people in
+ the IETF and finally deprecating IPv6 site-local addresses made it
+ impossible to standardize it. Note that this mechanism is
+ implemented in some existing operating systems today (also in some
+ 3GPP UEs) as a last resort of IPv6 DNS configuration.
+
+5.3.5 Recommendations
+
+ It is suggested that a lightweight, stateless DNS configuration
+ mechanism is specified as soon as possible. From a 3GPP UE and
+ network point of view, the Router Advertisement based mechanism looks
+ most promising. The sooner a light, stateless mechanism is
+ specified, the sooner we can get rid of using well-known site-local
+ addresses for IPv6 DNS configuration.
+
+
+
+
+Jeong Expires November 6, 2005 [Page 21]
+\f
+Internet-Draft IPv6 Host Configuration of DNS Server May 2005
+
+
+5.4 Unmanaged Network
+
+ There are 4 deployment scenarios of interest in unmanaged networks
+ [24]:
+
+ 1. A gateway which does not provide IPv6 at all;
+
+ 2. A dual-stack gateway connected to a dual-stack ISP;
+
+ 3. A dual-stack gateway connected to an IPv4-only ISP; and
+
+ 4. A gateway connected to an IPv6-only ISP.
+
+
+5.4.1 Case A: Gateway does not provide IPv6 at all
+
+ In this case, the gateway does not provide IPv6; the ISP may or may
+ not provide IPv6. Automatic or Configured tunnels are the
+ recommended transition mechanisms for this scenario.
+
+ The case where dual-stack hosts behind an NAT, that need access to an
+ IPv6 RDNSS, cannot be entirely ruled out. The DNS configuration
+ mechanism has to work over the tunnel, and the underlying tunneling
+ mechanism could be implementing NAT traversal. The tunnel server
+ assumes the role of a relay (both for DHCP and Well-known anycast
+ addresses approaches).
+
+ RA-based mechanism is relatively straightforward in its operation,
+ assuming the tunnel server is also the IPv6 router emitting RAs.
+ Well-known anycast addresses approach seems also simple in operation
+ across the tunnel, but the deployment model using Well-known anycast
+ addresses in a tunneled environment is unclear or not well
+ understood.
+
+5.4.2 Case B: A dual-stack gateway connected to a dual-stack ISP
+
+ This is similar to a typical IPv4 home user scenario, where DNS
+ configuration parameters are obtained using DHCP. Except that
+ Stateless DHCPv6 is used, as opposed to the IPv4 scenario where the
+ DHCP server is stateful (maintains the state for clients).
+
+5.4.3 Case C: A dual-stack gateway connected to an IPv4-only ISP
+
+ This is similar to Case B. If a gateway provides IPv6 connectivity by
+ managing tunnels, then it is also supposed to provide access to an
+ RDNSS. Like this, the tunnel for IPv6 connectivity originates from
+ the dual-stack gateway instead of the host.
+
+
+
+
+Jeong Expires November 6, 2005 [Page 22]
+\f
+Internet-Draft IPv6 Host Configuration of DNS Server May 2005
+
+
+5.4.4 Case D: A gateway connected to an IPv6-only ISP
+
+ This is similar to Case B.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jeong Expires November 6, 2005 [Page 23]
+\f
+Internet-Draft IPv6 Host Configuration of DNS Server May 2005
+
+
+6. Security Considerations
+
+ As security requirements depend solely on applications and are
+ different application by application, there can be no generic
+ requirement defined at IP or application layer for DNS.
+
+ However, it should be noted that cryptographic security requires
+ configured secret information that full autoconfiguration and
+ cryptographic security are mutually exclusive. People insisting on
+ secure full autoconfiguration will get false security, false
+ autoconfiguration or both.
+
+ In some deployment scenarios [19], where cryptographic security is
+ required for applications, the secret information for the
+ cryptographic security is preconfigured through which application
+ specific configuration data, including those for DNS, can be securely
+ configured. It should be noted that if applications requiring
+ cryptographic security depend on DNS, the applications also require
+ cryptographic security to DNS. Therefore, the full autoconfiguration
+ of DNS is not acceptable.
+
+ However, with full autoconfiguration, weaker but still reasonable
+ security is being widely accepted and will continue to be acceptable.
+ That is, with full autoconfiguration, which means there is no
+ cryptographic security for the autoconfiguration, it is already
+ assumed that the local environment is secure enough that the
+ information from the local autoconfiguration server has acceptable
+ security even without cryptographic security. Thus, the
+ communication between the local DNS client and local DNS server has
+ acceptable security.
+
+ In autoconfiguring recursive servers, DNSSEC may be overkill, because
+ DNSSEC [29] needs the configuration and reconfiguration of clients at
+ root key roll-over [30][31]. Even if additional keys for secure key
+ roll-over are added at the initial configuration, they are as
+ vulnerable as the original keys to some forms of attacks, such as
+ social hacking. Another problem of using DNSSEC and
+ autoconfiguration together is that DNSSEC requires secure time, which
+ means secure communication with autoconfigured time servers, which
+ requires configured secret information. Therefore, in order that the
+ autoconfiguration may be secure, it requires configured secret
+ information.
+
+ If DNSSEC [29] is used and the signatures are verified on the client
+ host, the misconfiguration of a DNS server may be simply denial of
+ service. Also, if local routing environment is not reliable, clients
+ may be directed to a false resolver with the same IP address as the
+ true one.
+
+
+
+Jeong Expires November 6, 2005 [Page 24]
+\f
+Internet-Draft IPv6 Host Configuration of DNS Server May 2005
+
+
+6.1 RA Option
+
+ The security of RA option for RDNSS is the same as the ND protocol
+ security [3][8]. The RA option does not add any new vulnerability.
+
+ It should be noted 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, the 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 NA replies, answer RS or NS requests, etc.
+ All of this can be done independently of implementing ND. Therefore,
+ the RA option for RDNSS does not add to the vulnerability.
+
+ Security issues regarding the ND protocol were discussed at IETF SEND
+ (Securing Neighbor Discovery) Working Group and RFC 3971 for the ND
+ security has been published [14].
+
+6.2 DHCPv6 Option
+
+ The DNS Recursive Name Server option may be used by an intruder DHCP
+ server to cause DHCP clients to send DNS queries to an intruder DNS
+ recursive name server [7]. The results of these misdirected DNS
+ queries may be used to spoof DNS names.
+
+ To avoid attacks through the DNS Recursive Name Server option, the
+ DHCP client SHOULD require DHCP authentication (see section
+ "Authentication of DHCP messages" in RFC 3315 [5]) before installing
+ a list of DNS recursive name servers obtained through authenticated
+ DHCP.
+
+6.3 Well-known Anycast Addresses
+
+ 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.
+
+
+
+
+
+
+
+
+Jeong Expires November 6, 2005 [Page 25]
+\f
+Internet-Draft IPv6 Host Configuration of DNS Server May 2005
+
+
+7. Contributors
+
+ Ralph Droms
+ Cisco Systems, Inc.
+ 1414 Massachusetts Ave.
+ Boxboro, MA 01719
+ US
+
+ Phone: +1 978 936 1674
+ Email: rdroms@cisco.com
+
+
+ Robert M. Hinden
+ Nokia
+ 313 Fairchild Drive
+ Mountain View, CA 94043
+ US
+
+ Phone: +1 650 625 2004
+ Email: bob.hinden@nokia.com
+
+
+ Ted Lemon
+ Nominum, Inc.
+ 950 Charter Street
+ Redwood City, CA 94043
+ US
+
+ Email: Ted.Lemon@nominum.com
+
+
+ Masataka Ohta
+ Tokyo Institute of Technology
+ 2-12-1, O-okayama, Meguro-ku
+ Tokyo 152-8552
+ Japan
+
+ Phone: +81 3 5734 3299
+ Fax: +81 3 5734 3299
+ Email: mohta@necom830.hpcl.titech.ac.jp
+
+
+ Soohong Daniel Park
+ Mobile Platform Laboratory, SAMSUNG Electronics
+ 416 Maetan-3dong, Yeongtong-Gu
+ Suwon, Gyeonggi-Do 443-742
+ Korea
+
+
+
+
+Jeong Expires November 6, 2005 [Page 26]
+\f
+Internet-Draft IPv6 Host Configuration of DNS Server May 2005
+
+
+ Phone: +82 31 200 4508
+ Email: soohong.park@samsung.com
+
+
+ Suresh Satapati
+ Cisco Systems, Inc.
+ San Jose, CA 95134
+ US
+
+ Email: satapati@cisco.com
+
+
+ Juha Wiljakka
+ Nokia
+ Visiokatu 3
+ FIN-33720, TAMPERE
+ Finland
+
+ Phone: +358 7180 48372
+ Email: juha.wiljakka@nokia.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jeong Expires November 6, 2005 [Page 27]
+\f
+Internet-Draft IPv6 Host Configuration of DNS Server May 2005
+
+
+8. 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]
+\f
+Internet-Draft IPv6 Host Configuration of DNS Server May 2005
+
+
+9. References
+
+9.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 IPv6
+
+
+
+Jeong Expires November 6, 2005 [Page 29]
+\f
+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]
+\f
+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]
+\f
+Internet-Draft IPv6 Host Configuration of DNS Server May 2005
+
+
+Appendix 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]
+\f
+Internet-Draft IPv6 Host Configuration of DNS Server May 2005
+
+
+Intellectual 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]
+\f
Network Working Group S. Woolf
Internet-Draft Internet Systems Consortium, Inc.
-Expires: January 16, 2005 D. Conrad
+Expires: September 14, 2005 D. Conrad
Nominum, Inc.
- July 18, 2004
+ March 13, 2005
- Identifying an Authoritative Name `Server
- draft-ietf-dnsop-serverid-02
+ Identifying an Authoritative Name Server
+ draft-ietf-dnsop-serverid-04
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
- of section 3 of RFC 3667. By submitting this Internet-Draft, each
+ of Section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
- The list of current Internet-Drafts can be accessed at http://
- www.ietf.org/ietf/1id-abstracts.txt.
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
- This Internet-Draft will expire on January 16, 2005.
+ This Internet-Draft will expire on September 14, 2005.
Copyright Notice
- Copyright (C) The Internet Society (2004). All Rights Reserved.
+ Copyright (C) The Internet Society (2005).
Abstract
IP address, it is sometimes difficult to tell which of a pool of name
servers has answered a particular query. A standardized mechanism to
determine the identity of a name server responding to a particular
- query would be useful, particularly as a diagnostic aid. Existing ad
-Woolf & Conrad Expires January 16, 2005 [Page 1]
+Woolf & Conrad Expires September 14, 2005 [Page 1]
\f
-Internet-Draft Identifying an Authoritative Name `Server July 2004
+Internet-Draft Identifying an Authoritative Name Server March 2005
+ query would be useful, particularly as a diagnostic aid. Existing ad
hoc mechanisms for addressing this concern are not adequate. This
document attempts to describe the common ad hoc solution to this
- problem, including its advantages and disadvantasges, and to
+ problem, including its advantages and disadvantages, and to
characterize an improved mechanism.
-
-Woolf & Conrad Expires January 16, 2005 [Page 2]
+Woolf & Conrad Expires September 14, 2005 [Page 2]
\f
-Internet-Draft Identifying an Authoritative Name `Server July 2004
+Internet-Draft Identifying an Authoritative Name Server March 2005
1. Introduction
-Woolf & Conrad Expires January 16, 2005 [Page 3]
+Woolf & Conrad Expires September 14, 2005 [Page 3]
\f
-Internet-Draft Identifying an Authoritative Name `Server July 2004
+Internet-Draft Identifying an Authoritative Name Server March 2005
2. Rationale
balancing solutions, including the use of shared unicast addresses as
documented in [RFC3258].
- An unfortunate side effect of these load balancing solutions is that
- traditional methods of determining which server is responding can be
- unreliable. Specifically, non-DNS methods such as ICMP ping, TCP
- connections, or non-DNS UDP packets (e.g., as generated by tools such
- as "traceroute"), etc., can end up going to a different server than
- that which receives the DNS queries.
-
- The widespread use of the existing convention suggests a need for a
- documented, interoperable means of querying the identity of a
- nameserver that may be part of an anycast or load-balancing cluster.
- At the same time, however, it also has some drawbacks that argue
- against standardizing it as it's been practiced so far.
+ An unfortunate side effect of these load balancing solutions, and
+ some changes in management practices as the public Internet has
+ evolved, is that traditional methods of determining which server is
+ responding can be unreliable. Specifically, non-DNS methods such as
+ ICMP ping, TCP connections, or non-DNS UDP packets (such as those
+ generated by tools such as "traceroute"), etc., can end up going to a
+ different server than that which receives the DNS queries.
+ There is a well-known and frequently-used technique for determining
+ an identity for a nameserver more specific than the
+ possibly-non-unique "server that answered my query". The widespread
+ use of the existing convention suggests a need for a documented,
+ interoperable means of querying the identity of a nameserver that may
+ be part of an anycast or load-balancing cluster. At the same time,
+ however, it also has some drawbacks that argue against standardizing
+ it as it's been practiced so far.
-
-
-
-Woolf & Conrad Expires January 16, 2005 [Page 4]
+Woolf & Conrad Expires September 14, 2005 [Page 4]
\f
-Internet-Draft Identifying an Authoritative Name `Server July 2004
+Internet-Draft Identifying an Authoritative Name Server March 2005
3. Existing Conventions
For reference, the other well-known name used by recent versions of
BIND within the CHAOS class "BIND." domain is "VERSION.BIND." A
- query for a TXT RR for this name will return an administratively re-
- definable string which defaults to the version of the server
- responding.
+ query for a TXT RR for this name will return an administratively
+ defined string which defaults to the version of the server
+ responding. This is, however, not generally implemented by other
+ vendors.
3.1 Advantages
There are several valuable attributes to this mechanism, which
account for its usefulness.
- 1. This mechanism is within the DNS protocol itself. An
- identification mechanism that relies on the DNS protocol is more
- likely to be successful (although not guaranteed) in going to the
- same machine as a "normal" DNS query.
- 2. It is simple to configure. An administrator can easily turn on
+ 1. The "hostname.bind" query response mechanism is within the DNS
+ protocol itself. An identification mechanism that relies on the
+ DNS protocol is more likely to be successful (although not
+ guaranteed) in going to the same machine as a "normal" DNS query.
+ 2. Since the identity information is requested and returned within
+ the DNS protocol, it doesn't require allowing any other query
+ mechanism to the server, such as holes in firewalls for
+ otherwise-unallowed ICMP Echo requests. Thus it does not require
+ any special exceptions to site security policy.
+ 3. It is simple to configure. An administrator can easily turn on
this feature and control the results of the relevant query.
- 3. It allows the administrator complete control of what information
+ 4. It allows the administrator complete control of what information
is given out in the response, minimizing passive leakage of
implementation or configuration details. Such details are often
considered sensitive by infrastructure operators.
At the same time, there are some forbidding drawbacks to the
VERSION.BIND mechanism that argue against standardizing it as it
currently operates.
+
+
+
+
+Woolf & Conrad Expires September 14, 2005 [Page 5]
+\f
+Internet-Draft Identifying an Authoritative Name Server March 2005
+
+
1. It requires an additional query to correlate between the answer
to a DNS query under normal conditions and the supposed identity
of the server receiving the query. There are a number of
2. It reserves an entire class in the DNS (CHAOS) for what amounts
to one zone. While CHAOS class is defined in [RFC1034] and
[RFC1035], it's not clear that supporting it solely for this
-
-
-
-Woolf & Conrad Expires January 16, 2005 [Page 5]
-\f
-Internet-Draft Identifying an Authoritative Name `Server July 2004
-
-
purpose is a good use of the namespace or of implementation
effort.
3. It is implementation specific. BIND is one DNS implementation.
- At the time of this writing, it is probably the most prevalent,
- for authoritative servers anyway. This does not justify
- standardizing on its ad hoc solution to a problem shared across
- many operators and implementors.
+ At the time of this writing, it is probably the most prevalent
+ for authoritative servers. This does not justify standardizing
+ on its ad hoc solution to a problem shared across many operators
+ and implementors.
The first of the listed disadvantages is technically the most
serious. It argues for an attempt to design a good answer to the
-
-
-
-
-
-
-
-Woolf & Conrad Expires January 16, 2005 [Page 6]
+Woolf & Conrad Expires September 14, 2005 [Page 6]
\f
-Internet-Draft Identifying an Authoritative Name `Server July 2004
+Internet-Draft Identifying an Authoritative Name Server March 2005
4. Characteristics of an Implementation Neutral Convention
information to be part of a normal, operational query. It SHOULD
also permit a separate, dedicated query for the server's
identifying information.
- 2. The new mechanism should not require dedicated namespaces or
+ 2. The new mechanism SHOULD not require dedicated namespaces or
other reserved values outside of the existing protocol mechanisms
- for these, i.e. the OPT pseudo-RR.
+ for these, i.e. the OPT pseudo-RR. In particular, it should not
+ propagate the existing drawback of requiring support for a CLASS
+ and top level domain in the authoritative server (or the querying
+ tool) to be useful.
3. Support for the identification functionality SHOULD be easy to
implement and easy to enable. It MUST be easy to disable and
SHOULD lend itself to access controls on who can query for it.
-
-
-
-Woolf & Conrad Expires January 16, 2005 [Page 7]
+Woolf & Conrad Expires September 14, 2005 [Page 7]
\f
-Internet-Draft Identifying an Authoritative Name `Server July 2004
+Internet-Draft Identifying an Authoritative Name Server March 2005
5. IANA Considerations
-Woolf & Conrad Expires January 16, 2005 [Page 8]
+Woolf & Conrad Expires September 14, 2005 [Page 8]
\f
-Internet-Draft Identifying an Authoritative Name `Server July 2004
+Internet-Draft Identifying an Authoritative Name Server March 2005
6. Security Considerations
- Providing identifying information as to which server is responding
- can be seen as information leakage and thus a security risk. This
- motivates the suggestion above that a new mechanism for server
- identification allow the administrator to disable the functionality
- altogether or partially restrict availability of the data. It also
- suggests that the serverid data should not be readily correlated with
- a hostname or unicast IP address that may be considered private to
- the nameserver operator's management infrastructure.
+ Providing identifying information as to which server is responding to
+ a particular query from a particular location in the Internet can be
+ seen as information leakage and thus a security risk. This motivates
+ the suggestion above that a new mechanism for server identification
+ allow the administrator to disable the functionality altogether or
+ partially restrict availability of the data. It also suggests that
+ the serverid data should not be readily correlated with a hostname or
+ unicast IP address that may be considered private to the nameserver
+ operator's management infrastructure.
Propagation of protocol or service meta-data can sometimes expose the
application to denial of service or other attack. As DNS is a
-
-Woolf & Conrad Expires January 16, 2005 [Page 9]
+Woolf & Conrad Expires September 14, 2005 [Page 9]
\f
-Internet-Draft Identifying an Authoritative Name `Server July 2004
+Internet-Draft Identifying an Authoritative Name Server March 2005
7. Acknowledgements
Berkeley Internet Name Daemon package. Comments and questions on
earlier drafts were provided by Bob Halley, Brian Wellington, Andreas
Gustafsson, Ted Hardie, Chris Yarnell, Randy Bush, and members of the
- ICANN Root Server System Advisory Committee. The newest draft takes
- a significantly different direction from previous versions, owing to
- discussion among contributors to the DNSOP working group and others,
- particularly Olafur Gudmundsson, Ed Lewis, Bill Manning, Sam Weiler,
- and Rob Austein.
+ ICANN Root Server System Advisory Committee. The newest version
+ takes a significantly different direction from previous versions,
+ owing to discussion among contributors to the DNSOP working group and
+ others, particularly Olafur Gudmundsson, Ed Lewis, Bill Manning, Sam
+ Weiler, and Rob Austein.
-Woolf & Conrad Expires January 16, 2005 [Page 10]
+Woolf & Conrad Expires September 14, 2005 [Page 10]
\f
-Internet-Draft Identifying an Authoritative Name `Server July 2004
+Internet-Draft Identifying an Authoritative Name Server March 2005
Intellectual Property Statement
Copyright Statement
- Copyright (C) The Internet Society (2004). This document is subject
+ 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.
-Woolf & Conrad Expires January 16, 2005 [Page 11]
+Woolf & Conrad Expires September 14, 2005 [Page 11]
\f
projects / thirdparty / bind9.git / commitdiff
