draft-ietf-dhc-dhcpv6-opt-netboot-00.txt   draft-ietf-dhc-dhcpv6-opt-netboot-01.txt 
DHC T. Huth DHC T. Huth
Internet-Draft J. Freimann Internet-Draft J. Freimann
Intended status: Standards Track IBM Deutschland Research & Intended status: Standards Track IBM Deutschland Research &
Expires: February 20, 2009 Development GmbH Expires: April 17, 2009 Development GmbH
August 19, 2008 October 14, 2008
DHCPv6 option for network boot DHCPv6 option for network boot
draft-ietf-dhc-dhcpv6-opt-netboot-00 draft-ietf-dhc-dhcpv6-opt-netboot-01
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
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
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 February 20, 2009. This Internet-Draft will expire on April 17, 2009.
Abstract Abstract
The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) provides a The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) provides a
framework for passing configuration information to nodes on a framework for passing configuration information to nodes on a
network. This document describes a new option for DHCPv6 to convey network. This document describes a new option for DHCPv6 to convey
information, required for network booting, to the nodes. information, required for network booting, to the nodes.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Netboot option format . . . . . . . . . . . . . . . . . . . . . 3 3. Netboot option format . . . . . . . . . . . . . . . . . . . . 3
4. Suboption: boot file Uniform Resource Locator (URL) . . . . . . 4 4. Suboption: Boot file Uniform Resource Locator (URL) . . . . . 4
5. Appearance of these options . . . . . . . . . . . . . . . . . . 6 5. Suboption: Vendor class extension . . . . . . . . . . . . . . 6
6. Boot protocol considerations . . . . . . . . . . . . . . . . . 6 6. Appearance of these options . . . . . . . . . . . . . . . . . 7
7. IANA considerations . . . . . . . . . . . . . . . . . . . . . . 6 7. Boot protocol considerations . . . . . . . . . . . . . . . . . 7
8. Security considerations . . . . . . . . . . . . . . . . . . . . 7 8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 7
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 9. Security considerations . . . . . . . . . . . . . . . . . . . 8
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
10.1. Normative References . . . . . . . . . . . . . . . . . . . 7 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.2. Informative References . . . . . . . . . . . . . . . . . . 8 11.1. Normative References . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 11.2. Informative References . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . . . 11
1. Introduction 1. Introduction
Network booting means that a node which should be booted fetches the Network booting means that a node which should be booted fetches the
files required for booting via its network device from a server. files required for booting via its network device from a server.
Network booting is, for example, very useful in environments where Network booting is, for example, very useful in environments where
the administrators have to maintain a large number of nodes. Since the administrators have to maintain a large number of nodes. Since
all boot and configuration files are stored on a central server, the all boot and configuration files are stored on a central server, the
maintenance of all nodes can be kept simple this way. maintenance of all nodes can be kept simple this way.
skipping to change at page 4, line 10 skipping to change at page 4, line 10
The netboot option is used as an encapsulation for suboptions which The netboot option is used as an encapsulation for suboptions which
carry the actual information needed to boot a client. This option carry the actual information needed to boot a client. This option
will be used by clients to request boot information from a server. will be used by clients to request boot information from a server.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPT_NET_BOOT | option-len | | OPT_NET_BOOT | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| suboption-code 1 | subopt-len | | suboption-code 1 | suboption-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| subopt-data 1 (variable length) | | subopt-data 1 (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. <multiple suboptions> . . <multiple suboptions> .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| suboption-code n | subopt-len | | suboption-code n | suboption-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| subopt-data n (variable length) | | subopt-data n (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPT_NET_BOOT (tbd). option-code OPT_NET_BOOT (tbd).
option-len Length of the netboot option in octets. option-len Length of the netboot option in octets (not including
the size of the option-code and option-len fields).
Multiple occurences of each suboption-type can occur within a netboot Multiple occurences of each suboption-type can occur within a netboot
option (for example when more than one boot server is available). option (for example when more than one boot server is available).
Clients MUST process the suboptions in the order in which they appear Clients MUST process the suboptions in the order in which they appear
in the message sent by the server. in the message sent by the server.
So far, only one suboption has been defined, SUBOPT_BOOTFILE_URL, So far, only the suboptions in the following chapters have been
which is described in Section 4. Other suboptions might be defined defined. Other suboptions might be defined in future RFCs.
in future RFCs.
4. Suboption: boot file Uniform Resource Locator (URL) 4. Suboption: Boot file Uniform Resource Locator (URL)
This suboption consists of multiple null-terminated strings. It is This suboption consists of multiple null-terminated strings. It is
used to convey an URL to a boot file together with additional used to convey an URL to a boot file together with additional
parameters for the boot file (e.g. parameters for the kernel or boot parameters for the boot file (e.g. parameters for the kernel or boot
loader program). loader program).
Since multiple occurrences of SUBOPT_BOOTFILE_URL can be present in a Since multiple occurrences of SUBOPT_BOOTFILE_URL can be present in a
single OPT_NETBOOT message, clients MUST process them in the order in single OPT_NETBOOT message, clients MUST process them in the order in
which they appear within the message. For example in the case of a which they appear within the message. For example in the case of a
boot file URL the first file should be downloaded and executed. In boot file URL the first file should be downloaded and executed. In
case of a failure the process should continue with the second one and case of a failure the process should continue with the second one and
so on. so on.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SUBOPT_BOOTFILE_URL | subopt-len | | SUBOPT_BOOTFILE_URL | suboption-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| bootfile-url | | bootfile-url |
. (variable) . . (variable) .
| | '\0' | | | '\0' |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| parameter 1 | | parameter 1 |
. (variable) . . (variable) .
| | '\0' | | | '\0' |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
skipping to change at page 5, line 31 skipping to change at page 5, line 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| parameter n | | parameter n |
. (variable) . . (variable) .
| | '\0' | | | '\0' |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Format description: Format description:
suboption-code SUBOPT_BOOTFILE_URL (tbd). suboption-code SUBOPT_BOOTFILE_URL (tbd).
suboption-len Length of the bootfile suboption in octets. suboption-len Length of the bootfile suboption in octets (not
including the size of the suboption-code and
suboption-len fields).
bootfile-url This NULL-terminated ASCII string is the URL bootfile-url This NULL-terminated ASCII string is the URL
(conforming to [RFC2396]) to a boot file. This (conforming to [RFC2396]) to a boot file. This
string starts with the protocol which is used for string starts with the protocol which is used for
downloading. Separated by '://', the hostname or downloading. Separated by '://', the hostname or
IPv6 address of the server hosting the boot file IPv6 address of the server hosting the boot file
(see also the note below), the path, file name and (see also the note below), the path, file name and
query parts of the URL follow. query parts of the URL follow.
parameters 1...n These NULL-terminated ASCII strings are parameters parameters 1...n These NULL-terminated ASCII strings are parameters
skipping to change at page 6, line 11 skipping to change at page 6, line 13
should be downloaded from. All clients which implement support for should be downloaded from. All clients which implement support for
the SUBOPT_BOOTFILE_URL suboption MUST be able to handle IPv6 the SUBOPT_BOOTFILE_URL suboption MUST be able to handle IPv6
addresses here. The IPv6 address in the URL then MUST be enclosed in addresses here. The IPv6 address in the URL then MUST be enclosed in
"[" and "]" characters, conforming to [RFC2732]. Clients SHOULD also "[" and "]" characters, conforming to [RFC2732]. Clients SHOULD also
be able to handle hostnames in the URLs. However, in this case the be able to handle hostnames in the URLs. However, in this case the
firmware implementation on the client machine must support DNS, too. firmware implementation on the client machine must support DNS, too.
Due to size limitations, this might not be possible in all firmware Due to size limitations, this might not be possible in all firmware
implementations, so support for hostnames in the URLs is only implementations, so support for hostnames in the URLs is only
optional. optional.
5. Appearance of these options 5. Suboption: Vendor class extension
With this suboption, vendors can define their own netboot suboptions:
It can be used by clients and servers to exchange vendor-specific
information which is related to network booting.
This suboption can occur multiple times within a OPT_NET_BOOT option
(also with different enterprise-numbers in case a server and client
implementation supports different vendor extensions). Clients MUST
process them in the order in which they appear within the message.
Unsupported vendor extensions MUST be ignored.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SUBOPT_NETBOOT_VENDOR | suboption-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| enterprise-number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. vendor-class-data .
. (variable length) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Format description:
suboption-code SUBOPT_NETBOOT_VENDOR (tbd).
suboption-len Length of the vendor class suboption in octets
(not including the size of the suboption-code and
suboption-len fields).
enterprise-number The enterprise number of the vendor as registered
with IANA (see [VENDORIDS]).
vendor-class-data Vendor-specific information. The meaning is
defined by the vendor identified by the
enterprise-number.
6. Appearance of these options
The netboot option MUST NOT appear in DHCPv6 messages other than the The netboot option MUST NOT appear in DHCPv6 messages other than the
types Solicit, Advertise, Request, Renew, Rebind, Information-Request types Solicit, Advertise, Request, Renew, Rebind, Information-Request
and Reply. and Reply.
The number of the netboot option MAY appear in the Option Request The number of the netboot option MAY appear in the Option Request
Option in the DHCPv6 message types Solicit, Request, Renew, Rebind, Option in the DHCPv6 message types Solicit, Request, Renew, Rebind,
Information-Request and Reconfigure. Information-Request and Reconfigure.
The bootfile suboption MUST appear only in the netboot option. The suboptions MUST appear only in the netboot option.
6. Boot protocol considerations 7. Boot protocol considerations
RFC 906 [RFC906] suggests to use TFTP for bootstrap loading. Because RFC 906 [RFC906] suggests to use TFTP for bootstrap loading. Because
it is easy to implement this protocol in firmware (where one has to it is easy to implement this protocol in firmware (where one has to
deal with size and complexity constraints), this is still the deal with size and complexity constraints), this is still the
recommended protocol for network booting, so every firmware recommended protocol for network booting. Every firmware
implementation SHOULD at least support this protocol. The boot file implementation SHOULD at least support this protocol. The boot file
URLs then must be specified according to RFC 3617 [RFC3617]. URLs then must be specified according to RFC 3617 [RFC3617].
In some cases however, it might also be useful to use other protocols An alternative approach to TFTP network booting is to bootstrap the
like FTP or HTTP for network booting, so a firmware implementation system with iSCSI. In this case, the URL in the SUBOPT_BOOTFILE_URL
can support these protocols, too. Then it is up to the network suboption MUST be specified according to the "iscsi:" string
administrator to choose the appropriate boot protocol for the definition in chapter 5 of [RFC4173]. Note that [RFC4173] also
network, and to specify the right boot file URLs in the DHCPv6 suggests that the "iscsi:" string should be specified in the so-
configuration file. called "Root Path" option. However, this option does not exist for
DHCPv6 yet, and with the SUBOPT_BOOTFILE_URL it is also not necessary
anymore. So for IPv6 iSCSI booting, the "iscsi:" string MUST be
specified as URL in the SUBOPT_BOOTFILE_URL suboption instead.
7. IANA considerations In some different scenarios, it might also be useful to use other
protocols like FTP or HTTP for network booting, so a firmware
implementation can support these protocols, too. Then it is up to
the network administrator to choose the appropriate boot protocol for
the network, and to specify the right boot file URLs in the DHCPv6
server configuration file.
The following options need to be assigned by the IANA from the option 8. IANA considerations
The following option needs to be assigned by the IANA from the option
number space defined in the chapter 22 of the DHCPv6 RFC [RFC3315]. number space defined in the chapter 22 of the DHCPv6 RFC [RFC3315].
+---------------------+-------+--------------+ +--------------+-------+--------------+
| Option name | Value | Specified in | | Option name | Value | Specified in |
+---------------------+-------+--------------+ +--------------+-------+--------------+
| OPT_NET_BOOT | tbd | Section 3 | | OPT_NET_BOOT | tbd | Section 3 |
+--------------+-------+--------------+
The netboot suboptions numbers form a new name space to be defined by
the IANA:
+-----------------------+-------+--------------+
| Suboption name | Value | Specified in |
+-----------------------+-------+--------------+
| SUBOPT_BOOTFILE_URL | tbd | Section 4 | | SUBOPT_BOOTFILE_URL | tbd | Section 4 |
+---------------------+-------+--------------+ | SUBOPT_NETBOOT_VENDOR | tbd | Section 5 |
+-----------------------+-------+--------------+
8. Security considerations 9. Security considerations
The new DHCPv6 option described in this document could be sent in The new DHCPv6 option described in this document could be sent in
untrusted networks by malicious people with a fake DHCPv6 server to untrusted networks by malicious people with a fake DHCPv6 server to
confuse the booting clients. The clients could be provided with a confuse the booting clients. The clients could be provided with a
wrong URL so that the boot either fails, or even worse, the client wrong URL so that the boot either fails, or even worse, the client
boots the wrong operating system which has been provided by a boots the wrong operating system which has been provided by a
malicious file server. To prevent this kind of attack, clients malicious file server. To prevent this kind of attack, clients
SHOULD use authentication of DHCPv6 messages (see chapter 21. in RFC SHOULD use authentication of DHCPv6 messages (see chapter 21. in RFC
3315 [RFC3315]). 3315 [RFC3315]).
Note also that DHCPv6 messages are sent unencrypted by default. So Note also that DHCPv6 messages are sent unencrypted by default. So
the boot file URL options are sent unencrypted over the network, too. the boot file URL options are sent unencrypted over the network, too.
This can become a security risk since the URLs can contain sensitive This can become a security risk since the URLs can contain sensitive
information like user names and passwords (for example a URL like information like user names and passwords (for example a URL like
"ftp://username:password@servername/path/file"). At the current "ftp://username:password@servername/path/file"). At the current
point in time, there is no possibility to send encrypted DHCPv6 point in time, there is no possibility to send encrypted DHCPv6
messages, so it is strongly recommended not to use sensitive messages, so it is strongly recommended not to use sensitive
information in the URLs in untrusted networks. information in the URLs in untrusted networks.
9. Acknowledgements 10. Acknowledgements
The authors would like to thank Ketan P. Pancholi for corrections and The authors would like to thank Ketan P. Pancholi for corrections and
suggestions. suggestions.
Vijayabhaskar Kalusivalingam and Senthil Balasubramanian published a Vijayabhaskar Kalusivalingam and Senthil Balasubramanian published a
similar draft for IPv6 network booting some years ago (available at similar draft for IPv6 network booting some years ago (available at
http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-opt-rboot-00), which http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-opt-rboot-00), which
however was abandoned for unknown reasons. however was abandoned for unknown reasons.
10. References 11. References
10.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396, Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998. August 1998.
[RFC2732] Hinden, R., Carpenter, B., and L. Masinter, "Format for [RFC2732] Hinden, R., Carpenter, B., and L. Masinter, "Format for
Literal IPv6 Addresses in URL's", RFC 2732, December 1999. Literal IPv6 Addresses in URL's", RFC 2732, December 1999.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003. IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3617] Lear, E., "Uniform Resource Identifier (URI) Scheme and [RFC3617] Lear, E., "Uniform Resource Identifier (URI) Scheme and
Applicability Statement for the Trivial File Transfer Applicability Statement for the Trivial File Transfer
Protocol (TFTP)", RFC 3617, October 2003. Protocol (TFTP)", RFC 3617, October 2003.
10.2. Informative References [RFC4173] Sarkar, P., Missimer, D., and C. Sapuntzakis,
"Bootstrapping Clients using the Internet Small Computer
System Interface (iSCSI) Protocol", RFC 4173,
September 2005.
[VENDORIDS]
IANA, "Private Enterprise Numbers",
<http://www.iana.org/assignments/enterprise-numbers>.
11.2. Informative References
[RFC1350] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, [RFC1350] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33,
RFC 1350, July 1992. RFC 1350, July 1992.
[RFC906] Finlayson, R., "Bootstrap Loading using TFTP", RFC 906, [RFC906] Finlayson, R., "Bootstrap Loading using TFTP", RFC 906,
June 1984. June 1984.
Authors' Addresses Authors' Addresses
Thomas H. Huth Thomas H. Huth
 End of changes. 27 change blocks. 
46 lines changed or deleted 117 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/