draft-ietf-dhc-csr-06.txt   draft-ietf-dhc-csr-07.txt 
Network Working Group Ted Lemon Network Working Group Ted Lemon
Internet Draft Nominum, Inc. Internet Draft Nominum, Inc.
Stuart Cheshire Obsoletes: draft-ietf-dhc-csr-06.txt Stuart Cheshire
Apple Computer, Inc. Apple Computer, Inc.
Bernie Volz Bernie Volz
Ericsson Ericsson
Obsoletes: draft-ietf-dhc-csr-05.txt October, 2001 July, 2002
Expires April, 2002 Expires January, 2003
The Classless Static Route Option for DHCP The Classless Static Route Option for DHCPv4
<draft-ietf-dhc-csr-06.txt> <draft-ietf-dhc-csr-07.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is subject to all provisions
all provisions of Section 10 of RFC2026. of Section 10 of RFC2026.
This document is an Internet-Draft. Internet-Drafts are working Internet-Drafts are working documents of the Internet Engineering
documents of the Internet Engineering Task Force (IETF), its areas, Task Force (IETF), its areas, and its working groups. Note that
and its working groups. Note that other groups may also distribute other groups may also distribute working documents as
working documents as Internet-Drafts. Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six
and may be updated, replaced, or obsoleted by other documents at any months and may be updated, replaced, or obsoleted by other
time. It is inappropriate to use Internet-Drafts as reference documents at any time. It is inappropriate to use Internet-
material or to cite them other than as "work in progress". Drafts as reference 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/1id-abstracts.html
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
Abstract Abstract
This document defines a new DHCP option which is passed from the This document defines a new DHCP option which is passed from the
DHCP Server to the DHCP Client to configure a list of static routes DHCP Server to the DHCP Client to configure a list of static routes
in the client. This option supersedes the Static Route option in the client. The network destinations in these routes are
(option 33) defined in RFC2132 [2]. classless - each routing table entry includes a subnet mask.
Introduction Introduction
This option supersedes the Static Route option (option 33) defined
in RFC2132 [2].
The IP protocol [4] uses routers to transmit packets from hosts The IP protocol [4] uses routers to transmit packets from hosts
connected to one IP subnet to hosts connected to a different IP connected to one IP subnet to hosts connected to a different IP
subnet. When an IP host (the source host) wishes to transmit a subnet. When an IP host (the source host) wishes to transmit a
packet to another IP host (the destination), it consults its packet to another IP host (the destination), it consults its
routing table to determine the IP address of the router that should routing table to determine the IP address of the router that should
be used to forward the packet to the destination host. be used to forward the packet to the destination host.
The routing table on an IP host can be maintained in a variety of The routing table on an IP host can be maintained in a variety of
^L
ways - using a routing information protocol such as RIP [5], ICMP ways - using a routing information protocol such as RIP [5], ICMP
router discovery [6,7] or using the DHCP Router option, defined in router discovery [6,7] or using the DHCP Router option, defined in
RFC2132 [2]. RFC2132 [2].
In a network that already provides DHCP service, using DHCP to In a network that already provides DHCP service, using DHCP to
update the routing table on a DHCP client has several virtues. It update the routing table on a DHCP client has several virtues. It
is efficient, since it makes use of messages that would have been is efficient, since it makes use of messages that would have been
sent anyway. It is convenient - the DHCP server configuration sent anyway. It is convenient - the DHCP server configuration
is already being maintained, so maintaining routing information, at is already being maintained, so maintaining routing information, at
least on a relatively stable network, requires little extra work. least on a relatively stable network, requires little extra work.
If DHCP service is already in use, no additional infrastructure If DHCP service is already in use, no additional infrastructure
need be deployed. need be deployed.
The DHCP protocol as defined in RFC2131 [1] and the options defined The DHCP protocol as defined in RFC2131 [1] and the options defined
in RFC2132 [2] only provide a mechanism for installing a default in RFC2132 [2] only provide a mechanism for installing a default
route or installing a table of classed routes. Classed routes are route or installing a table of classful routes. Classful routes
routes whose subnet mask is implicit in the subnet number - see are routes whose subnet mask is implicit in the subnet number - see
section 3.2 of RFC791 [4] for details on classed routing. section 3.2 of RFC791 [4] for details on classful routing.
Classed routing is no longer in common use, so the DHCP Static Classful routing is no longer in common use, so the DHCP Static
Route option is no longer useful. Currently, classless routing, Route option is no longer useful. Currently, classless routing,
described in [8] and [9], is the most commonly-deployed form of described in [8] and [9], is the most commonly-deployed form of
routing on the Internet. In classless routing, IP addresses routing on the Internet. In classless routing, IP addresses
consist of a network number (the combination of the network number consist of a network number (the combination of the network number
and subnet number described in [8]) and a host number. and subnet number described in [8]) and a host number.
In classed IP, the network number and host number are derived from In classful IP, the network number and host number are derived from
the IP address using a bitmask whose value is determined by the first the IP address using a bitmask whose value is determined by the
few bits of the IP address. In classless IP, the network number first few bits of the IP address. In classless IP, the network
and host number are derived from the IP address using a seperate number and host number are derived from the IP address using a
quantity, the subnet mask. In order to determine the network to seperate quantity, the subnet mask. In order to determine the
which a given route applies, an IP host must know both the network network to which a given route applies, an IP host must know both
number AND the subnet mask for that network. the network number AND the subnet mask for that network.
The Static Routes option (option 33) does not provide a subnet mask The Static Routes option (option 33) does not provide a subnet mask
for each route - it is assumed that the subnet mask is implicit in for each route - it is assumed that the subnet mask is implicit in
whatever network number is specified in each route entry. The whatever network number is specified in each route entry. The
Classless Static Routes option does provide a subnet mask for each Classless Static Routes option does provide a subnet mask for each
entry, so that the subnet mask can be other than what would be entry, so that the subnet mask can be other than what would be
determined using the algorithm specified in RFC791 [4] and RFC950 determined using the algorithm specified in RFC791 [4] and RFC950
[8]. [8].
Definitions Definitions
skipping to change at line 107 skipping to change at page 3, line 5
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [3]. document are to be interpreted as described in RFC 2119 [3].
This document also uses the following terms: This document also uses the following terms:
"DHCP client" "DHCP client"
DHCP client or "client" is an Internet host using DHCP to DHCP client or "client" is an Internet host using DHCP to
obtain configuration parameters such as a network address. obtain configuration parameters such as a network address.
^L
"DHCP server" "DHCP server"
A DHCP server or "server" is an Internet host that returns A DHCP server or "server" is an Internet host that returns
configuration parameters to DHCP clients. configuration parameters to DHCP clients.
"link" "link"
Any set of all network attachment points that will recieve Any set of all network attachment points that will recieve
a link-layer broadcast sent on any one of the attachment a link-layer broadcast sent on any one of the attachment
points. This term is used in DHCP because in some cases points. This term is used in DHCP because in some cases
skipping to change at line 159 skipping to change at page 4, line 4
The width of the subnet mask describes the number of one bits in The width of the subnet mask describes the number of one bits in
the mask, so for example a subnet with a subnet number of the mask, so for example a subnet with a subnet number of
10.0.127.0 and a netmask of 255.255.255.0 would have a subnet mask 10.0.127.0 and a netmask of 255.255.255.0 would have a subnet mask
width of 24. width of 24.
The significant portion of the subnet number is simply all of the The significant portion of the subnet number is simply all of the
octets of the subnet number where the corresponding octet in the octets of the subnet number where the corresponding octet in the
subnet mask is non-zero. The number of significant octets is the subnet mask is non-zero. The number of significant octets is the
width of the subnet mask divided by eight, rounding up, as shown width of the subnet mask divided by eight, rounding up, as shown
^L
in the following table: in the following table:
Width of subnet mask Number of significant octets Width of subnet mask Number of significant octets
0 0 0 0
1- 8 1 1- 8 1
9-16 2 9-16 2
17-24 3 17-24 3
25-32 4 25-32 4
The following table contains some examples of how various subnet The following table contains some examples of how various subnet
number/mask combinations can be encoded: number/mask combinations can be encoded:
Subnet number Subnet mask Destination descriptor Subnet number Subnet mask Destination descriptor
0 0 0 0 0 0
10.0.0.0 255.0.0.0 8.10 10.0.0.0 255.0.0.0 8.10
10.0.0.0 255.255.255.0 24.10.0.0 10.0.0.0 255.255.255.0 24.10.0.0
10.17.0.0 255.255.0.0 16.10.17 10.17.0.0 255.255.0.0 16.10.17
10.27.129.0 255.255.255.0 24.10.27.129 10.27.129.0 255.255.255.0 24.10.27.129
10.229.0.128 255.255.255.128 25.10.229.0.128 10.229.0.128 255.255.255.128 25.10.229.0.128
skipping to change at line 213 skipping to change at page 5, line 5
DHCP Client Behavior DHCP Client Behavior
DHCP clients that do not support this option MUST ignore it if it DHCP clients that do not support this option MUST ignore it if it
is received from a DHCP server. DHCP clients that support this is received from a DHCP server. DHCP clients that support this
option MUST install the routes specified in the option, except as option MUST install the routes specified in the option, except as
specified in the Local Subnet Routes section. DHCP clients that specified in the Local Subnet Routes section. DHCP clients that
support this option MUST NOT install the routes specified in the support this option MUST NOT install the routes specified in the
Static Routes option (option code 33) if both a Static Routes Static Routes option (option code 33) if both a Static Routes
option and the Classless Static Routes option are provided. option and the Classless Static Routes option are provided.
^L
DHCP clients that support this option and that send a DHCP DHCP clients that support this option and that send a DHCP
Parameter Request List option MUST request both this option and the Parameter Request List option MUST request both this option and the
Router option [2] in the DHCP Parameter Request List. Router option [2] in the DHCP Parameter Request List.
DHCP clients that support this option and send a parameter request DHCP clients that support this option and send a parameter request
list MAY also request the Static Routes option, for compatibility list MAY also request the Static Routes option, for compatibility
with older servers that don't support Classless Static Routes. with older servers that don't support Classless Static Routes.
The Classless Static Routes option code MUST appear in the The Classless Static Routes option code MUST appear in the
parameter request list prior to both the Router option code and the parameter request list prior to both the Router option code and the
Static Routes option code, if present. Static Routes option code, if present.
If the DHCP server returns both a Router option and a Classless If the DHCP server returns both a Router option and a Classless
Static Routes option, the DHCP client MUST ignore the Router Static Routes option, the DHCP client MUST ignore the Router
option. option.
After deriving a subnet number and subnet mask from each After deriving a subnet number and subnet mask from each
destination descriptor, the DHCP client MUST set any bits in the destination descriptor, the DHCP client MUST set any bits in the
skipping to change at line 269 skipping to change at page 6, line 5
DHCP Server administrator responsibilities DHCP Server administrator responsibilities
Many clients may not implement the Classless Static Routes option. Many clients may not implement the Classless Static Routes option.
DHCP server administrators should therefore configure their DHCP DHCP server administrators should therefore configure their DHCP
servers to send both a Router option and a Classless Static Routes servers to send both a Router option and a Classless Static Routes
option, and should specify the default router(s) both in the option, and should specify the default router(s) both in the
Router option and in the Classless Static Routes option. Router option and in the Classless Static Routes option.
DHCP Server Considerations DHCP Server Considerations
^L
When a DHCP client requests the Classless Static Routes option and When a DHCP client requests the Classless Static Routes option and
also requests either or both of the Router option and the Static also requests either or both of the Router option and the Static
Routes option, and the DHCP server is sending Classless Static Routes option, and the DHCP server is sending Classless Static
Routes options to that client, the server SHOULD NOT include the Routes options to that client, the server SHOULD NOT include the
Router or Static Routes options. Router or Static Routes options.
Security Considerations Security Considerations
DHCP currently provides no authentication or security mechanisms. Potential exposures to attack in the DHCP protocol are discussed in
Potential exposures to attack are discussed in section 7 of the DHCP section 7 of the DHCP protocol specification [1] and in
protocol specification [1]. The Classless Static Routes option can Authentication for DHCP Messages [5].
be used to misdirect network traffic by providing incorrect IP
addresses for routers. The Classless Static Routes option can be used to misdirect network
traffic by providing incorrect IP addresses for routers. This can
be either a Denial of Service attack, where the router IP address
given is simply valid, or can be used to set up a man-in-the-middle
attack by providing the IP address of a potential snooper. This is
not a new problem - the existing Router and Static Routes options
defined in RFC2132 [2] exhibit the same vulnerability.
IANA Considerations IANA Considerations
This DHCP option will require the allocation of an option code in This DHCP option will require the allocation of an option code in
the list DHCP option codes that the IANA maintains. the list of DHCP option codes that the IANA maintains.
References References
[1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
Bucknell University, March 1997. Bucknell University, March 1997.
[2] Alexander, S. and Droms, R., "DHCP Options and BOOTP Vendor [2] Alexander, S. and Droms, R., "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, Silicon Graphics, Inc., Bucknell Extensions", RFC 2132, Silicon Graphics, Inc., Bucknell
University, March 1997. University, March 1997.
[3] Bradner, S., "Key words for use in RFCs to indicate requirement [3] Bradner, S., "Key words for use in RFCs to indicate requirement
levels", RFC 2119, Harvard University, March 1997. levels", RFC 2119, Harvard University, March 1997.
skipping to change at line 312 skipping to change at page 6, line 55
Xerox PARC, September 1991. Xerox PARC, September 1991.
[7] Postel, J., "Internet Control Message Protocol", RFC 792, [7] Postel, J., "Internet Control Message Protocol", RFC 792,
USC/Information Sciences Institute, September 1981. USC/Information Sciences Institute, September 1981.
[8] Mogul, J., Postel, J., "Internet Standard Subnetting [8] Mogul, J., Postel, J., "Internet Standard Subnetting
Procedure", RFC950, Stanford University, USC/Information Procedure", RFC950, Stanford University, USC/Information
Sciences Institute, August 1985. Sciences Institute, August 1985.
[9] Pummill, T., Manning, B., "Variable Length Subnet Table For [9] Pummill, T., Manning, B., "Variable Length Subnet Table For
IPv4", RFC1878, Alantec, USC/Information Sciences Institute, IPv4", RFC1878, Alantec, USC/Information Sciences Institute,
December, 1995. December, 1995.
[10] Lemon, T., Cheshire, S., "Encoding Long DHCP Options", [10] Lemon, T., Cheshire, S., "Encoding Long DHCP Options",
draft-ietf-dhc-concat-02.txt, Nominum, Inc., October, 2001. draft-ietf-dhc-concat-05.txt, Nominum, Inc., Apple Computer,
Inc., July, 2002.
^L
Author Information Author Information
Ted Lemon Ted Lemon
Nominum, Inc. Nominum, Inc.
950 Charter Street 2385 Bay Road
Redwood City, CA 94043 Redwood City, CA 94063
email: Ted.Lemon@nominum.com email: Ted.Lemon@nominum.com
Stuart Cheshire Stuart Cheshire
Apple Computer, Inc. Apple Computer, Inc.
1 Infinite Loop 1 Infinite Loop
Cupertino Cupertino
California 95014 California 95014
USA USA
Phone: +1 408 974 3207 Phone: +1 408 974 3207
EMail: rfc@stuartcheshire.org EMail: rfc@stuartcheshire.org
Bernie Volz Bernie Volz
Ericsson Ericsson
959 Concord Street 959 Concord Street
Framingham, MA, 01701 Framingham, MA, 01701
Phone: +1 508 875 3162 Phone: +1 508 875 3162
EMail: bernie.volz@ericsson.com EMail: bernie.volz@ericsson.com
Expiration Expiration
This document will expire on April 31, 2002. This document will expire on December 31, 2002.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2000-2001). All Rights Copyright (C) The Internet Society (2000-2002). All Rights
Reserved. Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than followed, or as required to translate it into languages other than
English. English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
^L
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 

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