draft-ietf-dhc-v6exts-02.txt   draft-ietf-dhc-v6exts-03.txt 
Internet Engineering Task Force C. Perkins Internet Engineering Task Force C. Perkins
INTERNET DRAFT IBM INTERNET DRAFT IBM
27 August 1996 22 November 1996
Extensions for DHCPv6 Extensions for DHCPv6
draft-ietf-dhc-v6exts-02.txt draft-ietf-dhc-v6exts-03.txt
Status of This Memo Status of This Memo
This document is a submission to the Dynamic Host Configuration This document is a submission to the Dynamic Host Configuration
Working Group of the Internet Engineering Task Force (IETF). Comments Working Group of the Internet Engineering Task Force (IETF). Comments
should be submitted to the dhcp-v6@bucknell.edu mailing list. should be submitted to the dhcp-v6@bucknell.edu mailing list.
Distribution of this memo is unlimited. Distribution of this memo is unlimited.
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
skipping to change at page 1, line 35 skipping to change at page 1, line 36
material or to cite them other than as ``work in progress.'' material or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check the To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet- Drafts ``1id-abstracts.txt'' listing contained in the Internet- Drafts
Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast). ftp.isi.edu (US West Coast).
Abstract Abstract
The Dynamic Host Configuration Protocol for IPv6 [4] (DHCPv6) The Dynamic Host Configuration Protocol for IPv6 [3] (DHCPv6)
provides a framework for passing configuration information to hosts provides a framework for passing configuration information to hosts
on a TCP/IP network. Configuration parameters and other control on a TCP/IP network. Configuration parameters and other control
information are carried in tagged data items that are stored in the information are carried in typed data items that are stored in the
"extensions" field of the DHCPv6 message. The data items themselves "extensions" field of the DHCPv6 message. The data items themselves
are also called "extensions." are also called "extensions."
This document specifies the current set of DHCPv6 extensions. This This document specifies the current set of DHCPv6 extensions. This
document will be periodically updated as new extensions are defined. document will be periodically updated as new extensions are defined.
Each superseding document will include the entire current list of Each superseding document will include the entire current list of
valid extensions. valid extensions.
Contents Contents
skipping to change at page 1, line 77 skipping to change at page 1, line 78
4.2.1. Use with the DHCP Advertise message . . . . . . . 6 4.2.1. Use with the DHCP Advertise message . . . . . . . 6
4.2.2. Receiving a DHCP Request with the IPv6 Address 4.2.2. Receiving a DHCP Request with the IPv6 Address
Extension . . . . . . . . . . . . . . . . 6 Extension . . . . . . . . . . . . . . . . 6
4.2.3. Use with the DHCP Reply message . . . . . . . . . 7 4.2.3. Use with the DHCP Reply message . . . . . . . . . 7
4.2.4. Use with the DHCP Reconfigure message . . . . . . 7 4.2.4. Use with the DHCP Reconfigure message . . . . . . 7
4.3. DHCP Relay Considerations . . . . . . . . . . . . . . . . 7 4.3. DHCP Relay Considerations . . . . . . . . . . . . . . . . 7
5. General Extensions 8 5. General Extensions 8
5.1. Time Offset . . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Time Offset . . . . . . . . . . . . . . . . . . . . . . . 8
5.2. Domain Name Server Extension . . . . . . . . . . . . . . 8 5.2. Domain Name Server Extension . . . . . . . . . . . . . . 8
5.3. Directory Agent Extension . . . . . . . . . . . . . . . . 8 5.3. Domain Name . . . . . . . . . . . . . . . . . . . . . . . 8
5.4. Service Scope Extension . . . . . . . . . . . . . . . . . 10
5.5. Naming Authority Extension . . . . . . . . . . . . . . . 10
5.6. Domain Name . . . . . . . . . . . . . . . . . . . . . . . 10
6. IP Layer Parameters per Interface 11 6. Service Location Extensions 9
6.1. Static Route Extension . . . . . . . . . . . . . . . . . 11 6.1. Directory Agent Extension . . . . . . . . . . . . . . . . 9
6.2. Service Scope Extension . . . . . . . . . . . . . . . . . 10
7. TCP Parameters 11 7. IP Layer Parameters per Interface 10
7.1. TCP Keepalive Interval Extension . . . . . . . . . . . . 11 7.1. Static Route Extension . . . . . . . . . . . . . . . . . 10
8. Vendor Specific Information 12 8. TCP Parameters 11
8.1. TCP Keepalive Interval Extension . . . . . . . . . . . . 11
9. DHCPv6 Extensions 13 9. Vendor Specific Information 11
9.1. Maximum DHCPv6 Message Size Extension . . . . . . . . . . 13
9.2. Class-identifier . . . . . . . . . . . . . . . . . . . . 13
9.3. Reconfigure Multicast Address . . . . . . . . . . . . . . 14
9.4. Renumber DHCPv6 Server Address . . . . . . . . . . . . . 14
9.5. Client-Server Authentication Extension . . . . . . . . . 14
10. Security Considerations 15 10. DHCPv6 Extensions 12
10.1. Replay Protection . . . . . . . . . . . . . . . . . . . . 15 10.1. Maximum DHCPv6 Message Size Extension . . . . . . . . . . 12
10.2. Default Authentication Algorithm . . . . . . . . . . . . 15 10.2. Class Identifier . . . . . . . . . . . . . . . . . . . . 13
10.3. Reconfigure Multicast Address . . . . . . . . . . . . . . 13
10.4. Renumber DHCPv6 Server Address . . . . . . . . . . . . . 14
10.5. Client-Server Authentication Extension . . . . . . . . . 14
11. New Extensions 16 11. Security Considerations 15
11.1. Replay Protection . . . . . . . . . . . . . . . . . . . . 15
11.2. Default Authentication Algorithm . . . . . . . . . . . . 15
12. Acknowledgements 16 12. New Extensions 16
13. Acknowledgements 16
Chair's Address 18 Chair's Address 18
Author's Address 18 Author's Address 18
1. Introduction 1. Introduction
This document specifies extensions for use with the Dynamic This document specifies extensions for use with the Dynamic
Host Configuration Protocol for IP version 6, DHVPv6. The full Host Configuration Protocol for IP version 6, DHVPv6. The full
description of DHCPv6 message formats may be found in the DHCPv6 description of DHCPv6 message formats may be found in the DHCPv6
specification document [4]. specification document [3].
This document defines the format of information in the last field This document defines the format of information in the last field
of DHCPv6 messages ('extensions'). The extensions defined within of DHCPv6 messages ('extensions'). The extensions defined within
this document specify a generalized use of this area for giving this document specify a generalized use of this area for giving
information useful to a wide class of machines, operating systems information useful to a wide class of machines, operating systems
and configurations. Sites with a single DHCPv6 server that is and configurations. Sites with a single DHCPv6 server that is
shared among heterogeneous clients may choose to define other, site- shared among heterogeneous clients may choose to define other, site-
specific formats for the use of the 'extensions' field. specific formats for the use of the 'extensions' field.
Section 2 of this memo describes the formats of DHCPv6 extensions. Section 2 of this memo describes the formats of DHCPv6 extensions.
Information on registering new extensions is contained in section 11. Information on registering new extensions is contained in section 12.
Although extension numbers in this document correspond closely to the Although extension numbers in this document correspond closely to the
analogous numbers in the options specification for IPv4 [1], there is analogous numbers in the options specification for IPv4 [1], there is
no requirement to keep numbering future extensions in any consistent no requirement to keep numbering future extensions in any consistent
manner except purely as a matter of editorial and cross-referencing manner except purely as a matter of editorial and cross-referencing
convenience. convenience.
Future applications will make extensive use of an ever-increasing Future applications will make extensive use of an ever-increasing
number and variety of network services. It is expected that client number and variety of network services. It is expected that client
needs for creating connections with these future network services needs for creating connections with these future network services
will be satisfied by the Service Location Protocol [12], and not will be satisfied by the Service Location Protocol [10], and not
DHCPv6. DHCP is expected to be used for the kinds of configuration DHCPv6. DHCP is expected to be used for the kinds of configuration
that enable clients to become fully functional as self-contained that enable clients to become fully functional as self-contained
network entities, but not the kinds of configuration that might be network entities, but not the kinds of configuration that might be
required by applications running above the network or transport layer required by applications running above the network or transport layer
protocol levels. protocol levels.
2. DHCPv6 Extension Field Format 2. DHCPv6 Extension Field Format
DHCPv6 extensions have the same format as the BOOTP "vendor DHCPv6 extensions have the same format as the BOOTP "vendor
extensions" defined in RFC 1497 [10]. Extensions may be fixed length extensions" defined in RFC 1497 [8]. Extensions may be fixed length
or variable length. All extensions begin with a tag octet, which or variable length. All extensions except for the pad extension
uniquely identifies the extension. Fixed-length extensions without begin with a type field which is two octets long, which uniquely
data consist of only a tag octet. Only extensions 0 and 255 are identifies the extension. Fixed-length extensions without data
fixed length. All other extensions are variable-length with a length consist of only the two octet type field. Only extensions 0 and
octet following the tag octet. The value of the length octet does 65535 are fixed length. All other extensions are variable-length
not include the two octets specifying the tag and length. The length with a two octet length field following the type octets. The value
octet is followed by "length" octets of data. In the case of some of the length octets does not include the two octets specifying the
variable-length extensions the length field is a constant but must type and length. The length octet is followed by "length" octets
still be specified. of data. In the case of some variable-length extensions the length
field is a constant but must still be specified.
Any extensions defined subsequent to this document should contain a Any extensions defined subsequent to this document should contain a
length octet even if the length is fixed or zero. Unknown options length field of two octets in length even if the length is fixed or
MAY be skipped by ignoring the number of bytes specified in the zero. Unknown options MAY be skipped by ignoring the number of bytes
length octet. All multi-octet quantities are in network byte-order. specified in the length octets. All multi-octet quantities are in
network byte-order.
Extension codes 128 to 254 (decimal) are reserved for site-specific Extension types 32768 to 65534 (decimal) are reserved for
extensions. site-specific extensions.
All of the extensions described in this document will also have their All of the extensions described in this document will also have their
default values specified, if any. default values specified, if any.
DISCUSSION: Should the DHCPv6 Extensions be put into a format
similar to IPv6 options?
3. Padding and End extension specifications 3. Padding and End extension specifications
3.1. Pad Extension 3.1. Pad Extension
The pad extension can be used to cause subsequent fields to align on The pad extension can be used to cause subsequent fields to align on
word boundaries. word boundaries.
The code for the pad extension is 0, and its length is 1 octet. The type code for the pad extension is 0, and its length is 1 octet.
Code Type
+-----+ +-----+
| 0 | | 0 |
+-----+ +-----+
3.2. End Extension 3.2. End Extension
The end extension marks the end of valid information in the vendor The end extension marks the end of valid information in the vendor
field. Subsequent octets should be filled with pad extensions. field. Subsequent octets should be filled with pad extensions.
The code for the end extension is 255, and its length is 1 octet. The type for the end extension is 65535, and its length is 2 octets.
Code Type
+-----+ +-----+-----+
| 255 | | 65535 |
+-----+ +-----+-----+
4. IPv6 Address Extension 4. IPv6 Address Extension
The IPv6 Address extension is the most essential of all the DHCPv6 The IPv6 Address extension is the most essential of all the DHCPv6
extensions. It is relatively complex and and can be used by both extensions. It is relatively complex and and can be used by both
client and server in various ways. Since the IPv6 Address option client and server in various ways. Since the IPv6 Address option
can be used more than once in the same DHCP message, all information can be used more than once in the same DHCP message, all information
relevant to a particular IPv6 allocation has to be collected together relevant to a particular IPv6 allocation has to be collected together
in the same extension, hence the added complexity. Some of this in the same extension, hence the added complexity. Some of this
added complexity also derives from various possible ways that added complexity also derives from various possible ways that
updating DNS may be specified within the IPv6 Address extension. updating DNS may be specified within the IPv6 Address extension.
An IPv6 Address Extension can contain at most one IPv6 address. To An IPv6 Address Extension can contain at most one IPv6 address. To
specify more than one IPv6 address, multiple extensions are used. specify more than one IPv6 address, multiple extensions are used.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ext-type | ext-length |C|L|Q|A|P| rsv | pfx-size | | ext-type | ext-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C|L|Q|A|P| reserved | pfx-size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (if present) | | (if present) |
| client address (16 octets) | | client address (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (if present) preferred lifetime (4 octets) | | (if present) preferred lifetime (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (if present) valid lifetime (4 octets) | | (if present) valid lifetime (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (if present) DNS name (variable length) ... | (if present) DNS name (variable length) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 4, line 27 skipping to change at page 4, line 27
The IPv6 address to be allocated by the server for use by The IPv6 address to be allocated by the server for use by
the client (16 octets long). the client (16 octets long).
preferred lifetime preferred lifetime
The preferred lifetime of the IPv6 address in seconds The preferred lifetime of the IPv6 address in seconds
valid lifetime valid lifetime
The valid lifetime of the IPv6 address in seconds The valid lifetime of the IPv6 address in seconds
DNS name DNS name
The DNS name (a zero-terminated character string) to be The DNS name (a zero-terminated string of ASCII octets)
used by the client (variable length). to be used by the client (variable length).
The DNS name can be a host name, which does not contain the '.' The DNS name can be a host name, which does not contain the '.'
character as a separator between DNS hierarchy components. Any name ASCII character as a separator between DNS hierarchy components. Any
containing the '.' is treated as a Fully Qualified Domain Name name containing the '.' is treated as a Fully Qualified Domain Name
(FQDN). The length of the DNS name may be determined by subtracting, (FQDN). The length of the DNS name may be determined by subtracting,
from the ext-length, the length of those fixed-length fields which from the ext-length, the length of those fixed-length fields which
are present. If the last byte of the DNS name is not zero, the IPv6 are present. If the last byte of the DNS name is not zero, the IPv6
Address Extension MUST be rejected. Address Extension MUST be rejected.
4.1. Client Considerations for the IPv6 Address extension 4.1. Client Considerations for the IPv6 Address extension
4.1.1. Address Lifetimes 4.1.1. Address Lifetimes
An IPv6 address returned to a client has a preferred and valid An IPv6 address returned to a client has a preferred and valid
skipping to change at page 5, line 10 skipping to change at page 5, line 10
a new address or the same address before the lease actually expires. a new address or the same address before the lease actually expires.
If the client does not make a new Request for an address, the server If the client does not make a new Request for an address, the server
MUST assume the client does not want that address. The server MAY MUST assume the client does not want that address. The server MAY
provide that address to another client requesting an address. provide that address to another client requesting an address.
The client MAY request a value for the lifetimes returned by a The client MAY request a value for the lifetimes returned by a
server, but the client MUST use the lifetimes provided by the server server, but the client MUST use the lifetimes provided by the server
response. response.
When the preferred lifetime of an IPv6 address expires, the client's When the preferred lifetime of an IPv6 address expires, the client's
address becomes a deprecated address. See [5] for required handling address becomes a deprecated address. See [4] for required handling
of deprecated IPv6 addresses. When an address for a DHCPv6 client's of deprecated IPv6 addresses. When an address for a DHCPv6 client's
interface becomes deprecated, the processing of the lifetime SHOULD interface becomes deprecated, the processing of the lifetime SHOULD
request a new address for that interface, or make a new DHCP Request request a new address for that interface, or make a new DHCP Request
for the existing address (which can result in the address receiving for the existing address (which can result in the address receiving
an updated preferred lifetime). an updated preferred lifetime).
When the client requests an IPv6 address from the DHCPv6 server, the When the client requests an IPv6 address from the DHCPv6 server, the
client MUST keep track of when the request was issued. When the client MUST keep track of when the request was issued. When the
client receives a successful reply from the DHCPv6 server, it MUST client receives a successful reply from the DHCPv6 server, it MUST
decrement the received Lifetimes by the amount of time between the decrement the received Lifetimes by the amount of time between the
skipping to change at page 6, line 14 skipping to change at page 6, line 14
When a client requests an IP address, it MUST maintain a record for When a client requests an IP address, it MUST maintain a record for
the server which allocates that address, so that the client can (if the server which allocates that address, so that the client can (if
necessary) in the future necessary) in the future
- Renew the lifetime with the same server, or - Renew the lifetime with the same server, or
- Release the address, using DHCP Release. - Release the address, using DHCP Release.
Upon reception of a new IP address, the client must perform Duplicate Upon reception of a new IP address, the client must perform Duplicate
Address Detection (DAD) [9]; however, if the address has already been Address Detection (DAD) [7]; however, if the address has already been
allocated to the client and it is merely renewing the lifetime of the allocated to the client and it is merely renewing the lifetime of the
address, the client does not have to perform DAD each time. address, the client does not have to perform DAD each time.
4.1.3. Use with the DHCP Release message 4.1.3. Use with the DHCP Release message
In DHCP Release (for each address extension): In DHCP Release (for each address extension):
- Client can include an IPv6 address and/or name and/or FQDN. - Client can include an IPv6 address and/or name and/or FQDN.
- Server MUST update DNS to delete the AAAA record if the server - Server MUST update DNS to delete the AAAA record if the server
skipping to change at page 8, line 16 skipping to change at page 8, line 16
The following extensions are important for many DHCPv6 clients, and The following extensions are important for many DHCPv6 clients, and
are not specific to any upper-level protocol. are not specific to any upper-level protocol.
5.1. Time Offset 5.1. Time Offset
The time offset field specifies the offset of the client's subnet The time offset field specifies the offset of the client's subnet
in seconds from Coordinated Universal Time (UTC). The offset is in seconds from Coordinated Universal Time (UTC). The offset is
expressed as a signed 32-bit integer. expressed as a signed 32-bit integer.
The code for the time offset extension is 2, and its length is 4 The type for the time offset extension is 2, and its length is 4
octets. octets.
Code Len Time Offset Type Length Time Offset
+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
| 2 | 4 | n1 | n2 | n3 | n4 | | 8 | 4 | n1 | n2 | n3 | n4 |
+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
5.2. Domain Name Server Extension 5.2. Domain Name Server Extension
The domain name server extension specifies a list of Domain Name The domain name server extension specifies a list of Domain Name
System (STD 13, RFC 1035 [8]) name servers available to the client. System (STD 13, RFC 1035 [6]) name servers available to the client.
Servers SHOULD be listed in order of preference. Servers SHOULD be listed in order of preference.
The code for the domain name server extension is 6. The minimum The type for the domain name server extension is 6. The minimum
length for this extension is 16 octets, and the length MUST always be length for this extension is 16 octets, and the length MUST always be
a multiple of 16. a multiple of 16.
Code Len Address 1 Address 2 Type Length Address 1 Address 2
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+---- +-----+-----+-----+-----+-----+-----+---+-----+-----+-----+---+-----+---
| 6 | n | a1 | a2 | ... | a16 | a1 | a2 | ... | a16 | ... | 9 | n | a1 | a2 |...| a16 | a1 | a2 |...| a16 |...
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+---- +-----+-----+-----+-----+-----+-----+---+-----+-----+-----+---+-----+---
5.3. Directory Agent Extension 5.3. Domain Name
This extension specifies a Directory Agent (DA) [12], along with zero This extension specifies the domain name that client should use when
or more Naming Authorities [6] known to that DA and zero or more resolving hostnames via the Domain Name System.
scopes supported by that DA.
The code for this extension is 11. Each Naming Authority and each The type for this extension is 10. Its minimum length is 1.
scope MUST be a null-terminated string of ASCII characters. The
lengths of the strings are only indicated implicitly by their null Type Length Domain Name
+-----+-----+-----+-----+-----+-----+-----+-----+--
| 10 | n | d1 | d2 | d3 | d4 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+--
The domain name is a null-terminated ASCII string, of length 'n'
octets including the terminating null octet.
If the Domain Name extension is not specified, and the IPv6 Address
extension received by a client contains a FQDN, then the client may
take the part of the FQDN after the first '.' octet as the Domain
Name.
6. Service Location Extensions
6.1. Directory Agent Extension
This extension specifies a Directory Agent (DA) [10], along with zero
or more scopes supported by that DA.
The type for this extension is 16. Each scope MUST be a
null-terminated string of ASCII octets. The lengths of the strings
(measured in octets) are only indicated implicitly by their null
termination and the overall length of the extension. termination and the overall length of the extension.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Length |D| NA count | scope count | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| scope count |D|M| reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (if present) | | (if present) |
| Directory Agent address (16 octets) | | Directory Agent address (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NA list ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| scope list ... | scope list ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code 11 Type 16
Length variable Length variable
D If the 'D' bit is set, the Directory Agent address is D If the 'D' bit is set, the Directory Agent address is
present. present.
NA count M If the 'M' bit is set, the Directory Agent address is
The number of Naming Authorities indicated by strings in the only one that may be used, and multicast methods for
the NA list following. discovering Directory Agents MUST NOT be used.
scope count scope count
The number of scopes indicated by strings in the NA list The number of scopes indicated by strings in the scope
following. list following.
NA list
A list of strings denoting Naming Authorities.
scope list scope list
A list of strings denoting scopes. A list of strings denoting scopes.
Note that more than one Directory Agent extension may be present in Note that more than one Directory Agent extension may be present in
a DHCP message. Each such extension may have the same or different a DHCP message. Each such extension may have the same or different
lists of Naming Authorities and scopes. The client may request a lists of scopes. The client may request a Directory Agent with a
Directory Agent with a particular scope, and/or knowledgeable about particular scope, by including the Directory Agent extension in a
schemes defined by a particular Naming Authority, by including the DHCP Request message with no Directory Agent address included (the
Directory Agent extension in a DHCP Request message with no Directory 'D' bit set to zero), and the appropriate strings in the scope list.
Agent address included (the 'D' bit set to zero), and the appropriate
strings in the NA list and/or scope list.
5.4. Service Scope Extension 6.2. Service Scope Extension
This extension indicates a scope that should be used by a Service This extension indicates a scope that should be used by a Service
Agent (SA) [12], when responding to Service Request messages as Agent (SA) [10], when responding to Service Request messages as
specified by the Service Location Protocol. specified by the Service Location Protocol.
Code Len Type Length
+-----+-----+-----+-----
| 12 | n | Scope ...
+-----+-----+-----+-----
Scope is a null-terminated ASCII string, of length 'n' including the
terminating null character.
5.5. Naming Authority Extension
This extension indicates a naming authority (which specifies the
syntax for schemes that may be used in URLs [3]) for use by entities
with the Service Location Protocol.
Code Len
+-----+-----+-----+-----+-----+----- +-----+-----+-----+-----+-----+-----
| 13 | n | Naming Authority ... | 17 | n | Scope ...
+-----+-----+-----+-----+-----+----- +-----+-----+-----+-----+-----+-----
Naming Authority is a null-terminated ASCII string, of length 'n' Scope is a null-terminated ASCII string, of length 'n' octets
including the terminating null character. including the terminating null octet.
5.6. Domain Name
This extension specifies the domain name that client should use when
resolving hostnames via the Domain Name System.
The code for this extension is 15. Its minimum length is 1.
Code Len Domain Name
+-----+-----+-----+-----+-----+-----+--
| 15 | n | d1 | d2 | d3 | d4 | ...
+-----+-----+-----+-----+-----+-----+--
If the Domain Name extension is not specified, and the IPv6 Address
extension received by a client contains a FQDN, then the client may
take the part of the FQDN after the first '.' character as the
Domain Name.
6. IP Layer Parameters per Interface 7. IP Layer Parameters per Interface
This section details the extensions that affect the operation of the This section details the extensions that affect the operation of the
IP layer on a per-interface basis. It is expected that a client can IP layer on a per-interface basis. It is expected that a client can
issue multiple requests, one per interface, in order to configure issue multiple requests, one per interface, in order to configure
interfaces with their specific parameters. interfaces with their specific parameters.
6.1. Static Route Extension 7.1. Static Route Extension
This extension specifies a list of static routes that the client This extension specifies a list of static routes that the client
should install in its routing cache. If multiple routes to the same should install in its routing cache. If multiple routes to the same
destination are specified, they are listed in the order in which the destination are specified, they are listed in the order in which the
client should make use of them. client should make use of them.
The routes consist of a list of IP address pairs. The first address The routes consist of a list of IP address pairs. The first address
is the destination address, and the second address is the router for is the destination address, and the second address is the router for
the destination. the destination.
Link-local addresses are illegal destinations for a static route. Link-local addresses are illegal destinations for a static route.
The code for this extension is 33. The minimum length of this The type for this extension is 24. The minimum length of this
extension is 32, and the length MUST be a multiple of 16. extension is 24, and the length MUST be a multiple of 16.
Code Len Destination 1 Router 1 Type Length Destination 1 Router 1
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| 33 | n | d1 | d2 | ... | d16 | r1 | r2 | ... | r16 | | 24 | n | d1 | d2 | ... | d16 | r1 | r2 | ... | r16 |
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
Destination 2 Router 2 Destination 2 Router 2
+-----+-----+-----+-----+-----+-----+-----+-----+--- +-----+-----+-----+-----+-----+-----+-----+-----+---
| d1 | d2 | ... | d16 | r1 | r2 | ... | r16 | ... | d1 | d2 | ... | d16 | r1 | r2 | ... | r16 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+--- +-----+-----+-----+-----+-----+-----+-----+-----+---
7. TCP Parameters 8. TCP Parameters
This section lists the extensions that affect the operation of the This section lists the extensions that affect the operation of the
TCP layer on a per-interface basis. TCP layer on a per-interface basis.
7.1. TCP Keepalive Interval Extension 8.1. TCP Keepalive Interval Extension
This extension specifies the interval (in seconds) that the This extension specifies the interval (in seconds) that the
client TCP should wait before sending a keepalive message on a TCP client TCP should wait before sending a keepalive message on a TCP
connection. The time is specified as a 32-bit unsigned integer. connection. The time is specified as a 32-bit unsigned integer.
A value of zero indicates that the client should not generate A value of zero indicates that the client should not generate
keepalive messages on connections unless specifically requested by an keepalive messages on connections unless specifically requested by an
application. application.
The code for this extension is 38, and its length is 4. The type for this extension is 32, and its length is 4.
Code Len Time Type Length Time
+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
| 38 | 4 | t1 | t2 | t3 | t4 | | 32 | 4 | t1 | t2 | t3 | t4 |
+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
8. Vendor Specific Information 9. Vendor Specific Information
This extension is used by clients and servers to exchange vendor- This extension is used by clients and servers to exchange vendor-
specific information. The information is an opaque object of n specific information. The information is an opaque object of n
octets, presumably interpreted by vendor-specific code on the clients octets, presumably interpreted by vendor-specific code on the clients
and servers. The definition of this information is vendor specific. and servers. The definition of this information is vendor specific.
The vendor is indicated in the class-identifier extension. Servers The vendor is indicated in the class-identifier extension. Servers
not equipped to interpret the vendor-specific information sent by a not equipped to interpret the vendor-specific information sent by a
client MUST ignore it (although it may be reported). Clients which client MUST ignore it (although it may be reported). Clients which
do not receive desired vendor-specific information SHOULD make an do not receive desired vendor-specific information SHOULD make an
attempt to operate without it, although they may do so (and announce attempt to operate without it, although they may do so (and announce
they are doing so) in a degraded mode. they are doing so) in a degraded mode.
If a vendor potentially encodes more than one item of information in If a vendor potentially encodes more than one item of information in
this extension, then the vendor SHOULD encode the extension using this extension, then the vendor SHOULD encode the extension using
"Encapsulated vendor-specific extensions" as described below: "Encapsulated vendor-specific extensions" as described below:
The Encapsulated vendor-specific extensions field SHOULD be encoded The Encapsulated vendor-specific extensions field SHOULD be encoded
as a sequence of type/length/value fields of identical syntax to the as a sequence of type/length/value fields of identical syntax to the
DHCPv6 extensions field with the following exceptions: DHCPv6 extensions field with the following exceptions:
- Codes other than 0 or 255 MAY be redefined by the vendor - Types other than 0 or 255 MAY be redefined by the vendor
within the encapsulated vendor-specific extensions field, within the encapsulated vendor-specific extensions field, but
but SHOULD conform to the tag-length-value syntax defined in SHOULD conform to the type-length-value syntax defined in
section 2. section 2.
- Code 255 (END), if present, signifies the end of the - Code 255 (END), if present, signifies the end of the
encapsulated vendor extensions, not the end of the vendor encapsulated vendor extensions, not the end of the vendor
extensions field. If no code 255 is present, then the end of extensions field. If no code 255 is present, then the end of
the enclosing vendor-specific information field is taken as the enclosing vendor-specific information field is taken as
the end of the encapsulated vendor-specific extensions field. the end of the encapsulated vendor-specific extensions field.
The code for this extension is 43 and its minimum length is 1. The type for this extension is 40 and its minimum length is 1.
Type Length Vendor-specific information
+-----+-----+-----+-----+-----+-----+---
| 40 | n | i1 | i2 | ...
+-----+-----+-----+-----+-----+-----+---
Code Len Vendor-specific information
+-----+-----+-----+-----+---
| 43 | n | i1 | i2 | ...
+-----+-----+-----+-----+---
When encapsulated vendor-specific extensions are used, the When encapsulated vendor-specific extensions are used, the
information bytes 1-n have the following format: information bytes 1-n have the following format:
Code Len Data item Code Len Data item Code Type Len Data item Type Len Data item Type
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| T1 | n | d1 | d2 | ... | T2 | n | D1 | D2 | ... | ... | | T1 | n | d1 | d2 | ... | T2 | n | D1 | D2 | ... | ... |
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
9. DHCPv6 Extensions 10. DHCPv6 Extensions
This section details the extensions that are specific to DHCPv6. This section details the extensions that are specific to DHCPv6.
9.1. Maximum DHCPv6 Message Size Extension 10.1. Maximum DHCPv6 Message Size Extension
This extension specifies the maximum length in octets of any DHCPv6 This extension specifies the maximum size in octets of any DHCPv6
message that the sender of the extension is willing to accept. The message that the sender of the extension is willing to accept. The
length is specified as an unsigned 16-bit integer. A client may use size is specified as an unsigned 16-bit integer. A client may use
the maximum DHCPv6 message size extension in DHCP Request messages, the maximum DHCPv6 message size extension in DHCP Request messages,
but SHOULD NOT use the extension in DHCP Solicit messages(see [4]), but SHOULD NOT use the extension in DHCP Solicit messages(see [3]),
and MUST NOT use the extension in other DHCP messages. and MUST NOT use the extension in other DHCP messages.
The code for this extension is 57, and its length is 2. The minimum The type for this extension is 64, and its length is 2. The minimum
legal value is 1500. legal value is 1500.
Code Len Length Type Length Size
+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+
| 57 | 2 | l1 | l2 | | 64 | 2 | l1 | l2 |
+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+
9.2. Class-identifier 10.2. Class Identifier
This extension may be used by DHCPv6 clients to identify their This extension is used by a DHCP client to optionally identify the
type and configuration. The information is a string of n octets, type or category of user or applications it represents. The class
interpreted by servers. Vendors and sites may choose to define identifier is a null-terminated NVT ASCII string, of length 'n'
specific class identifiers to convey particular configuration or octets including the terminating null octet, that represents the user
other identification information about a client. For example, the class of which the client is a member.
identifier may encode the client's hardware configuration. Servers
not equipped to interpret the class-specific information sent by
a client MUST ignore it (although it may be reported for system
management purposes).
The code for this extension is 60, and its minimum length is 1. DHCP administrators may define specific user class identifiers to
convey information about a client's software configuration or about
its user's preferences. For example, an identifier may specify
that a particular DHCP client is a member of the class "accounting
auditors", which have special service needs such as a particular
database server. Alternatively, the identifier may encode the
client's hardware configuration.
Code Len Class-Identifier Servers not equipped to interpret the user class specified by a
+-----+-----+-----+-----+--- client MUST ignore it (although it may be reported). Otherwise,
| 60 | n | i1 | i2 | ... servers SHOULD respond with the set of extensions corresponding to
+-----+-----+-----+-----+--- the user class specified by the client. Further, if the server
responds with the set of extensions corresponding to the given user
class, it MUST return this extension (with the given user class
value) to the client.
9.3. Reconfigure Multicast Address The type for this extension is 65, and its minimum length is 1.
Type Length Class-Identifier
+-----+-----+-----+-----+-----+-----+---
| 65 | n | i1 | i2 | ...
+-----+-----+-----+-----+-----+-----+---
10.3. Reconfigure Multicast Address
A DHCPv6 server can instruct its clients to join a multicast group A DHCPv6 server can instruct its clients to join a multicast group
for the purposes of receiving DHCPv6 Reconfigure messages. This will for the purposes of receiving DHCPv6 Reconfigure messages. This will
allow a server to reconfigure all of its clients at once; such a allow a server to reconfigure all of its clients at once; such a
feature will be useful when renumbering becomes necessary. feature will be useful when renumbering becomes necessary.
Code Len IPv6 Multicast Address Type Length IPv6 Multicast Address
+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
| 70 | 16 | a1 | a2 | ... | a16 | | 66 | 16 | a1 | a2 | ... | a16 |
+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
9.4. Renumber DHCPv6 Server Address 10.4. Renumber DHCPv6 Server Address
A DHCPv6 server can instruct its clients to change their internal A DHCPv6 server can instruct its clients to change their internal
records to reflect the server's newly renumbered IPv6 address, by records to reflect the server's newly renumbered IPv6 address, by
using the "Renumber DHCPv6 Server Address" extension. This extension using the "Renumber DHCPv6 Server Address" extension. This extension
may be sent with the DHCP Reconfigure message, and thus can be may be sent with the DHCP Reconfigure message, and thus can be
multicast to all of the server's clients instead of being unicast to multicast to all of the server's clients instead of being unicast to
each one individually. each one individually.
Code Len New IPv6 Server Address Type Length New IPv6 Server Address
+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+
| 71 | 16 | a1 | a2 | ... | a16 | | 67 | 16 | a1 | a2 | ... | a16 |
+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+
9.5. Client-Server Authentication Extension 10.5. Client-Server Authentication Extension
Exactly one Client-Server Authentication Extension MAY be present Exactly one Client-Server Authentication Extension MAY be present
in any DHCPv6 message transmitted between a client and server in any DHCPv6 message transmitted between a client and server
(or vice-versa). If present, it MUST be placed after every other (or vice-versa). If present, it MUST be placed after every other
extension. extension.
Code Len Security Parameter ndx replay protect Type Length Security Parameter ndx replay protect
+-----+------+-----+-----+-----+-----+-----+-----+-----+-----+--- +-----+------+-----+-----+-----+-----+-----+-----+-----+---+-----+---+-
| 84 | 12+x | sp1 | sp2 | sp3 | sp4 | rp1 | ... | rp8 | Auth ... | 80 | 12+x | sp1 | sp2 | sp3 | sp4 | rp1 |...| rp8 |Auth
+-----+------+-----+-----+-----+-----+-----+-----+-----+-----+--- +-----+------+-----+-----+-----+-----+-----+-----+-----+---+-----+---+-
Type 84 Type 84
Length 4 for the SPI, plus 8 for the replay protection, plus the Length 4 for the SPI, plus 8 for the replay protection, plus the
number of bytes in the Authenticator. number of bytes in the Authenticator.
SPI A Security Parameters index [2] identifying a security SPI A Security Parameters index [2] identifying a security
context between a pair of nodes among the contexts context between a pair of nodes among the contexts
available in the security association defined between available in the security association defined between
the DHCPv6 client and server. SPI values 0 through 255 the DHCPv6 client and server. SPI values 0 through 255
are reserved and MUST NOT be used in any Client-Server are reserved and MUST NOT be used in any Client-Server
Authentication Extension. Authentication Extension.
Replay Protection Replay Protection
A 64-bit timestamp (in Network Time Protocol [7](NTP) A 64-bit timestamp (in Network Time Protocol [5](NTP)
format) (see section 10.1). format) (see section 11.1).
Authenticator Authenticator
(variable length) (See Section 10.2.) (variable length) (See Section 11.2.)
This authentication extension remedies the inability of IPsec to This authentication extension remedies the inability of IPsec to
provide for non end-to-end authentication, since authentication is provide for non end-to-end authentication, since authentication is
needed even when the client needs has no valid IPv6 address. The needed even when the client needs has no valid IPv6 address. The
extension can be originated by either the DHCPv6 Client or DHCPv6 extension can be originated by either the DHCPv6 Client or DHCPv6
server to authenticate the rest of the data in the DHCPv6 message. server to authenticate the rest of the data in the DHCPv6 message.
10. Security Considerations 11. Security Considerations
There is an urgent need to define some security protocol for use There is an urgent need to define some security protocol for use
with DHCPv6, since otherwise malicious parties could create numerous with DHCPv6, since otherwise malicious parties could create numerous
denial-of-service style attacks based on depleting available server denial-of-service style attacks based on depleting available server
resources or providing corrupted or infected data to unsuspecting resources or providing corrupted or infected data to unsuspecting
clients. The following sections discuss aspects of security relevant clients. The following sections discuss aspects of security relevant
for users of the Client-Server Authentication extension 9.5. for users of the Client-Server Authentication extension 10.5.
10.1. Replay Protection 11.1. Replay Protection
A 64-bit timestamp, in Network Time Protocol [7](NTP) format, is A 64-bit timestamp, in Network Time Protocol [5](NTP) format, is
used to protect against replay of previous authenticated messages used to protect against replay of previous authenticated messages
by malicious agents. The NTP timestamp value used in the extension by malicious agents. The NTP timestamp value used in the extension
MUST be chosen, and verified, to be larger than values used by the MUST be chosen, and verified, to be larger than values used by the
originator in previous Client-Server Authentication extensions. originator in previous Client-Server Authentication extensions.
On the other hand, the timestamp value MUST also be chosen (and On the other hand, the timestamp value MUST also be chosen (and
verified) to be no greater than one year more than the last known verified) to be no greater than one year more than the last known
value (if any) used by the originator. value (if any) used by the originator.
10.2. Default Authentication Algorithm 11.2. Default Authentication Algorithm
The default authentication algorithm uses keyed-MD5 [11] in The default authentication algorithm uses keyed-MD5 [9] in
"prefix+suffix" mode to compute a 128-bit "message digest" of the "prefix+suffix" mode to compute a 128-bit "message digest" of the
registration message. The default authenticator is a 128-bit value registration message. The default authenticator is a 128-bit value
computed as the MD5 checksum over the the following stream of bytes: computed as the MD5 checksum over the the following stream of bytes:
- the shared secret defined by the security association between - the shared secret defined by the security association between
the client and server and by the SPI value specified in the the client and server and by the SPI value specified in the
Authentication Extension, followed by Authentication Extension, followed by
- all previous fields in the DHCPv6 message and extensions, - all previous fields in the DHCPv6 message and extensions,
followed by followed by
- the shared secret again. - the shared secret again.
11. New Extensions 12. New Extensions
Additional generic data fields may be registered by contacting: Additional generic data fields may be registered by contacting:
Internet Assigned Numbers Authority (IANA) Internet Assigned Numbers Authority (IANA)
USC/Information Sciences Institute USC/Information Sciences Institute
4676 Admiralty Way 4676 Admiralty Way
Marina del Rey, California 90292-6695 Marina del Rey, California 90292-6695
or by email as: iana@isi.edu or by email as: iana@isi.edu
Implementation specific use of undefined generic types (including Implementation specific use of undefined generic types (including
those in the range 72-127) may conflict with other implementations, those in the range 72-127) may conflict with other implementations,
and registration is required. and registration is required.
DISCUSSION: Need to read Ralph's new draft and incorporate DISCUSSION: Need to read Ralph's new draft and incorporate
those ideas here. those ideas here.
12. Acknowledgements 13. Acknowledgements
Thanks to Jim Bound for his frequent review, helpful suggestions, Thanks to Jim Bound for his frequent review, helpful suggestions,
and design assistance. The original form of this internet draft was and design assistance. The original form of this internet draft was
copied directly from RFC1533 [1], written by Steve Alexander and copied directly from RFC1533 [1], written by Steve Alexander and
Ralph Droms, to whom thanks are again due. Ralph Droms, to whom thanks are again due.
References References
[1] S. Alexander and R. Droms. DHCP Options and BOOTP Vendor [1] S. Alexander and R. Droms. DHCP Options and BOOTP Vendor
Extensions. RFC 1533, October 1993. Extensions. RFC 1533, October 1993.
[2] R. Atkinson. IP Authentication Header. RFC 1826, August 1995. [2] R. Atkinson. IP Authentication Header. RFC 1826, August 1995.
[3] T. Berners-Lee, L. Masinter, and M. McCahill. Uniform Resource [3] J. Bound and C. Perkins. Dynamic Host Configuration Protocol
Locators (URL). RFC 1738, December 1994.
[4] J. Bound and C. Perkins. Dynamic Host Configuration Protocol
for IPv6. draft-ietf-dhc-dhcpv6-05.txt -- work in progress, for IPv6. draft-ietf-dhc-dhcpv6-05.txt -- work in progress,
June 1996. June 1996.
[5] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6) [4] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6)
Specification. RFC 1883, December 1995. Specification. RFC 1883, December 1995.
[6] Paul E. Hoffman and Ron Daniel, Jr. Generic URN Syntax. [5] David L. Mills. Network Time Protocol (Version 3):
draft-ietf-uri-urn-syntax-00.txt -- work in progress, April
1995.
[7] David L. Mills. Network Time Protocol (Version 3):
Specification, Implementation and Analysis. RFC 1305, March Specification, Implementation and Analysis. RFC 1305, March
1992. 1992.
[8] P. Mockapetris. DOMAIN NAMES - IMPLEMENTATION AND [6] P. Mockapetris. DOMAIN NAMES - IMPLEMENTATION AND
SPECIFICATION. RFC 1035, November 1987. SPECIFICATION. RFC 1035, November 1987.
[9] T. Narten, E. Nordmark, and W. Simpson. Neighbor Discovery for [7] T. Narten, E. Nordmark, and W. Simpson. Neighbor Discovery for
IP Version 6 (IPv6). draft-ietf-ipngwg-discovery-06.txt -- work IP Version 6 (IPv6). draft-ietf-ipngwg-discovery-06.txt -- work
in progress, March 1996. in progress, March 1996.
[10] J. Reynolds. BOOTP Vendor Information Extensions. RFC 1497, [8] J. Reynolds. BOOTP Vendor Information Extensions. RFC 1497,
August 1993. August 1993.
[11] Ronald L. Rivest. The MD5 Message-Digest Algorithm. RFC 1321, [9] Ronald L. Rivest. The MD5 Message-Digest Algorithm. RFC 1321,
April 1992. April 1992.
[12] J. Veizades, E. Guttman, C. Perkins, and S. Kaplan. Service [10] J. Veizades, E. Guttman, C. Perkins, and S. Kaplan. Service
Location Protocol. draft-ietf-svrloc-protocol-14.txt - work in Location Protocol. draft-ietf-svrloc-protocol-14.txt - work in
progress, June 1996. progress, June 1996.
Chair's Addresses Chair's Addresses
The working group can be contacted via the current chair: The working group can be contacted via the current chair:
Ralph Droms Ralph Droms
Computer Science Department Computer Science Department
323 Dana Engineering 323 Dana Engineering
 End of changes. 

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