draft-ietf-ipv6-dns-discovery-06.txt   draft-ietf-ipv6-dns-discovery-07.txt 
Network Working Group Alain Durand Network Working Group Alain Durand
INTERNET-DRAFT SUN Microsystems, inc. INTERNET-DRAFT SUN Microsystems, inc.
August 21, 2002 Jun-ichiro itojun Hagino October 25, 2002 Jun-ichiro itojun Hagino
Expires February 2002 IIJ Research Laboratory Expires April 2002 IIJ Research Laboratory
Dave Thaler Dave Thaler
Microsoft Microsoft
Well known site local unicast addresses for DNS resolver Well known site local unicast addresses
<draft-ietf-ipv6-dns-discovery-06.txt> to communicate with recursive DNS servers
<draft-ietf-ipv6-dns-discovery-07.txt>
Status of this memo Status of this memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at line 31 skipping to change at line 32
Internet Drafts are valid for a maximum of six months and may be Internet Drafts are valid for a maximum of six months and may be
updated, replaced, or obsoleted by other documents at any time. It updated, replaced, or obsoleted by other documents at any time. It
is inappropriate to use Internet Drafts as reference material or to is inappropriate to use Internet Drafts as reference material or to
cite them other than as a "work in progress". cite them other than as a "work in progress".
To view the list Internet-Draft Shadow Directories, see To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
This documents specifies a method for nodes to find a DNS resolver This documents specifies 3 well known addresses to configure stub
with minimum configuration in the network and without running a resolvers on IPv6 nodes to enable them to communicate with recursive
discovery protocol on the nodes. This method is to be used in last DNS server with minimum configuration in the network and without
resort, when no other information about the addresses of DNS running a discovery protocol on the end nodes. This method may be
resolvers is available. used when no other information about the addresses of recursive DNS
servers is available. Implementation of stub resolvers using this as
default configuration must provide a way to override this.
Copyright notice Copyright notice
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2002). All Rights Reserved.
1. Introduction 1. Introduction
RFC 2462 [ADDRCONF] provides a way to autoconfigure nodes with one or RFC 2462 [ADDRCONF] provides a way to autoconfigure nodes with one or
more IPv6 address and default routes. more IPv6 address and default routes.
However, for a node to be fully operational on a network, many other However, for a node to be fully operational on a network, many other
parameters are needed, such as the address of a DNS resolver, mail parameters are needed, such as the address of a name server that
relays, web proxies, etc. Except for name resolution, all the other offer recursive service (a.k.a. recursive DNS server), mail relays,
services are usually described using names, not addresses, such as web proxies, etc. Except for name resolution, all the other services
are usually described using names, not addresses, such as
smtp.myisp.net or webcache.myisp.net. For obvious bootstrapping smtp.myisp.net or webcache.myisp.net. For obvious bootstrapping
reasons, a node needs to be configured with the IP address (and not reasons, a node needs to be configured with the IP address (and not
the name) of a DNS resolver. As IPv6 addresses look much more the name) of a recursive DNS server. As IPv6 addresses look much
complex than IPv4 ones, there is some incentive to make this more complex than IPv4 ones, there is some incentive to make this
configuration as automatic and simple as possible. configuration as automatic and simple as possible.
Although it would be desirable to have all configuration parameters Although it would be desirable to have all configuration parameters
configured/discovered automatically, it is common practice in IPv4 configured/discovered automatically, it is common practice in IPv4
today to ask the user to do manual configuration for some of them by today to ask the user to do manual configuration for some of them by
entering server names in a configuration form. So, a solution that entering server names in a configuration form. So, a solution that
will allow for automatic configuration of the DNS resolver is seen as will allow for automatic configuration of the recursive DNS server is
an important step forward in the autoconfiguration story. seen as an important step forward in the autoconfiguration story.
The intended usage scenario for this proposal is a home or enterprise The intended usage scenario for this proposal is a home or enterprise
network where IPv6 nodes are plugged/unplugged with minimum network where IPv6 nodes are plugged/unplugged with minimum
management and use local resources available on the network to management and use local resources available on the network to
autoconfigure. This proposal is also usefull in cellular networks autoconfigure. This proposal is also useful in cellular networks
where all moble devices are included within the same site. where all mobile devices are included within the same site.
2. Pre-configuration vs discovery 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 [KEYWORDS].
2. Well known addresses vs discovery
Some of the discussions in the past around DNS server discovery have Some of the discussions in the past around DNS server discovery have
been trying to characterize the solution space into stateless versus been trying to characterize the solution space into stateless versus
stateful or server-oriented versus severless. It is not absolutely stateful or server oriented versus severless. It is not absolutely
clear how much state if any needs to be kept to perform DNS server clear how much state if any needs to be kept to perform DNS server
discovery, and, although the semantic differences between a router discovery, and, although the semantic differences between a router
and a server are well understood from a conceptual perspective, the and a server are well understood from a conceptual perspective, the
current implementations tend to blur the picture. In another attempt current implementations tend to blur the picture. In another attempt
to characterize different approaches, one can look at how much to characterize different approaches, one can look at how much
intelligence a client needs to have in order to use the service. intelligence a client needs to have in order to use the service.
One avenue is to ask the IPv6 node to participate in a discovery One avenue is to ask the IPv6 node to participate in a discovery
protocol, such as SLP or DHCP, learn the address of the server and protocol, such as SLP or DHCP, learn the address of the server and
send packets to this server. Another one is to pre-configure (hard- send packets to this server. Another one is to configure the IPv6
code) a local scope address on the IPv6 node and let it send packets node with well known addresses and let the local routing system
directly to this address, with the underlying assumption that the forward packets to the right place. This document explores this
routing system will forward them to the right place. This document later avenue of configuration using well known addresses that does
explores this later avenue of pre-configuration that does not require not require participation of the end node in any discovery mechanism.
participation of the end node in the DNS resolver discovery
mechanism.
The mechanism described here is to be used as a last resort, in the 3. Reserved prefix and addresses
absence of any information about the addresses of DNS resolvers. If
other configuration mechanisms are available, they should be tried
first.
Note to implementors: The mechanism described here is:
- intended for ongoing use and not not just for bootstrapping
- intended to populate a stub resolver's list of available
recursive servers only if that list is otherwise unpopulated
- providing reliability through redundancy using three unicast
addresses.
Implementing only the mechanism described in this memo may end up 3.1 Stub resolver configuration
causing some interoperability problems when operating in networks
where no DNS resolver is configured with the well known addresses.
Thus, it is recommended to implement also other mechanisms for
overriding this default, for example: manual configuration, L2
mechanisms and/or DHCPv6.
3. Reserved prefix and addresses This memo reserved three well known IPv6 site local addresses.
The basic idea of this proposal is to reserve three well known IPv6 In the absence of any other information about the addresses of
site local addresses for DNS resolvers and then have the routing recursive DNS servers, IPv6 stub-resolvers MAY use any of those three
system forward the DNS request to them. IPv6 addresses in their list of candidate recursive DNS servers.
IPv6 stub-resolvers implementing this proposal are pre-configured 3.2 Recursive DNS servers configuration
with those three IPv6 addresses as DNS resolver.
Local DNS resolvers should be configured with one of those three Within sites, one or more recursive DNS server SHOULD be configured
addresses to enable clients to switch from one to the other if one with any of those three addresses. It is RECOMMENDED that large sites
fails. deploy 3 recursive DNS servers, one for each reserved address. Small
site could use only one recursive DNS server and assign the 3
addresses to it.
A solution to enable clients to reach the DNS resolvers is to inject 3.3 Rationale for the choice of three addresses
host routes in the local routing system. Examples of methods for
injecting host routes and a brief discussion of their fate sharing Three was chosen based on common practice in many places in the
properties are presented here: industry. While it's true that if the first one fails, that it's
unlikely the second one will succeed (due to there really being no
DNS server at all), using multiple addresses is important so that
when ones do exist, the host can fail over to a second server more
quickly than routing converges. Three servers is a compromise between
extra reliability and increased complexity (maintaining additional
servers, having multiple entries in the routing system, additional
delays before the stub resolver returns an error,...).
Another reason to have multiple addresses is to avoid the need to use
of anycast addresses to achieve reliability through redundancy. On
top of the classic problems (TCP sessions, ICMP messages,...) using
an anycast address would hide the real locations of the recursive DNS
servers to the stub resolver, prohibiting it to keep track of which
servers are performing correctly. For this particular matter, using
well known addresses is no different than configuring the stub
resolver with regular addresses taken from the local site.
3.4 Implementation considerations
Stub resolver implementation MAY be configured by default using those
addresses. However, implementing only the mechanism described in this
memo may end up causing some interoperability problems when operating
in networks where no recursive DNS server is configured with any of
the well known addresses. Thus, stub resolvers MUST implement
mechanisms for overriding this default, for example: manual
configuration, L2 mechanisms and/or DHCPv6.
4. Routing
A solution to enable the stub resolvers to reach the recursive DNS
servers is to inject host routes in the local routing system.
Examples of methods for injecting host routes and a brief discussion
of their fate sharing properties are presented here:
a) Manual injection of routes by a router on the same subnet. a) Manual injection of routes by a router on the same subnet.
If the node running the DNS resolver goes down, the router may or If the node running the recursive DNS server goes down, the router
may not be notified and keep announcing the route. may or may not be notified and keep announcing the route.
b) Running a routing protocol on the same node running the DNS b) Running a routing protocol on the same node running the DNS
resolver. resolver.
If the process running the DNS resolver dies, the routing protocol If the process running the recursive DNS server dies, the routing
may or may not be notified and keep annoucing the route. protocol may or may not be notified and keep announcing the route.
c) Running a routing protocol within the same process running the c) Running a routing protocol within the same process running the
DNS resolver. recursive DNS server.
If the DNS resolver and the routing protocol run in separated If the recursive DNS server and the routing protocol run in
threads, similar concerns as above are true. separated threads, similar concerns as above are true.
d) Having an "announcement" protocol that the DNS resolver could d) Developing an "announcement" protocol that the recursive DNS
use to advertize the host route to the nearby router. Details of server could use to advertize the host route to the nearby router.
such a protocols are out of scope of this document, but something Details of such a protocol are out of scope of this document, but
similar to [MLD] is possible. something similar to [MLD] is possible. However, the three first
mechanisms should cover most cases.
An alternate solution is to configure a link with the well known An alternate solution is to configure a link with the well known
prefix and position the three DNS resolvers on that link. The prefix and position the three recursive DNS servers on that link.
advantage of this method is that host routes are not necessary , the The advantage of this method is that host routes are not necessary ,
well known prefix is advertized to the routing system by the routers the well known prefix is advertised to the routing system by the
on the link. However, in the event of a problem on the physical link, routers on the link. However, in the event of a problem on the
all resolvers will become unreachable. physical link, all resolvers will become unreachable.
IANA considerations for this prefix are covered in Section 6. IANA considerations for this prefix are covered in Section 6.
4. Site local versus global scope considerations 5. Site local versus global scope considerations
The rationales for having a site local prefix are: The rationales for having a site local prefix are:
-a) Using a site local prefix will ensure that the traffic to the -a) Using a site local prefix will ensure that the traffic to the
DNS resolver stays local to the site. This will prevent the DNS recursive DNS servers stays local to the site. This will prevent
requests from accidentally leaking out of the site. However, the the DNS requests from accidentally leaking out of the site.
local resolver can implement a policy to forward DNS resolution of However, the local resolver can implement a policy to forward DNS
non-local addresses to an external DNS resolver. resolution of non-local addresses to an external DNS resolver.
-b) Reverse DNS resolution of site local addresses is only -b) Reverse DNS resolution of site local addresses is only
meaningful within the site. Thus, making sure that such queries meaningful within the site. Thus, making sure that such queries
are first sent to a DNS resolver located within the site perimeter are first sent to a recursive DNS server located within the site
increase their likelyhood of success. perimeter increase their likelihood of success.
5. Examples of use 6. Examples of use
This section presents example scenarios showing how the mechanism This section presents example scenarios showing how the mechanism
described in this memo can co-exist with other techniques, namely described in this memo can co-exist with other techniques, namely
manual configuration and DHCPv6 discovery. manual configuration and DHCPv6 discovery.
5.1 Simple case, general purpose DNS resolver Note: those examples are just there to illustrate some usage
scenarios and in no way do they suggest any recommended practices.
This example shows the case of an enterprise or a cellular network 6.1 Simple case, general purpose recursive DNS server
that manages a full flavor general purpose DNS resolver and a large
number of nodes running DNS stub resolvers. The DNS resolver is
performing (and caching) all the recursive queries on behalf of the
stub resolvers. Those stub resolvers are either manually configured
with the IPv6 address of the resolver or with one (or several) of the
well known site local unicast addresses defined in this memo.
------------------------------------------- This example shows the case of a network that manages one recursive
DNS server and a large number of nodes running DNS stub resolvers.
The recursive DNS server is performing (and caching) all the
recursive queries on behalf of the stub resolvers. The recursive DNS
server is configured with an IPv6 address taken from the prefix
delegated to the site and with the 3 well known addresses defined in
this memo. The stub resolvers are either configured with the "real"
IPv6 address of the recursive DNS server or with the well known site
local unicast addresses defined in this memo.
--------------------------------------------
| | | |
| --------------------- | | --------------------- |
| |manually configured| |
| |DNS stub resolver | | | |DNS stub resolver | |
| |configured with the| |
| |"real" address of | |
| |the recursive DNS | |
| |server | |
| --------------------- | | --------------------- |
| ---------- | | | ----------- | |
| |DNS |<----------- | | |recursive| | |
| |resolver|<----------- | | |DNS |<---------- |
| ---------- | | | |server |<---------------- |
| ----------- | |
| ---------------------- |
| |DNS stub resolver | |
| |configured with 3 | |
| |well known addresses| |
| ---------------------- |
| |
--------------------------------------------
(The recursive DNS server is configured to listen both on
its IPv6 address and on the well known address)
6.2 Three recursive DNS servers
This is a similar example as above, except that three recursive DNS
resolvers are configured instead of just one.
-------------------------------------------
| |
| --------------------- | | --------------------- |
| |DNS stub resolver | | | |DNS stub resolver | |
| |configured with | | | |configured with the| |
| |well known address | | | |"real" address of | |
| |the recursive DNS | |
| |server | |
| --------------------- | | --------------------- |
| | |
| ----------- | |
| |recursive| | |
| |DNS |<---------| |
| |server 1 |<---------|------ |
| ----------- | | |
| | | |
| ----------- | | |
| |recursive| | | |
| |DNS |<---------| | |
| |server 2 |<---------|-----| |
| ----------- | | |
| | | |
| ----------- | | |
| |recursive| | | |
| |DNS |<---------- | |
| |server 3 |<---------------| |
| ----------- | |
| ---------------------- |
| |DNS stub resolver | |
| |configured with 3 | |
| |well known addresses| |
| ---------------------- |
| | | |
------------------------------------------- -------------------------------------------
(The DNS resolver is configured to listen both on (The recursive DNS server is configured to listen both on
its IPv6 address and on the well known address) its IPv6 address and on the well known address)
5.2 DNS forwarder 6.3 DNS forwarder
A drawback of the choice of site local scope for the reserved A drawback of the choice of site local scope for the reserved
addresses for DNS resolver is that, in the case of a home/small addresses for recursive DNS server is that, in the case of a
office network connected to an ISP, DNS traffic cannot be sent home/small office network connected to an ISP, DNS traffic cannot be
directly to the ISP DNS resolver without having the ISP and all its sent directly to the ISP recursive DNS server without having the ISP
customers share the same definition of site. and all its customers share the same definition of site.
In this scenario, the home/small office network is connected to the In this scenario, the home/small office network is connected to the
ISP router (PE) via an edge router (CPE). ISP router (PE) via an edge router (CPE).
------------- -------------
/ | / |
-------- -------------- / | -------- ----- / |
|ISP PE| |customer CPE| / Customer | |ISP PE| |CPE| / Customer |
| |===========| |====< site | | |===========| |====< site |
| | | | \ | | | | | \ |
-------- -------------- \ | -------- ----- \ |
\ | \ |
------------- -------------
The customer router CPE could be configured on its internal interface The customer router CPE could be configured on its internal interface
with one of the reserved site local addresses and listen for DNS with one of the reserved site local addresses and listen for DNS
queries. It would be configured to use one (or several) of the well queries. It would be configured to use one (or several) of the well
known site local unicast addresses within the ISP's site to send its known site local unicast addresses within the ISP's site to send its
own queries to. It would act as a DNS forwarder, forwarding queries own queries to. It would act as a DNS forwarder, forwarding queries
received on its internal interface to the ISP's DNS resolver. received on its internal interface to the ISP's recursive DNS server.
------------- -------------
/ | / |
---------- -------------- / | ---------- -------------- / |
|ISP | |customer CPE| / Customer | |ISP | | CPE| / Customer |
|DNS |===========| DNS|====< site | |DNS |===========| DNS|====< site |
|resolver| <------|---forwarder|-----\---- | |server | <------|---forwarder|-----\---- |
---------- -------------- \ | ---------- -------------- \ |
\ | \ |
------------- -------------
In this configuration, the CPE is acting as a multi-sited router. In this configuration, the CPE is acting as a multi-sited router.
5.3 DNS forwarder with DHCPv6 interactions 6.4 DNS forwarder with DHCPv6 interactions
In this variant scenario, DHCPv6 is be used between the PE and CPE to In this variant scenario, DHCPv6 is be used between the PE and CPE to
do prefix delegation [DELEG] and DNS resolver discovery. do prefix delegation [DELEG] and recursive DNS server discovery.
------------- -------------
/ | / |
-------- -------------- / | -------- -------------- / |
|ISP | |customer CPE| / Customer | |ISP | |customer CPE| / Customer |
|DHCPv6|===========| DHCPv6|====< site | |DHCPv6|===========| DHCPv6|====< site |
|server| <------|------client| \ | |server| <------|------client| \ |
-------- -------------- \ | -------- -------------- \ |
\ | \ |
------------- -------------
This example will show how DHCPv6 and well known site local unicast This example will show how DHCPv6 and well known site local unicast
addresses cooperate to enable the internal nodes to access DNS. addresses cooperate to enable the internal nodes to access DNS.
The customer router CPE is configured on its internal interface with The customer router CPE is configured on its internal interface with
one of the reserved site local addresses and listen for DNS queries. one of the reserved site local addresses and listen for DNS queries.
It would act as a DNS forwarder, as in 5.2, forwarding those queries It would act as a DNS forwarder, as in 5.2, forwarding those queries
to the DNS resolver pointed out by the ISP in the DHCPv6 exchange. to the recursive DNS server pointed out by the ISP in the DHCPv6
exchange.
------------- -------------
/ | / |
---------- -------------- / | ---------- -------------- / |
|ISP | |customer CPE| / Customer | |ISP | |customer CPE| / Customer |
|DNS |===========| DNS|====< site | |DNS |===========| DNS|====< site |
|resolver| <------|---forwarder|-----\---- | |resolver| <------|---forwarder|-----\---- |
---------- -------------- \ | ---------- -------------- \ |
\ | \ |
------------- -------------
The same CPE router could also implement a local DHCPv6 server and The same CPE router could also implement a local DHCPv6 server and
advertises itself as DNS forwarder. advertizes itself as DNS forwarder.
------------- -------------
/ | / |
-------- -------------- / Customer | -------- -------------- / Customer |
|ISP PE| |customer CPE| / site | |ISP PE| |customer CPE| / site |
| |===========|DHCPv6 |====< | | |===========|DHCPv6 |====< |
| | |server------|-----\---> | | | |server------|-----\---> |
-------- -------------- \ | -------- -------------- \ |
\ | \ |
------------- -------------
skipping to change at line 303 skipping to change at line 394
------------- -------------
/ | / |
---------- -------------- / Customer | ---------- -------------- / Customer |
|ISP | |customer CPE| / site | |ISP | |customer CPE| / site |
|DNS |===========| DNS|====< | |DNS |===========| DNS|====< |
|resolver| <------|---forwarder|-----\----DHCPv6 | |resolver| <------|---forwarder|-----\----DHCPv6 |
---------- -------------- \ client | ---------- -------------- \ client |
\ | \ |
------------- -------------
(The address of the DNS forwarder is aquired via DHCPv6.) (The address of the DNS forwarder is acquired via DHCPv6.)
b) other nodes simply send their DNS request to the reserved site b) other nodes simply send their DNS request to the reserved site
local addresses. local addresses.
------------- -------------
/ | / |
---------- -------------- / customer | ---------- -------------- / customer |
|ISP | |customer CPE| / site | |ISP | |customer CPE| / site |
|DNS |===========| DNS|====< | |DNS |===========| DNS|====< |
|resolver| <------|---forwarder|-----\----non DHCPv6| |resolver| <------|---forwarder|-----\----non DHCPv6|
---------- -------------- \ node | ---------- -------------- \ node |
\ | \ |
------------- -------------
(Internal nodes use the reserved site local unicast address.) (Internal nodes use the reserved site local unicast address.)
A variant of this scenario is the CPE can decide to pass the global A variant of this scenario is the CPE can decide to pass the global
address of the ISP DNS resolver in the DHCPv6 exchange with the address of the ISP recursive DNS server in the DHCPv6 exchange with
internal nodes. the internal nodes.
6. IANA considerations 7. IANA considerations
The site local prefix fec0:0000:0000:ffff::/64 is to be reserved out The site local prefix fec0:0000:0000:ffff::/64 is to be reserved out
of the site local fec0::/10 prefix. of the site local fec0::/10 prefix.
The unicast addresses fec0:000:0000:ffff::1, fec0:000:0000:ffff::2 The unicast addresses fec0:000:0000:ffff::1, fec0:000:0000:ffff::2
and fec0:000:0000:ffff::3 are to be reserved for DNS resolver and fec0:000:0000:ffff::3 are to be reserved for recursive DNS server
configuration. configuration.
All other addresses within the fec0:0000:0000:ffff::/64 are reserved All other addresses within the fec0:0000:0000:ffff::/64 are reserved
for future use and are expected to be assigned only with IESG for future use and are expected to be assigned only with IESG
approval. approval.
7. Security Considerations 8. Security Considerations
Ensuring that queries reach a legitimate DNS server relies on the Ensuring that queries reach a legitimate DNS server relies on the
security of the IPv6 routing infrastructure. The issues here are the security of the IPv6 routing infrastructure. The issues here are the
same as those for protecting basic IPv6 connectivity. same as those for protecting basic IPv6 connectivity.
IPsec/IKE can be used as the well-known addresses are used as unicast IPsec/IKE can be used as the well known addresses are used as unicast
addresses. addresses.
The payload can be protected using standard DNS security techniques. The payload can be protected using standard DNS security techniques.
If the client can preconfigure a well known private or public key If the client can preconfigure a well known private or public key
then TSIG [TSIG] can be used with the same packets presented for the then TSIG [TSIG] can be used with the same packets presented for the
query. If this is not the case, then TSIG keys will have to be query. If this is not the case, then TSIG keys will have to be
negotiated using [TKEY]. After the client has the proper key then negotiated using [TKEY]. After the client has the proper key then
the query can be performed. the query can be performed.
The use of site local addresses instead of global addresses will The use of site local addresses instead of global addresses will
ensure the DNS queries issued by host using this mechanism will not ensure the DNS queries issued by host using this mechanism will not
leak out of the site. leak out of the site.
8. References 9. References
[KEYWORDS]
Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[ADDRCONF] [ADDRCONF]
Thomson, S., and T. Narten, "IPv6 Stateless Address Thomson, S., and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998. Autoconfiguration", RFC 2462, December 1998.
[MLD] [MLD]
Deering, S., Fenner, W., Haberman, B., Deering, S., Fenner, W., Haberman, B.,
"Multicast Listener Discovery (MLD) for IPv6", "Multicast Listener Discovery (MLD) for IPv6",
RFC2710, October 1999. RFC2710, October 1999.
skipping to change at line 379 skipping to change at line 474
"Secret Key Transaction Authentication for DNS (TSIG)", "Secret Key Transaction Authentication for DNS (TSIG)",
RFC2845, May 2000. RFC2845, May 2000.
[TKEY] [TKEY]
D. Eastlake, "Secret Key Establishment for DNS (TKEY RR)", D. Eastlake, "Secret Key Establishment for DNS (TKEY RR)",
RFC2930, September 2000. RFC2930, September 2000.
[DHCPv6] [DHCPv6]
Bound, J., Carney, M., Perkins, C., Lemon, T., Volz, B. and Bound, J., Carney, M., Perkins, C., Lemon, T., Volz, B. and
Droms, R. (ed.), "Dynamic host Configuration Protocol for IPv6 Droms, R. (ed.), "Dynamic host Configuration Protocol for IPv6
(DHCPv6)", draft-ietf-dhc-dhcpv6-23 (work in progress), (DHCPv6)", draft-ietf-dhc-dhcpv6-27 (work in progress),
Februray 2002. Februray 2002.
[DELEG] [DELEG]
Troan, O., Droms, R., "IPv6 Prefix Options for DHCPv6", Troan, O., Droms, R., "IPv6 Prefix Options for DHCPv6",
draft-troan-dhcpv6-opt-prefix-delegation-00.txt (work in progress), draft-troan-dhcpv6-opt-prefix-delegation-01.txt (work in progress),
February 2002. February 2002.
9. Authors' Addresses 10. Authors' Addresses
Alain Durand Alain Durand
SUN microsystems, inc. SUN microsystems, inc.
901 San Antonio rd UMPK 17-202 17 Network Circle, UMPK 17-202
Palo Alto, CA 94303, USA. Menlo Park, CA 94025
Email: Alain.Durand@sun.com Email: Alain.Durand@sun.com
Jun-ichiro itojun HAGINO Jun-ichiro itojun HAGINO
Research Laboratory, Internet Initiative Japan Inc. Research Laboratory, Internet Initiative Japan Inc.
Takebashi Yasuda Bldg., Takebashi Yasuda Bldg.,
3-13 Kanda Nishiki-cho, 3-13 Kanda Nishiki-cho,
Chiyoda-ku, Tokyo 101-0054, JAPAN Chiyoda-ku, Tokyo 101-0054, JAPAN
Email: itojun@iijlab.net Email: itojun@iijlab.net
Dave Thaler Dave Thaler
Microsoft Microsoft
One Microsoft Way One Microsoft Way
Redmond, CA 98052, USA Redmond, CA 98052, USA
Email: dthaler@microsoft.com Email: dthaler@microsoft.com
10. Full Copyright Statement 11. Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/