One document matched: draft-beloeil-ipv6-dns-resolver-option-01.txt
Differences from draft-beloeil-ipv6-dns-resolver-option-00.txt
Individual Submission Luc Beloeil
Internet Draft France Telecom R&D
<draft-beloeil-ipv6-dns-resolver-option-01.txt>
Expires: June 2003 January 2003
IPv6 Router Advertisement DNS resolver Option
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026.
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
This document defines the DNS resolver (DNSR) option used to advertise
on a link IPv6 addresses of DNS resolvers. The DNSR option, which lists
the IPv6 addresses of DNS resolvers that all nodes of the link may use
to resolve name or address, is attached to IPv6 Neighbor Discovery
Router Advertisement messages that are sent across a link. This
document specifies the process used by a host to decide how to
configure the IPv6 addresses of DNS resolvers that the host could
use in IPv6 networks. This document defines the mechanism by which a
node processes the DNSR option and updates valid IPv6 addresses
of DNS resolvers.
1. Introduction
This specification defines the DNS resolvers (DNSR) option for the
Neighbor Discovery protocol [DISCOVERY]. The DNSR option adds a new
functionality to Router Advertisement messages so as to enable further
configuration of a node. Router Advertisement messages sent
by a router over a link can be used to assign one or more addresses of
DNS resolvers to the nodes connected to the link.
DNS resolution is a key service for a host connected to an IPv6 network.
Indeed [DISCOVERY] allows any node to autoconfigure a global unicast
addresses and default routes. Moreover DNS Discovery Design Team proposed
several solutions. An option added to Neighbor Discovery protocol was
studied but no definition has been proposed.
DNSR option will allow any node to discover IPv6 addresses of DNS
resolvers (with preference to global-unicast addresses). The purpose is
also to enhance the efficiency of [DISCOVERY] when DHCPv6 is not used.
1.1 Motivation
Many sites, particularly home networks and small companies networks,
are composed of a network with a single Ethernet link, a "plug-and-play"
router, and an uplink to a single provider. The DNSR option provides
a standard mechanism for advertising DNS Resolver IPv6 address within
such sites.
2. Terminology
IP - Internet Protocol Version 6.
node - a device that implements IP.
router - a node that forwards IP packets not addressed to
itself.
link - a facility over which nodes can exchange IP datagrams,
for example, Ethernet, Token Ring, PPP links, and
IP tunnels.
2.1. Requirements
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
document, are to be interpreted as described in [KEYWORDS].
3. DNS resolver option format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Code | Reserved... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ IPv6 address of DNS resolver 1 +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ IPv6 address of DNS resolver n +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
Type XXX [TBD: IANA]
Length (8 + 16 x n) : lenght in bytes of the option
Code 8-bit unsigned integer
0x0 = DNS Resolver Reply used by routers.
0x1 = DNS Resolver Query used by nodes.
If Code is set to 0x1, no IPv6 address MUST be
present.
Reserved 40-bit unused field. It MUST be initialized to zero
by the sender and MUST be ignored by the receiver.
IPv6 address of DNS resolver n
The IPv6 address of the DNS resolver n.
4. Protocol overview
4.1. Deployment scenario
The DNSR option should be sent within Router Advertisements in order to
complete stateless address autoconfiguration. All nodes connected to the
same link might use the DNSR option to configure the IPv6 addresses of
available DNS resolvers those nodes might use for DNS resolutions.
+--------+
| Router |
+--------+
| link
|
------------------------
| | | |
Node1 Node2 Node3 Node4
In such a network, the router allows the node to use stateless
address autoconfiguration and may send unsolicited Router
Advertisement.
A DNS resolver may or may not be connected to the link.
A typical deployment scenario could be a small network on which several
hosts would be connected to a single router. And that router would
interconnect that single-subnet network to an ISP.
4.2. Node operation
As specified in [DISCOVERY], if a receiver does not recognize the
"DNS resolver option", that receiver MUST ignore that option.
4.2.1 Active mode
If a node wants to learn IPv6 addresses of available DNS resolvers,
it SHOULD send a "DNS resolver Query". A "DNS resolver Query" is a
Router Solicitation with a DNSR option.
4.2.2 Passive mode
On any link a node SHOULD listen to Router Advertisements [DISCOVERY].
By that way a node may learn the IPv6 addresses of available DNS
resolvers in the case another node on the link has just queried for
that information, and that a router has just replied by a Router
Advertisement including a DNSR option.
4.3. Router operation
The way the router learns IPv6 addresses of reachable DNS resolver is
out the scope of that document. That could be achieved typically by an
access control protocol, DHCP or manual configuration.
The router MUST NOT send DNSR option in Unsolicited Router
Advertisements.
The router MUST reply to a "DNS resolver query" by sending a "DNS
Resolver Reply". A "DNS Resolver Reply" is a router advertisement with
DNSR option. As specified in [DISCOVERY], that router advertisement MAY
be sent to the soliciting host's address, but the usual case is to
multicast the response to the all-nodes group.
IPv6 address included in the DNSR option MUST not have a scope larger
than the largest scope of the prefixes advertised in the Router
Advertisement. For example, if the Router Advertisement advertises only
site-local prefixes, DNSR option MUST not include global-scope IPv6
addresses, but only local-scope or site-local-scope addresses.
If the router is configured not to send Router Advertisement, any DNS
resolver query MUST be discarded, and DNS Resolver Reply MUST NOT BE
sent.
5. Security considerations
DNSR option in Router Advertisement could introduce DoS attacks if fake
RA are advertised with bogus IPv6 addresses of DNS resoslvers. Nevertheless
such security considerations are actually related to Neighbor Discovery
protocol security.
Security issues regarding the Neighbor Discovery protocol are
discussed in [DISCOVERY] and in IETF send (Securing Neighbor Discovery)
working group.
6. Acknowledgments
This document is heavily based on [DISCOVERY], and the author wishes
to thank T. Narten, E. Nordmark, and W. Simpson for producing it.
The author would also like to acknowledge the work of Jun-ichiro
Itojun Hagino and Kazu Yamamoto and all the DNS Discovery Design Team
in surveying possible mechanisms for site configuration that
eventually lead to this specification. A special thanks to Nathan
Lutchansky from who the form of that draft has been inspired. Thanks
to Pekka Savola, A. Baudot, D. Binet who have reviewed this draft.
7. References
ADDRCONF Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
ADDR-ARCH Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998.
DISCOVERY Narten, T., Nordmark, E. and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461,
December 1998.
KEYWORDS Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
8. Author's Address
Luc Beloeil
France Telecom R&D
42, rue des coutures
BP 6243
14066 CAEN Cedex 4
France
Phone: (33) 02 31 75 93 91
EMail: luc.beloeil@francetelecom.com
9. Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implmentation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
| PAFTECH AB 2003-2026 | 2026-04-23 11:26:34 |