draft-ietf-dhc-dhcpv6-fqdn-02.txt | draft-ietf-dhc-dhcpv6-fqdn-03.txt | |||
---|---|---|---|---|
DHC B. Volz | DHC B. Volz | |||
Internet-Draft Cisco Systems, Inc. | Internet-Draft Cisco Systems, Inc. | |||
Expires: August 19, 2005 February 15, 2005 | Expires: March 28, 2006 September 24, 2005 | |||
The DHCPv6 Client FQDN Option | The DHCPv6 Client FQDN Option | |||
draft-ietf-dhc-dhcpv6-fqdn-02.txt | draft-ietf-dhc-dhcpv6-fqdn-03.txt | |||
Status of this Memo | Status of this Memo | |||
This document is an Internet-Draft and is subject to all provisions | By submitting this Internet-Draft, each author represents that any | |||
of Section 3 of RFC 3667. By submitting this Internet-Draft, each | applicable patent or other IPR claims of which he or she is aware | |||
author represents that any applicable patent or other IPR claims of | have been or will be disclosed, and any of which he or she becomes | |||
which he or she is aware have been or will be disclosed, and any of | aware will be disclosed, in accordance with Section 6 of BCP 79. | |||
which he or she become aware will be disclosed, in accordance with | ||||
RFC 3668. | ||||
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 | other groups may also distribute working documents as Internet- | |||
Internet-Drafts. | Drafts. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
The list of current Internet-Drafts can be accessed at | 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 | The list of Internet-Draft Shadow Directories can be accessed at | |||
http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
This Internet-Draft will expire on August 19, 2005. | This Internet-Draft will expire on March 28, 2006. | |||
Copyright Notice | Copyright Notice | |||
Copyright (C) The Internet Society (2005). | Copyright (C) The Internet Society (2005). | |||
Abstract | Abstract | |||
This document specifies a new Dynamic Host Configuration Protocol for | This document specifies a new Dynamic Host Configuration Protocol for | |||
IPv6, DHCPv6, option which can be used to exchange information about | IPv6, DHCPv6, option which can be used to exchange information about | |||
a DHCPv6 client's fully-qualified domain name and about | a DHCPv6 client's fully-qualified domain name and about | |||
responsibility for updating DNS RRs related to the client's address | responsibility for updating DNS RRs related to the client's address | |||
assignments. | assignments. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 | 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
3. Models of Operation . . . . . . . . . . . . . . . . . . . . 3 | 3. Models of Operation . . . . . . . . . . . . . . . . . . . . . 3 | |||
4. The DHCPv6 Client FQDN Option . . . . . . . . . . . . . . . 4 | 4. The DHCPv6 Client FQDN Option . . . . . . . . . . . . . . . . 4 | |||
4.1 The Flags Field . . . . . . . . . . . . . . . . . . . . . 5 | 4.1. The Flags Field . . . . . . . . . . . . . . . . . . . . . 5 | |||
4.2 The Domain Name Field . . . . . . . . . . . . . . . . . . 6 | 4.2. The Domain Name Field . . . . . . . . . . . . . . . . . . 6 | |||
5. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . . . 6 | 5. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . . . . 6 | |||
5.1 Client Desires to Update AAAA RRs . . . . . . . . . . . . 7 | 5.1. Client Desires to Update AAAA RRs . . . . . . . . . . . . 7 | |||
5.2 Client Desires Server to Do DNS Updates . . . . . . . . . 7 | 5.2. Client Desires Server to Do DNS Updates . . . . . . . . . 7 | |||
5.3 Client Desires No Server DNS Updates . . . . . . . . . . . 7 | 5.3. Client Desires No Server DNS Updates . . . . . . . . . . . 7 | |||
5.4 Domain Name and DNS Update Issues . . . . . . . . . . . . 8 | 5.4. Domain Name and DNS Update Issues . . . . . . . . . . . . 8 | |||
6. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . . . 9 | 6. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . . . . 9 | |||
6.1 When to Perform DNS Updates . . . . . . . . . . . . . . . 9 | 6.1. When to Perform DNS Updates . . . . . . . . . . . . . . . 9 | |||
7. DNS Update Conflicts . . . . . . . . . . . . . . . . . . . . 10 | 7. DNS Update Conflicts . . . . . . . . . . . . . . . . . . . . . 10 | |||
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 11 | 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 | |||
9. Security Considerations . . . . . . . . . . . . . . . . . . 11 | 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 | |||
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 | 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 | 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
11.1 Normative References . . . . . . . . . . . . . . . . . . 12 | 11.1. Normative References . . . . . . . . . . . . . . . . . . . 12 | |||
11.2 Informative References . . . . . . . . . . . . . . . . . 12 | 11.2. Informative References . . . . . . . . . . . . . . . . . . 12 | |||
Author's Address . . . . . . . . . . . . . . . . . . . . . . 13 | Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 | |||
Intellectual Property and Copyright Statements . . . . . . . 14 | Intellectual Property and Copyright Statements . . . . . . . . . . 15 | |||
1. Introduction | 1. Introduction | |||
DNS ([2], [3]) maintains (among other things) the information about | DNS ([2], [3]) maintains (among other things) the information about | |||
mapping between hosts' Fully Qualified Domain Names (FQDNs) [10] and | mapping between hosts' Fully Qualified Domain Names (FQDNs) [10] and | |||
IPv6 addresses assigned to the hosts. The information is maintained | IPv6 addresses assigned to the hosts. The information is maintained | |||
in two types of Resource Records (RRs): AAAA and PTR [12]. The DNS | in two types of Resource Records (RRs): AAAA and PTR [12]. The DNS | |||
update specification ([4]) describes a mechanism that enables DNS | update specification ([4]) describes a mechanism that enables DNS | |||
information to be updated over a network. | information to be updated over a network. | |||
skipping to change at page 4, line 32 | skipping to change at page 4, line 33 | |||
propose one. The range of possible policies is very broad, from | propose one. The range of possible policies is very broad, from | |||
sites where only the DHCPv6 servers have been given credentials that | sites where only the DHCPv6 servers have been given credentials that | |||
the DNS servers will accept, to sites where each individual DHCPv6 | the DNS servers will accept, to sites where each individual DHCPv6 | |||
client has been configured with credentials which allow the client to | client has been configured with credentials which allow the client to | |||
modify its own domain name. Compliant implementations MAY support | modify its own domain name. Compliant implementations MAY support | |||
some or all of these possibilities. Furthermore, this specification | some or all of these possibilities. Furthermore, this specification | |||
applies only to DHCPv6 client and server processes: it does not apply | applies only to DHCPv6 client and server processes: it does not apply | |||
to other processes which initiate DNS updates. | to other processes which initiate DNS updates. | |||
This document describes a new DHCPv6 option which a client can use to | This document describes a new DHCPv6 option which a client can use to | |||
convey all or part of its domain name to a DHCPv6 server. | convey all or part of its domain name to a DHCPv6 server. Site- | |||
Site-specific policy determines whether DHCPv6 servers use the names | specific policy determines whether DHCPv6 servers use the names that | |||
that clients offer or not, and what DHCPv6 servers do in cases where | clients offer or not, and what DHCPv6 servers do in cases where | |||
clients do not supply domain names. | clients do not supply domain names. | |||
4. The DHCPv6 Client FQDN Option | 4. The DHCPv6 Client FQDN Option | |||
To update the IPv6 address to FQDN mapping a DHCPv6 server needs to | To update the IPv6 address to FQDN mapping a DHCPv6 server needs to | |||
know the FQDN of the client for the addresses for the client's IA_NA | know the FQDN of the client for the addresses for the client's IA_NA | |||
bindings. To allow the client to convey its FQDN to the server this | bindings. To allow the client to convey its FQDN to the server this | |||
document defines a new DHCPv6 option, called "Client FQDN". The | document defines a new DHCPv6 option, called "Client FQDN". The | |||
Client FQDN option also contains Flags which DHCPv6 clients and | Client FQDN option also contains Flags which DHCPv6 clients and | |||
servers use to negotiate who does which updates. | servers use to negotiate who does which updates. | |||
skipping to change at page 5, line 33 | skipping to change at page 5, line 33 | |||
flags flag bits used between client and server to | flags flag bits used between client and server to | |||
negotiate who performs which updates | negotiate who performs which updates | |||
domain-name the partial or fully qualified domain name | domain-name the partial or fully qualified domain name | |||
(with length option-len - 1) | (with length option-len - 1) | |||
The Client FQDN option MUST only appear in a message's options field | The Client FQDN option MUST only appear in a message's options field | |||
and applies to all addresses for all IA_NA bindings in the | and applies to all addresses for all IA_NA bindings in the | |||
transaction. | transaction. | |||
4.1 The Flags Field | 4.1. The Flags Field | |||
The format of the Flags field is: | The format of the Flags field is: | |||
0 1 2 3 4 5 6 7 | 0 1 2 3 4 5 6 7 | |||
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ | |||
| MBZ |N|O|S| | | MBZ |N|O|S| | |||
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ | |||
The "S" bit indicates whether the server SHOULD or SHOULD NOT perform | The "S" bit indicates whether the server SHOULD or SHOULD NOT perform | |||
the AAAA RR (FQDN to address) DNS updates. A client sets the bit to | the AAAA RR (FQDN to address) DNS updates. A client sets the bit to | |||
skipping to change at page 6, line 20 | skipping to change at page 6, line 20 | |||
SHOULD perform updates (the PTR RR and possibly the AAAA RR based on | SHOULD perform updates (the PTR RR and possibly the AAAA RR based on | |||
the "S" bit) or to 1 to request that the server SHOULD NOT perform | the "S" bit) or to 1 to request that the server SHOULD NOT perform | |||
any DNS updates. A server sets the "N" bit to indicate whether the | any DNS updates. A server sets the "N" bit to indicate whether the | |||
server SHALL (0) or SHALL NOT (1) perform DNS updates. If the "N" | server SHALL (0) or SHALL NOT (1) perform DNS updates. If the "N" | |||
bit is 1, the "S" bit MUST be 0. | bit is 1, the "S" bit MUST be 0. | |||
The remaining bits in the Flags field are reserved for future | The remaining bits in the Flags field are reserved for future | |||
assignment. DHCPv6 clients and servers which send the Client FQDN | assignment. DHCPv6 clients and servers which send the Client FQDN | |||
option MUST clear the MBZ bits, and they MUST ignore these bits. | option MUST clear the MBZ bits, and they MUST ignore these bits. | |||
4.2 The Domain Name Field | 4.2. The Domain Name Field | |||
The Domain Name part of the option carries all or part of the FQDN of | The Domain Name part of the option carries all or part of the FQDN of | |||
a DHCPv6 client. The data in the Domain Name field MUST be encoded | a DHCPv6 client. The data in the Domain Name field MUST be encoded | |||
as described in Section 8 of [5]. In order to determine whether the | as described in Section 8 of [5]. In order to determine whether the | |||
FQDN has changed between message exchanges, the client and server | FQDN has changed between message exchanges, the client and server | |||
MUST NOT alter the Domain Name field contents unless the FQDN has | MUST NOT alter the Domain Name field contents unless the FQDN has | |||
actually changed. | actually changed. | |||
A client MAY be configured with a fully-qualified domain name or with | A client MAY be configured with a fully-qualified domain name or with | |||
a partial name that is not fully-qualified. If a client knows only | a partial name that is not fully-qualified. If a client knows only | |||
skipping to change at page 7, line 10 | skipping to change at page 7, line 12 | |||
The following describes the behavior of a DHCPv6 client that | The following describes the behavior of a DHCPv6 client that | |||
implements the Client FQDN option. | implements the Client FQDN option. | |||
A client MUST only include the Client FQDN option in SOLICIT, | A client MUST only include the Client FQDN option in SOLICIT, | |||
REQUEST, RENEW, or REBIND messages. | REQUEST, RENEW, or REBIND messages. | |||
A client that sends the Client FQDN option MUST also include the | A client that sends the Client FQDN option MUST also include the | |||
option in the Option Request option if it expects the server to | option in the Option Request option if it expects the server to | |||
include the Client FQDN option in any responses. | include the Client FQDN option in any responses. | |||
5.1 Client Desires to Update AAAA RRs | 5.1. Client Desires to Update AAAA RRs | |||
If a client that owns/maintains its own FQDN wants to be responsible | If a client that owns/maintains its own FQDN wants to be responsible | |||
for updating the FQDN to IPv6 address mapping for the FQDN and | for updating the FQDN to IPv6 address mapping for the FQDN and | |||
address(es) used by the client, the client MUST include the Client | address(es) used by the client, the client MUST include the Client | |||
FQDN option in the SOLICIT with Rapid Commit, REQUEST, RENEW, and | FQDN option in the SOLICIT with Rapid Commit, REQUEST, RENEW, and | |||
REBIND message originated by the client. A client MAY choose to | REBIND message originated by the client. A client MAY choose to | |||
include the Client FQDN option in its SOLICIT messages. The "S" bit | include the Client FQDN option in its SOLICIT messages. The "S" bit | |||
in the Flags field in the option MUST be 0. The "O" and "N" bits | in the Flags field in the option MUST be 0. The "O" and "N" bits | |||
MUST be 0. | MUST be 0. | |||
skipping to change at page 7, line 32 | skipping to change at page 7, line 34 | |||
receives a REPLY message and successfully completes a final check on | receives a REPLY message and successfully completes a final check on | |||
the parameters passed in the message), the client MAY originate an | the parameters passed in the message), the client MAY originate an | |||
update for the AAAA RRs (associated with the client's FQDN) unless | update for the AAAA RRs (associated with the client's FQDN) unless | |||
the server has set the "S" bit to 1. If the "S" is 1, the DHCPv6 | the server has set the "S" bit to 1. If the "S" is 1, the DHCPv6 | |||
client SHOULD NOT initiate an update for the name in the server's | client SHOULD NOT initiate an update for the name in the server's | |||
returned Client FQDN option Domain Name field. However, a DHCPv6 | returned Client FQDN option Domain Name field. However, a DHCPv6 | |||
client that is explicitly configured with a FQDN MAY ignore the state | client that is explicitly configured with a FQDN MAY ignore the state | |||
of the "S" bit if the server's returned name matches the client's | of the "S" bit if the server's returned name matches the client's | |||
configured name. | configured name. | |||
5.2 Client Desires Server to Do DNS Updates | 5.2. Client Desires Server to Do DNS Updates | |||
A client can choose to delegate the responsibility for updating the | A client can choose to delegate the responsibility for updating the | |||
FQDN to IPv6 address mapping for the FQDN and address(es) used by the | FQDN to IPv6 address mapping for the FQDN and address(es) used by the | |||
client to the server. In order to inform the server of this choice, | client to the server. In order to inform the server of this choice, | |||
the client SHOULD include the Client FQDN option in its SOLICIT with | the client SHOULD include the Client FQDN option in its SOLICIT with | |||
Rapid Commit, REQUEST, RENEW, and REBIND message and MAY include the | Rapid Commit, REQUEST, RENEW, and REBIND message and MAY include the | |||
Client FQDN option in its SOLICIT. The "S" bit in the Flags field in | Client FQDN option in its SOLICIT. The "S" bit in the Flags field in | |||
the option MUST be 1. The "O" and "N" bits MUST be 0. | the option MUST be 1. The "O" and "N" bits MUST be 0. | |||
5.3 Client Desires No Server DNS Updates | 5.3. Client Desires No Server DNS Updates | |||
A client can choose to request that the server perform no DNS updates | A client can choose to request that the server perform no DNS updates | |||
on its behalf. In order to inform the server of this choice, the | on its behalf. In order to inform the server of this choice, the | |||
client SHOULD include the Client FQDN option in its SOLICIT with | client SHOULD include the Client FQDN option in its SOLICIT with | |||
Rapid Commit, REQUEST, RENEW, and REBIND messages and MAY include the | Rapid Commit, REQUEST, RENEW, and REBIND messages and MAY include the | |||
Client FQDN option in its SOLICIT. The "N" bit in the Flags field in | Client FQDN option in its SOLICIT. The "N" bit in the Flags field in | |||
the option MUST be 1 and the "S" and "O" bits MUST be 0. | the option MUST be 1 and the "S" and "O" bits MUST be 0. | |||
Once the client's DHCPv6 configuration is completed (the client | Once the client's DHCPv6 configuration is completed (the client | |||
receives a REPLY message and successfully completes a final check on | receives a REPLY message and successfully completes a final check on | |||
the parameters passed in the message), the client MAY originate its | the parameters passed in the message), the client MAY originate its | |||
DNS updates provided the server's "N" bit is 1. If the server's "N" | DNS updates provided the server's "N" bit is 1. If the server's "N" | |||
bit is 0, the server MAY perform the PTR RR updates; and, MAY also | bit is 0, the server MAY perform the PTR RR updates; and, MAY also | |||
perform the AAAA RR updates if the "S" bit is 1. | perform the AAAA RR updates if the "S" bit is 1. | |||
5.4 Domain Name and DNS Update Issues | 5.4. Domain Name and DNS Update Issues | |||
As there is a possibility that the DHCPv6 server is configured to | As there is a possibility that the DHCPv6 server is configured to | |||
complete or replace a domain name that the client sends, the client | complete or replace a domain name that the client sends, the client | |||
MAY find it useful to send the Client FQDN option in its SOLICIT | MAY find it useful to send the Client FQDN option in its SOLICIT | |||
messages. If the DHCPv6 server returns different Domain Name data in | messages. If the DHCPv6 server returns different Domain Name data in | |||
its ADVERTISE message, the client could use that data in performing | its ADVERTISE message, the client could use that data in performing | |||
its own eventual AAAA RR update, or in forming the Client FQDN option | its own eventual AAAA RR update, or in forming the Client FQDN option | |||
that it sends in its subsequent messages. There is no requirement | that it sends in its subsequent messages. There is no requirement | |||
that the client send identical Client FQDN option data in its | that the client send identical Client FQDN option data in its | |||
SOLICIT, REQUEST, RENEW, or REBIND messages. In particular, if a | SOLICIT, REQUEST, RENEW, or REBIND messages. In particular, if a | |||
skipping to change at page 8, line 50 | skipping to change at page 8, line 52 | |||
If a client releases an address prior to the expiration of the valid | If a client releases an address prior to the expiration of the valid | |||
lifetime and the client is responsible for updating its AAAA RR, the | lifetime and the client is responsible for updating its AAAA RR, the | |||
client SHOULD delete the AAAA RR associated with the address before | client SHOULD delete the AAAA RR associated with the address before | |||
sending a RELEASE message. Similarly, if a client is responsible for | sending a RELEASE message. Similarly, if a client is responsible for | |||
updating its AAAA RRs, but is unable to renew the lifetimes for an | updating its AAAA RRs, but is unable to renew the lifetimes for an | |||
address, the client SHOULD attempt to delete the AAAA RR before the | address, the client SHOULD attempt to delete the AAAA RR before the | |||
lifetime on the address is no longer valid. A DHCPv6 client which | lifetime on the address is no longer valid. A DHCPv6 client which | |||
has not been able to delete an AAAA RR which it added SHOULD attempt | has not been able to delete an AAAA RR which it added SHOULD attempt | |||
to notify its administrator, perhaps by emitting a log message. | to notify its administrator, perhaps by emitting a log message. | |||
A client SHOULD NOT perform DNS updates to AAAA RRs for its | A client SHOULD NOT perform DNS updates to AAAA RRs for its non- | |||
non-Global Unicast addresses [7] or temporary addresses [6]. | Global Unicast addresses [7] or temporary addresses [6]. | |||
6. DHCPv6 Server Behavior | 6. DHCPv6 Server Behavior | |||
The following describes the behavior of a DHCPv6 server that | The following describes the behavior of a DHCPv6 server that | |||
implements the Client FQDN option when the client's message includes | implements the Client FQDN option when the client's message includes | |||
the Client FQDN option. | the Client FQDN option. | |||
Servers MUST only include a Client FQDN option in ADVERTISE and REPLY | Servers MUST only include a Client FQDN option in ADVERTISE and REPLY | |||
messages if the client included a Client FQDN option and the Client | messages if the client included a Client FQDN option and the Client | |||
FQDN option is requested by the Option Request Option in the client's | FQDN option is requested by the Option Request Option in the client's | |||
skipping to change at page 9, line 38 | skipping to change at page 9, line 39 | |||
bit does not match the client's "S" bit, the server sets the "O" | bit does not match the client's "S" bit, the server sets the "O" | |||
bit to 1. | bit to 1. | |||
The server MAY be configured to use the name supplied in the client's | The server MAY be configured to use the name supplied in the client's | |||
Client FQDN option, or it MAY be configured to modify the supplied | Client FQDN option, or it MAY be configured to modify the supplied | |||
name, or substitute a different name. The server SHOULD send its | name, or substitute a different name. The server SHOULD send its | |||
notion of the complete FQDN for the client in the Domain Name field. | notion of the complete FQDN for the client in the Domain Name field. | |||
The server MAY simply copy the Domain Name field from the Client FQDN | The server MAY simply copy the Domain Name field from the Client FQDN | |||
option that the client sent to the server. | option that the client sent to the server. | |||
6.1 When to Perform DNS Updates | 6.1. When to Perform DNS Updates | |||
The server SHOULD NOT perform any DNS updates if the "N" bit is 1 in | The server SHOULD NOT perform any DNS updates if the "N" bit is 1 in | |||
the Flags field of the Client FQDN option in the REPLY messages (to | the Flags field of the Client FQDN option in the REPLY messages (to | |||
be) sent to the client. However, the server SHOULD delete any RRs | be) sent to the client. However, the server SHOULD delete any RRs | |||
which it previously added via DNS updates for the client. | which it previously added via DNS updates for the client. | |||
The server MAY perform the PTR RR DNS update (unless the "N" bit is | The server MAY perform the PTR RR DNS update (unless the "N" bit is | |||
1). | 1). | |||
The server MAY perform the AAAA RR DNS update if the "S" bit is 1 in | The server MAY perform the AAAA RR DNS update if the "S" bit is 1 in | |||
skipping to change at page 12, line 7 | skipping to change at page 12, line 10 | |||
10. Acknowledgements | 10. Acknowledgements | |||
Many thanks to Mark Stapp and Yakov Rekhter as this document is based | Many thanks to Mark Stapp and Yakov Rekhter as this document is based | |||
on the DHCPv4 Client FQDN option (draft-ietf-dhc-fqdn-option [9]). | on the DHCPv4 Client FQDN option (draft-ietf-dhc-fqdn-option [9]). | |||
And, to Ted Lemon, Mark Stapp, Josh Littlefield, Kim Kinnear, and | And, to Ted Lemon, Mark Stapp, Josh Littlefield, Kim Kinnear, and | |||
Ralph Droms for discussions on this work. | Ralph Droms for discussions on this work. | |||
11. References | 11. References | |||
11.1 Normative References | 11.1. Normative References | |||
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement | [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement | |||
Levels", BCP 14, RFC 2119, March 1997. | Levels", BCP 14, RFC 2119, March 1997. | |||
[2] Mockapetris, P., "Domain names - concepts and facilities", | [2] Mockapetris, P., "Domain names - concepts and facilities", | |||
STD 13, RFC 1034, November 1987. | STD 13, RFC 1034, November 1987. | |||
[3] Mockapetris, P., "Domain names - implementation and | [3] Mockapetris, P., "Domain names - implementation and | |||
specification", STD 13, RFC 1035, November 1987. | specification", STD 13, RFC 1035, November 1987. | |||
[4] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic | [4] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic | |||
Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April | Updates in the Domain Name System (DNS UPDATE)", RFC 2136, | |||
1997. | April 1997. | |||
[5] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. | [5] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. | |||
Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", | Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", | |||
RFC 3315, July 2003. | RFC 3315, July 2003. | |||
[6] Narten, T. and R. Draves, "Privacy Extensions for Stateless | [6] Narten, T. and R. Draves, "Privacy Extensions for Stateless | |||
Address Autoconfiguration in IPv6", RFC 3041, January 2001. | Address Autoconfiguration in IPv6", RFC 3041, January 2001. | |||
[7] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) | [7] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) | |||
Addressing Architecture", RFC 3513, April 2003. | Addressing Architecture", RFC 3513, April 2003. | |||
[8] Stapp, M., "Resolution of DNS Name Conflicts Among DHCP Clients | [8] Stapp, M., "Resolution of DNS Name Conflicts Among DHCP Clients | |||
(draft-ietf-dhc-ddns-resolution-*.txt)", September 2004. | (draft-ietf-dhc-ddns-resolution-*.txt)", September 2005. | |||
11.2 Informative References | 11.2. Informative References | |||
[9] Stapp, M., Volz, B. and Y. Rekhter, "The DHCP Client FQDN | [9] Stapp, M., Volz, B., and Y. Rekhter, "The DHCP Client FQDN | |||
Option (draft-ietf-dhc-fqdn-option-*.txt)", January 2005. | Option (draft-ietf-dhc-fqdn-option-*.txt)", September 2005. | |||
[10] Marine, A., Reynolds, J. and G. Malkin, "FYI on Questions and | [10] Marine, A., Reynolds, J., and G. Malkin, "FYI on Questions and | |||
Answers - Answers to Commonly asked "New Internet User" | Answers - Answers to Commonly asked "New Internet User" | |||
Questions", RFC 1594, March 1994. | Questions", RFC 1594, March 1994. | |||
[11] Wellington, B., "Secure Domain Name System (DNS) Dynamic | [11] Wellington, B., "Secure Domain Name System (DNS) Dynamic | |||
Update", RFC 3007, November 2000. | Update", RFC 3007, November 2000. | |||
[12] Thomson, S., Huitema, C., Ksinant, V. and M. Souissi, "DNS | [12] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS | |||
Extensions to Support IP Version 6", RFC 3596, October 2003. | Extensions to Support IP Version 6", RFC 3596, October 2003. | |||
Author's Address | Author's Address | |||
Bernard Volz | Bernard Volz | |||
Cisco Systems, Inc. | Cisco Systems, Inc. | |||
1414 Massachusetts Ave. | 1414 Massachusetts Ave. | |||
Boxborough, MA 01719 | Boxborough, MA 01719 | |||
USA | USA | |||
End of changes. 23 change blocks. | ||||
56 lines changed or deleted | 54 lines changed or added | |||
This html diff was produced by rfcdiff 1.27, available from http://www.levkowetz.com/ietf/tools/rfcdiff/ |