draft-ietf-dhc-dhcpv4-bulk-leasequery-06.txt   draft-ietf-dhc-dhcpv4-bulk-leasequery-07.txt 
DHC Working Group Kim Kinnear DHC Working Group Kim Kinnear
Internet Draft Mark Stapp Internet Draft Mark Stapp
Intended Status: Standards Track Cisco Systems, Inc. Intended Status: Standards Track Cisco Systems, Inc.
Expires: September 12, 2012 D. Rao Expires: April 15, 2013 D. Rao
B. Joshi B. Joshi
Infosys Technologies Ltd. Infosys Technologies Ltd.
Neil Russell Neil Russell
BMC Software, Inc. BMC Software, Inc.
March 12, 2012 October 15, 2012
Bulk DHCPv4 Lease Query Bulk DHCPv4 Lease Query
<draft-ietf-dhc-dhcpv4-bulk-leasequery-06.txt> <draft-ietf-dhc-dhcpv4-bulk-leasequery-07.txt>
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and 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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 2, line 28 skipping to change at page 2, line 28
1. Introduction................................................. 3 1. Introduction................................................. 3
2. Terminology.................................................. 4 2. Terminology.................................................. 4
3. Design Goals................................................. 7 3. Design Goals................................................. 7
3.1. Information Acquisition before Data Starts................. 7 3.1. Information Acquisition before Data Starts................. 7
3.2. Lessen need for Caching and Negative Caching............... 7 3.2. Lessen need for Caching and Negative Caching............... 7
3.3. Antispoofing in 'Fast Path'................................ 8 3.3. Antispoofing in 'Fast Path'................................ 8
3.4. Minimize data transmission................................. 8 3.4. Minimize data transmission................................. 8
4. Protocol Overview............................................ 8 4. Protocol Overview............................................ 8
5. Interaction Between UDP Leasequery and Bulk Leasequery....... 10 5. Interaction Between UDP Leasequery and Bulk Leasequery....... 10
6. Message and Option Definitions............................... 10 6. Message and Option Definitions............................... 11
6.1. Message Framing for TCP.................................... 10 6.1. Message Framing for TCP.................................... 11
6.2. New or Changed Options..................................... 11 6.2. New or Changed Options..................................... 12
6.3. Connection and Transmission Parameters..................... 19 6.3. Connection and Transmission Parameters..................... 19
7. Requestor Behavior........................................... 19 7. Requestor Behavior........................................... 19
7.1. Connecting and General Processing.......................... 19 7.1. Connecting and General Processing.......................... 19
7.2. Forming a Bulk Leasequery.................................. 20 7.2. Forming a Bulk Leasequery.................................. 20
7.3. Processing Bulk Replies.................................... 22 7.3. Processing Bulk Replies.................................... 22
7.4. Processing Time Values in Leasequery messages.............. 24 7.4. Processing Time Values in Leasequery messages.............. 24
7.5. Querying Multiple Servers.................................. 25 7.5. Querying Multiple Servers.................................. 25
7.6. Making Sense Out of Multiple Responses Concerning a Single. 25 7.6. Making Sense Out of Multiple Responses Concerning a Single. 25
7.7. Multiple Queries to a Single Server over One Connection.... 26 7.7. Multiple Queries to a Single Server over One Connection.... 26
7.8. Closing Connections........................................ 27 7.8. Closing Connections........................................ 27
8. Server Behavior.............................................. 27 8. Server Behavior.............................................. 28
8.1. Accepting Connections...................................... 27 8.1. Accepting Connections...................................... 28
8.2. Replying to a Bulk Leasequery.............................. 28 8.2. Replying to a Bulk Leasequery.............................. 28
8.3. Building a Single Reply for Bulk Leasequery................ 31 8.3. Building a Single Reply for Bulk Leasequery................ 31
8.4. Multiple or Parallel Queries............................... 32 8.4. Multiple or Parallel Queries............................... 33
8.5. Closing Connections........................................ 33 8.5. Closing Connections........................................ 33
9. Security Considerations...................................... 33 9. Security Considerations...................................... 34
10. IANA Considerations......................................... 34 10. IANA Considerations......................................... 35
11. Contributing Authors........................................ 36 11. Contributing Authors........................................ 37
12. Acknowledgements............................................ 37 12. Acknowledgements............................................ 38
13. References.................................................. 37 13. References.................................................. 38
13.1. Normative References...................................... 37 13.1. Normative References...................................... 38
13.2. Informative References.................................... 38 13.2. Informative References.................................... 39
1. Introduction 1. Introduction
The DHCPv4 protocol [RFC2131] [RFC2132] specifies a mechanism for the The DHCPv4 protocol [RFC2131] [RFC2132] specifies a mechanism for the
assignment of IPv4 address and configuration information to IPv4 assignment of IPv4 address and configuration information to IPv4
nodes. DHCPv4 servers maintain authoritative binding information. nodes. DHCPv4 servers maintain authoritative binding information.
+--------+ +--------+
| DHCPv4 | +--------------+ | DHCPv4 | +--------------+
| Server |-...-| DSLAM | | Server |-...-| DHCP |
| | | Relay Agent | | | | Relay Agent |
+--------+ +--------------+ +--------+ +--------------+
| | | |
+------+ +------+ +------+ +------+
|Modem1| |Modem2| |Modem1| |Modem2|
+------+ +------+ +------+ +------+
| | | | | |
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
|Node1| |Node2| |Node3| |Node1| |Node2| |Node3|
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
skipping to change at page 4, line 7 skipping to change at page 3, line 45
relay agent information option [RFC3046] before relaying them to the relay agent information option [RFC3046] before relaying them to the
configured DHCPv4 servers (see Figure 1). In this process, some relay configured DHCPv4 servers (see Figure 1). In this process, some relay
agents also glean lease information sent by the server and cache it agents also glean lease information sent by the server and cache it
locally. This information is used for a variety of purposes. Two locally. This information is used for a variety of purposes. Two
examples are prevention of spoofing attempts from the DHCPv4 clients, examples are prevention of spoofing attempts from the DHCPv4 clients,
and installation of routes. When a relay agent reboots, this and installation of routes. When a relay agent reboots, this
information is frequently lost. information is frequently lost.
The DHCPv4 Leasequery capability [RFC4388] extends the basic DHCPv4 The DHCPv4 Leasequery capability [RFC4388] extends the basic DHCPv4
capability to allow an external entity, such as a relay agent, to capability to allow an external entity, such as a relay agent, to
query a DHCPv4 server to recover lease state information about a query a DHCPv4 server to rapidly recover lease state information
particular IP address or client in near real-time. about a particular IP address or client.
The existing query types in Leasequery are typically data driven; the The existing query types in Leasequery are typically data driven; the
relay agent initiates the Leasequery when it receives data traffic relay agent initiates the Leasequery when it receives data traffic
from or to the client. This approach may not scale well when there from or to the client. This approach may not scale well when there
are thousands of clients connected to the relay agent or when the are thousands of clients connected to the relay agent or when the
relay agent has a need to rebuild its internal data store prior to relay agent has a need to rebuild its internal data store prior to
processing traffic in one direction or another. processing traffic in one direction or another.
Some applications require the ability to query the server without Some applications require the ability to query the server without
waiting for traffic from or to clients. This query capability in turn waiting for traffic from or to clients. This query capability in turn
skipping to change at page 5, line 38 skipping to change at page 5, line 33
after one message is received by a requestor from a DHCPv4 after one message is received by a requestor from a DHCPv4
server, a more accurate value is derived from continuously server, a more accurate value is derived from continuously
examining the instantaneous value developed from each message examining the instantaneous value developed from each message
received from a DHCPv4 server and using it to make small received from a DHCPv4 server and using it to make small
adjustments to the existing value held in the requestor. adjustments to the existing value held in the requestor.
o "Default VPN" o "Default VPN"
Indicates that the address being described belongs to the set of Indicates that the address being described belongs to the set of
addresses not part of any VPN. In other words, the normal addresses not part of any VPN. In other words, the normal
address space operated on by DHCP. This includes private address space operated on by DHCP. This includes Special Use
addresses, for example the 10.x.x.x addresses as well as the IPv4 Addresses as defined in [RFC1918].
other private subnets that are not routed on the open internet.
o "DHCPv4 client" o "DHCPv4 client"
A DHCPv4 client is an Internet node using DHCPv4 to obtain A DHCPv4 client is an Internet node using DHCPv4 to obtain
configuration parameters such as a network address. configuration parameters such as a network address.
o "DHCPv4 relay agent" o "DHCPv4 relay agent"
A DHCPv4 relay agent is a third-party agent that transfers BOOTP A DHCPv4 relay agent is an agent that is neither a DHCPv4 client
and DHCPv4 messages between clients and servers residing on nor a DHCP server that transfers BOOTP and DHCPv4 messages
different subnets, per [RFC951] and [RFC1542]. between clients and servers residing on different subnets, per
[RFC951] and [RFC1542].
o "DHCPv4 server" o "DHCPv4 server"
A DHCPv4 server is an Internet node that returns configuration A DHCPv4 server is an Internet node that returns configuration
parameters to DHCPv4 clients. parameters to DHCPv4 clients.
o "DSLAM" o "DSLAM"
Digital Subscriber Line Multiplexer. Digital Subscriber Line Multiplexer.
o "downstream" o "downstream"
Refers to a direction away from the central part of a network Refers to a direction away from the central part of a network
and toward the edge. In a DHCPv4 context, typically refers to a and toward the edge. In a DHCPv4 context, typically refers to a
network direction which is away from the DHCPv4 server. network direction which is away from the DHCPv4 server and
toward the DHCPv4 client..
o "Global VPN" o "Global VPN"
Another name for the "Default VPN". Another name for the "Default VPN".
o "IP address" o "IP address"
In this document, the term "IP address" refers to an IPv4 IP In this document, the term "IP address" refers to an IPv4 IP
address. address.
skipping to change at page 6, line 50 skipping to change at page 6, line 46
o "MAC address" o "MAC address"
In the context of a DHCPv4 message, a MAC address consists of In the context of a DHCPv4 message, a MAC address consists of
the fields: hardware type "htype", hardware length "hlen", and the fields: hardware type "htype", hardware length "hlen", and
client hardware address "chaddr". client hardware address "chaddr".
o "upstream" o "upstream"
Refers to a direction toward the central part of a network and Refers to a direction toward the central part of a network and
away from the edge. In a DHCPv4 context, typically refers to a away from the edge. In a DHCPv4 context, typically refers to a
network direction which is toward the DHCPv4 server. network direction which is away from the DHCPv4 client toward
the DHCPv4 server.
o "stable storage" o "stable storage"
Stable storage is used to hold information concerning IP address Stable storage is used to hold information concerning IP address
bindings (among other things) so that this information is not bindings (among other things) so that this information is not
lost in the event of a failure which requires restart of the lost in the event of a failure which requires restart of the
network element. DHCPv4 servers are typically expected to have network element. DHCPv4 servers are typically expected to have
high speed access to stable storage, while relay agents and high speed access to stable storage, while relay agents and
access concentrators usually do not have access to stable access concentrators usually do not have access to stable
storage, although they may have periodic access to such storage. storage, although they may have periodic access to such storage.
o "xid" o "xid"
skipping to change at page 7, line 20 skipping to change at page 7, line 18
storage, although they may have periodic access to such storage. storage, although they may have periodic access to such storage.
o "xid" o "xid"
Transaction-id. The term "xid" refers to the DHCPv4 field Transaction-id. The term "xid" refers to the DHCPv4 field
containing the transaction-id of the message. containing the transaction-id of the message.
3. Design Goals 3. Design Goals
The goal of this document is to provide a lightweight mechanism for The goal of this document is to provide a lightweight mechanism for
an Access Concentrator or other network element to retrieve IP an Access Concentrator or other network element (such as a DHCP Relay
address binding information available in the DHCPv4 server. The Agent) to retrieve IP address binding information available in the
mechanism should also allow an Access Concentrator to retrieve DHCPv4 server. The mechanism should also allow an Access
consolidated IP address binding information for either the entire Concentrator or DHCP Relay Agent to retrieve consolidated IP address
access concentrator or a single connection/circuit. binding information for either the entire access concentrator or a
single connection/circuit. Throughout the discussion below,
everything that applies to an Access Concentrator also applies to a
DHCP Relay Agent.
3.1. Information Acquisition before Data Starts 3.1. Information Acquisition before Data Starts
The existing data driven approach required by [RFC4388] means that The existing data driven approach required by [RFC4388] means that
the Leasequeries can only be performed after an Access Concentrator the Leasequeries can only be performed after an Access Concentrator
receives data. To implement antispoofing, the concentrator must drop receives data. To implement antispoofing, the concentrator must drop
messages for each client until it gets lease information from the messages for each client until it gets lease information from the
DHCPv4 server for that client. If an Access Concentrator finishes the DHCPv4 server for that client. If an Access Concentrator finishes the
Leasequeries before it starts receiving data, then there is no need Leasequeries before it starts receiving data, then there is no need
to drop legitimate messages. In this way, outage time may be reduced. to drop legitimate messages. In this way, outage time may be reduced.
3.2. Lessen need for Caching and Negative Caching 3.2. Lessen need for Caching and Negative Caching
The result of a single Leasequery should be cached, whether that The result of a single Leasequery should be cached, whether that
results in a positive or negative cache, in order to remember that results in a positive or negative cache, in order to remember that
the Leasequery was performed. This caching is required to limit the the Leasequery was performed. This caching is required to limit the
traffic imposed upon a DHCPv4 server by Leasequeries for information traffic imposed upon a DHCPv4 server by Leasequeries for information
already received. already received.
These caches not only consume precious resources, they also need to These caches not only consume precious resources, they also need to
be managed. Hence they should be avoided as much as possible. be managed. Hence they should be avoided as much as possible. One
of the goals of the DHCPv4 Bulk Leasequery is to reduce the need for
this sort of caching.
3.3. Antispoofing in 'Fast Path' 3.3. Antispoofing in 'Fast Path'
If Antispoofing is not done in the fast path, it will become a If Antispoofing is not done in the fast path, it will become a
bottleneck and may lead to denial of service of the access bottleneck and may lead to denial of service of the access
concentrator. The Leasequeries should make it possible to do concentrator. The Leasequeries should make it possible to do
antispoofing in the fast path. antispoofing in the fast path.
3.4. Minimize data transmission 3.4. Minimize data transmission
skipping to change at page 10, line 6 skipping to change at page 10, line 6
this type of query is to update an existing database with this type of query is to update an existing database with
changes after a particular point in time. changes after a particular point in time.
Any of the above queries can be qualified by the specification of a Any of the above queries can be qualified by the specification of a
query-start-time or a query-end-time (or both). When these timers are query-start-time or a query-end-time (or both). When these timers are
used as qualifiers, they indicate that a binding should be included used as qualifiers, they indicate that a binding should be included
if it changed on or after the query-start-time and on or before the if it changed on or after the query-start-time and on or before the
query-end-time. query-end-time.
In addition, any of the above queries can be qualified by the In addition, any of the above queries can be qualified by the
specification of a vpn-id option [VpnId] to select the VPN on which specification of a vpn-id option [RFC6607] to select the VPN on which
the query should be processed. The vpn-id option is also extended to the query should be processed. The vpn-id option is also extended to
allow queries across all available VPNs. In the absence of any vpn-id allow queries across all available VPNs. In the absence of any vpn-id
option, only the default (global) VPN is used to satisfy the query. option, only the default (global) VPN is used to satisfy the query.
5. Interaction Between UDP Leasequery and Bulk Leasequery 5. Interaction Between UDP Leasequery and Bulk Leasequery
Bulk Leasequery can be seen as an extension of the existing UDP Bulk Leasequery can be seen as an extension of the existing UDP
Leasequery protocol [RFC4388]. This section clarifies the Leasequery protocol [RFC4388]. This section clarifies the
relationship between the two protocols. relationship between the two protocols.
Only the DHCPBULKLEASEQUERY request is supported over the Bulk The Bulk Leasequery TCP connection is only designed to handle the
Leasequery connection. No other DHCPv4 requests are supported. The DHCPBULKLEASEQUERY request. It is not intended as an alternative
Bulk Leasequery connection is not an alternative DHCPv4 communication DHCPv4 communication option for clients seeking other DHCPv4
option for clients seeking other DHCPv4 services. services. DHCPv4 address allocation could not be performed over a
TCP connection in any case, as a TCP connection requires an IP
address, as no IPv4 address exists prior to a successful DHCPv4
address allocation exchange. In addition, the existing DHCPv4 UDP
transmission regime is implemented in untold millions of devices
deployed worldwide, and complicating DHCPv4 services with alternative
transmission approaces (even if it were possible) would be worse than
any perceived benefit to doing so.
Two of the query-types introduced in the UDP Leasequery protocol can Two of the query-types introduced in the UDP Leasequery protocol can
be used in the Bulk Leasequery protocol -- query by MAC address and be used in the Bulk Leasequery protocol -- query by MAC address and
query by client-id. query by client-id.
The contents of the reply messages are similar between the existing The contents of the reply messages are similar between the existing
UDP Leasequery protocol and the Bulk Leasequery protocol, though more UDP Leasequery protocol and the Bulk Leasequery protocol, though more
information is returned in the Bulk Leasequery messages. information is returned in the Bulk Leasequery messages.
One change in behavior for these existing queries is required when One change in behavior for these existing queries is required when
skipping to change at page 11, line 31 skipping to change at page 11, line 38
+---------------+---------------+ + +---------------+---------------+ +
| | | |
. remainder of DHCPv4 message, . remainder of DHCPv4 message,
. from Figure 1 of [RFC2131] . . from Figure 1 of [RFC2131] .
. . . .
. (variable) . . (variable) .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
message-size the number of octets in the message that message-size the number of octets in the message that
follows, as a 16-bit integer in network follows, as a 16-bit unsigned integer in
byte-order. network byte-order.
All other fields are as specified in DHCPv4 [RFC2131]. All other fields are as specified in DHCPv4 [RFC2131].
Figure 2: Format of a DHCPv4 message in TCP Figure 2: Format of a DHCPv4 message in TCP
The intent in using this format is that code which currently knows The intent in using this format is that code which currently knows
how to deal with sending or receiving a message in [RFC2131] format how to deal with sending or receiving a message in [RFC2131] format
will easily be able to deal with the message contained in the TCP will easily be able to deal with the message contained in the TCP
framing. framing.
skipping to change at page 12, line 42 skipping to change at page 13, line 5
The code for this option is TBD1. The length of this option is a The code for this option is TBD1. The length of this option is a
minimum of 1 octet. minimum of 1 octet.
Status Status Status Status
Code Len Code Message Code Len Code Message
+------+------+------+------+------+-- --+-----+ +------+------+------+------+------+-- --+-----+
| TBD1 | n+1 |status| s1 | s2 | ... | sn | | TBD1 | n+1 |status| s1 | s2 | ... | sn |
+------+------+------+------+------+-- --+-----+ +------+------+------+------+------+-- --+-----+
The status-code is an octet defined in the table below. The Status The status-code is indicated in one octet as defined in the table
Message is an optional UTF-8 encoded text string suitable for display below. The Status Message is an optional UTF-8 encoded text string
to an end user, which MUST NOT be null-terminated. suitable for display to an end user. This text string MUST NOT
contain a termination character (e.g., a null). The len field
describes the length of the status message without any terminator
character. Nulls characters MUST NOT appear in the Status Message
string and it is a protocol violation for them to appear in any
position in the Status Message, including at the end.
Name Status Code Description Name Status Code Description
---- ----------- ----------- ---- ----------- -----------
Success 000 Success. Also signaled by absence of Success 000 Success. Also signaled by absence of
a status-code option. a status-code option.
UnspecFail 001 Failure, reason unspecified. UnspecFail 001 Failure, reason unspecified.
QueryTerminated 002 Indicates that the server is unable to QueryTerminated 002 Indicates that the server is unable to
perform a query or has prematurely terminated perform a query or has prematurely terminated
skipping to change at page 13, line 32 skipping to change at page 13, line 41
A status-code option MAY appear in the options field of a DHCPv4 A status-code option MAY appear in the options field of a DHCPv4
message. If the status-code option does not appear, it is assumed message. If the status-code option does not appear, it is assumed
that the operation was successful. The status-code option SHOULD NOT that the operation was successful. The status-code option SHOULD NOT
appear in a message which is successful unless there is some text appear in a message which is successful unless there is some text
string that needs to be communicated to the requestor. string that needs to be communicated to the requestor.
6.2.3. base-time 6.2.3. base-time
The base-time option is the current time the message was created to The base-time option is the current time the message was created to
be sent by the DHCPv4 server to the requestor of the Bulk Leasequery. be sent by the DHCPv4 server to the requestor of the Bulk Leasequery.
This MUST be an absolute time. All of the other time based options in This MUST be an absolute time. All of the other time based options
the reply message are relative to this time, including the dhcp- in the reply message are relative to this time, including the dhcp-
lease-time [RFC2132] and client-last-transaction-time [RFC4388]. lease-time [RFC2132] and client-last-transaction-time [RFC4388].
This time is in the context of the DHCPv4 server who placed this This time is in the context of the DHCPv4 server who placed this
option in a message. option in a message.
This is an integer in network byte order. This is an unsigned integer in network byte order.
The code for this option is TBD2. The length of this option is 4 The code for this option is TBD2. The length of this option is 4
octets. octets.
DHCPv4 Server DHCPv4 Server
Code Len base-time Code Len base-time
+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+
| TBD2| 4 | t1 | t2 | t3 | t4 | | TBD2| 4 | t1 | t2 | t3 | t4 |
+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+
6.2.4. start-time-of-state 6.2.4. start-time-of-state
The start-time-of-state option allows the receiver to determine the The start-time-of-state option allows the receiver to determine the
time at which the IP address made the transition into its current time at which the IP address made the transition into its current
state. state.
This MUST NOT be an absolute time, which is equivalent to saying that This MUST NOT be an absolute time, which is equivalent to saying that
this MUST NOT be an absolute number of seconds since Jan 1, 1970. this MUST NOT be an absolute number of seconds since Jan 1, 1970.
Instead, this MUST be the integer number of seconds from the time the Instead, this MUST be the unsigned integer number of seconds from the
IP address transitioned its current state to the time specified in time the IP address transitioned its current state to the time
the base-time option in the same message. specified in the base-time option in the same message.
This is an integer in network byte order. This is an unsigned integer in network byte order.
The code for this option is TBD3. The length of this option is 4 The code for this option is TBD3. The length of this option is 4
octets. octets.
Seconds in the past Seconds in the past
Code Len from base-time Code Len from base-time
+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+
| TBD3| 4 | t1 | t2 | t3 | t4 | | TBD3| 4 | t1 | t2 | t3 | t4 |
+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+
skipping to change at page 14, line 46 skipping to change at page 15, line 7
information it has received from the DHCPv4 server. This MUST be an information it has received from the DHCPv4 server. This MUST be an
absolute time in the DHCPv4 server's context (see Section 7.4). absolute time in the DHCPv4 server's context (see Section 7.4).
Typically (though this is not a requirement) the query-start-time Typically (though this is not a requirement) the query-start-time
option will contain the value most recently received in a base-time option will contain the value most recently received in a base-time
option by the requestor, as this will indicate the last successful option by the requestor, as this will indicate the last successful
communication with the DHCP server. communication with the DHCP server.
This MUST be an absolute time. This MUST be an absolute time.
This is an integer in network byte order. This is an unsigned integer in network byte order.
The code for this option is TBD4. The length of this option is 4 The code for this option is TBD4. The length of this option is 4
octets. octets.
DHCPv4 Server DHCPv4 Server
Code Len query-start-time Code Len query-start-time
+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+
| TBD4| 4 | t1 | t2 | t3 | t4 | | TBD4| 4 | t1 | t2 | t3 | t4 |
+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+
skipping to change at page 15, line 25 skipping to change at page 15, line 32
the query-end-time should be included in the response to the query. the query-end-time should be included in the response to the query.
The requestor MUST determine the query-end-time based on lease The requestor MUST determine the query-end-time based on lease
information it has received from the DHCPv4 server. This MUST be an information it has received from the DHCPv4 server. This MUST be an
absolute time in the context of the DHCPv4 server. absolute time in the context of the DHCPv4 server.
In the absence of information to the contrary, the requestor SHOULD In the absence of information to the contrary, the requestor SHOULD
assume that the time context of the DHCPv4 server is identical to the assume that the time context of the DHCPv4 server is identical to the
time context of the requestor (see Section 7.4). time context of the requestor (see Section 7.4).
This is an integer in network byte order. This is an unsigned integer in network byte order.
The code for this option is TBD5. The length of this option is 4 The code for this option is TBD5. The length of this option is 4
octets. octets.
DHCPv4 Server DHCPv4 Server
Code Len query-end-time Code Len query-end-time
+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+
| TBD5| 4 | t1 | t2 | t3 | t4 | | TBD5| 4 | t1 | t2 | t3 | t4 |
+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+
skipping to change at page 17, line 13 skipping to change at page 17, line 13
in multiple server deployments, where sometimes one server must in multiple server deployments, where sometimes one server must
interlock a state change with one or more other servers. Should a interlock a state change with one or more other servers. Should a
Bulk Leasequery need to send information concerning the state of the Bulk Leasequery need to send information concerning the state of the
IP address during this period, it SHOULD use the TRANSITIONING state, IP address during this period, it SHOULD use the TRANSITIONING state,
since the IP address is likely to be neither ACTIVE or AVAILABLE. since the IP address is likely to be neither ACTIVE or AVAILABLE.
There is no requirement for the state of an IP address to transition There is no requirement for the state of an IP address to transition
in a well defined way from state to state. To put this another way, in a well defined way from state to state. To put this another way,
you cannot draw a simple state transition graph for the states of an you cannot draw a simple state transition graph for the states of an
IP address and the requestor of a Leasequery MUST NOT depend on one IP address and the requestor of a Leasequery MUST NOT depend on one
certain state always following a particular previous state. In certain state always following a particular previous state. While a
general, every state can (at times) follow every other state. state transition diagram can be drawn, it would be fully connected
and therefore conveys no useful information. Every state can (at
times) follow every other state.
6.2.8. data-source 6.2.8. data-source
The data-source option contains information about the source of the The data-source option contains information about the source of the
data in a DHCPLEASEACTIVE or a DHCPLEASEUNASSIGNED message. It data in a DHCPLEASEACTIVE or a DHCPLEASEUNASSIGNED message. It
SHOULD be used when there are two or more servers who might have SHOULD be used when there are two or more servers who might have
information about a particular IP address binding. Frequently two information about a particular IP address binding. Frequently two
servers work together to provide an increased availability solution servers work together to provide an increased availability solution
for the DHCPv4 service, and in these cases, both servers will respond for the DHCPv4 service, and in these cases, both servers will respond
to Bulk Leasequery requests for the same IP address. When one server to Bulk Leasequery requests for the same IP address. When one server
skipping to change at page 18, line 19 skipping to change at page 18, line 19
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TBD7 The option code. TBD7 The option code.
Length The option length, 1 octet. Length The option length, 1 octet.
Flags The Source information for this message. Flags The Source information for this message.
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| MBZ |R| | UNA |R|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
R: REMOTE flag R: REMOTE flag
remote = 1 remote = 1
local = 0 local = 0
MBZ: MUST BE ZERO (reserved for future use) UNA: UNASSIGNED
The REMOTE flag is used to indicate where the most recent change of The REMOTE flag is used to indicate where the most recent change of
state (or other interesting change) concerning this IPv4 address took state (or other interesting change) concerning this IPv4 address took
place. If the value is local, then the change took place on the place. If the value is local, then the change took place on the
server from which this message was transmitted. If the value is server from which this message was transmitted. If the value is
remote, then the change took place on some other server, and was made remote, then the change took place on some other server, and was made
known to the server from which this message was transmitted. known to the server from which this message was transmitted.
If this option was requested and it doesn't appear, the requestor If this option was requested and it doesn't appear, the requestor
MUST consider that the data-source was local. MUST consider that the data-source was local.
Unassigned bits MUST be ignored.
6.2.9. Virtual Subnet Selection Type and Information 6.2.9. Virtual Subnet Selection Type and Information
All of the (sub)options defined in [VpnId] carry identical payloads, All of the (sub)options defined in [RFC6607] carry identical
consisting of a type and additional VSS (Virtual Subnet Selection) payloads, consisting of a type and additional VSS (Virtual Subnet
information. The existing table is extended (see below) with a new Selection) information. The existing table is extended (see below)
type 254 to allow specification of a type code which indicates that with a new type 254 to allow specification of a type code which
all VPN's are to be used to process the Bulk Leasequery. indicates that all VPN's are to be used to process the Bulk
Leasequery.
Type VSS Information format: Type VSS Information Format
---- ----------------------- ----------------------------------------------------------
0 UTF-8 ASCII VPN identifier 0 Network Virtual Terminal (NVT) ASCII VPN identifier
1 RFC 2685 VPN-ID 1 RFC 2685 VPN-ID
CHANGED -> 2-253 Not Allowed CHANGED -> 2-253 Unassigned
NEW -> 254 All VPN's (wildcard) NEW -> 254 All VPN's (wildcard)
255 Global, default VPN 255 Global, default VPN
6.3. Connection and Transmission Parameters 6.3. Connection and Transmission Parameters
DHCPv4 servers that support Bulk Leasequery SHOULD listen for DHCPv4 servers that support Bulk Leasequery SHOULD listen for
incoming TCP connections on the DHCPv4 server port 67. incoming TCP connections on the DHCPv4 server port 67.
Implementations MAY offer to make the incoming port configurable, but Implementations MAY offer to make the incoming port configurable, but
port 67 MUST be the default. Requestors SHOULD make TCP connections port 67 MUST be the default. Requestors SHOULD make TCP connections
to port 67, and MAY offer to make the destination server port to port 67, and MAY offer to make the destination server port
configurable. configurable.
skipping to change at page 21, line 44 skipping to change at page 21, line 44
o Query End Time o Query End Time
Inclusion of a query-end-time option specifies that only IP address Inclusion of a query-end-time option specifies that only IP address
bindings which have changed on or before the time specified in the bindings which have changed on or before the time specified in the
query-end-time option should be returned. query-end-time option should be returned.
o VPN Id o VPN Id
If no vpn-id option appears in the DHCPBULKLEASEQUERY, the default If no vpn-id option appears in the DHCPBULKLEASEQUERY, the default
(global) VPN is searched to satisfy the query specified by the (global) VPN is searched to satisfy the query specified by the
DHCPBULKLEASEQUERY. Using the vpn-id option [VpnId] allows the DHCPBULKLEASEQUERY. Using the vpn-id option [RFC6607] allows the
requestor to specify a single VPN other than the default VPN. In requestor to specify a single VPN other than the default VPN. In
addition, the vpn-id option has been extended as part of this addition, the vpn-id option has been extended as part of this
document to allow specification that all configured VPN's be document to allow specification that all configured VPN's be
searched in order to satisfy the query specified in the searched in order to satisfy the query specified in the
DHCPBULKLEASEQUERY. DHCPBULKLEASEQUERY.
In all cases, any message returned from a DHCPBULKLEASEQUERY In all cases, any message returned from a DHCPBULKLEASEQUERY
request containing information about an IP address for other than request containing information about an IP address for other than
the default (global) VPN MUST contain a vpn-id option in the the default (global) VPN MUST contain a vpn-id option in the
message. message.
Use of the query-start-time or the query-end-time options or both can Use of the query-start-time or the query-end-time options or both can
serve to reduce the amount of data transferred over the TCP serve to reduce the amount of data transferred over the TCP
connection by a considerable amount. connection by a considerable amount. Note that the times specified
in the query-start-time or query-end-time options are absolute times,
not durations offset from "now".
The TCP connection may become blocked or stop being writable while The TCP connection may become blocked or stop being writable while
the requestor is sending its query. Should this happen, the the requestor is sending its query. Should this happen, the
implementation's behavior is controlled by the current value of implementation's behavior is controlled by the current value of
BULK_LQ_DATA_TIMEOUT. The default value is given elsewhere in this BULK_LQ_DATA_TIMEOUT. The default value is given elsewhere in this
document, and this value may be overridden by local configuration of document, and this value may be overridden by local configuration of
the operator. the operator.
If this situation is detected, the requestor SHOULD start a timer If this situation is detected, the requestor SHOULD start a timer
using the current value of BULK_LQ_DATA_TIMEOUT. If that timer using the current value of BULK_LQ_DATA_TIMEOUT. If that timer
expires, the requestor SHOULD terminate the connection. expires, the requestor SHOULD terminate the connection. This timer
is completely independent of any TCP timeout established by the TCP
protocol connection.
7.3. Processing Bulk Replies 7.3. Processing Bulk Replies
The requestor attempts to read a DHCPv4 Leasequery reply message from The requestor attempts to read a DHCPv4 Leasequery reply message from
the TCP connection. the TCP connection.
The TCP connection may stop delivering reply data (i.e., the The TCP connection may stop delivering reply data (i.e., the
connection stops being readable). Should this happen, the connection stops being readable). Should this happen, the
implementation's behavior is controlled by the current value of implementation's behavior is controlled by the current value of
BULK_LQ_DATA_TIMEOUT. The default value is given elsewhere in this BULK_LQ_DATA_TIMEOUT. The default value is given elsewhere in this
skipping to change at page 22, line 46 skipping to change at page 22, line 50
using the current value of BULK_LQ_DATA_TIMEOUT. If that timer using the current value of BULK_LQ_DATA_TIMEOUT. If that timer
expires, the requestor SHOULD terminate the connection. expires, the requestor SHOULD terminate the connection.
A single Bulk Leasequery can and usually will result in a large A single Bulk Leasequery can and usually will result in a large
number of replies. The requestor MUST be prepared to receive more number of replies. The requestor MUST be prepared to receive more
than one reply with an xid matching a single DHCPBULKLEASEQUERY than one reply with an xid matching a single DHCPBULKLEASEQUERY
message from a single DHCPv4 server. If the xid in the received message from a single DHCPv4 server. If the xid in the received
message does not match an outstanding DHCPBULKLEASEQUERY message, the message does not match an outstanding DHCPBULKLEASEQUERY message, the
requestor MUST close the TCP connection. requestor MUST close the TCP connection.
If the requestor receives more data than it can process, it can
simply abort the connection and try again with a more specific
request. It can also simply read the TCP connection more slowly, and
match the rate at which it can digest the information returned in the
Bulk Leasequery packets with the rate at which it reads those packets
from the TCP connection.
The DHCPv4 server MUST send a server-identifier option (option 54) in The DHCPv4 server MUST send a server-identifier option (option 54) in
the first response to any DHCPBULKLEASEQUERY message. The DHCPv4 the first response to any DHCPBULKLEASEQUERY message. The DHCPv4
server SHOULD NOT send server identifier options in subsequent server SHOULD NOT send server identifier options in subsequent
responses to that DHCPBULKLEASEQUERY message. The requestor MUST responses to that DHCPBULKLEASEQUERY message. The requestor MUST
cache the server-identifier option from the first response and apply cache the server-identifier option from the first response and apply
it to any subsequent responses. it to any subsequent responses.
The response messages generated by a DHCPBULKLEASEQUERY request are: The response messages generated by a DHCPBULKLEASEQUERY request are:
o DHCPLEASEACTIVE o DHCPLEASEACTIVE
skipping to change at page 24, line 47 skipping to change at page 25, line 11
DHCPv4 server. As such, it is an ideal time to save and use as input DHCPv4 server. As such, it is an ideal time to save and use as input
to a DHCPBULKLEASEQUERY in the query-start-time or query-end-time to a DHCPBULKLEASEQUERY in the query-start-time or query-end-time
options, should the requestor need to ever issue a DHCPBULKLEASEQUERY options, should the requestor need to ever issue a DHCPBULKLEASEQUERY
message using those options as part of a later query, since those message using those options as part of a later query, since those
options require a time in the context of the DHCPv4 server. options require a time in the context of the DHCPv4 server.
In addition to saving the base-time for possible future use in a In addition to saving the base-time for possible future use in a
query-start-time or query-end-time option, the base-time is used as query-start-time or query-end-time option, the base-time is used as
part of the conversion of the other times in the Leasequery message part of the conversion of the other times in the Leasequery message
to values which are meaningful in the context of the requestor. to values which are meaningful in the context of the requestor.
These other time values are specified as a offset (duration) from the
base-time value and not as an absolute time.
In systems whose clocks are synchronized, perhaps using NTP, the In systems whose clocks are synchronized, perhaps using NTP, the
clock skew will usually be zero, which is not only acceptable, but clock skew will usually be zero.
desired.
7.5. Querying Multiple Servers 7.5. Querying Multiple Servers
A Bulk Leasequery requestor MAY be configured to attempt to connect A Bulk Leasequery requestor MAY be configured to attempt to connect
to and query from multiple DHCPv4 servers in parallel. The DHCPv4 to and query from multiple DHCPv4 servers in parallel. The DHCPv4
Leasequery specification [RFC4388] includes a discussion about Leasequery specification [RFC4388] includes a discussion about
reconciling binding data received from multiple DHCPv4 servers. reconciling binding data received from multiple DHCPv4 servers.
In addition, the algorithm in Section 7.6 should be used. In addition, the algorithm in Section 7.6 should be used.
skipping to change at page 26, line 20 skipping to change at page 26, line 33
to recover binding information. A requestor MAY use a single to recover binding information. A requestor MAY use a single
connection to issue multiple queries to a server willing to support connection to issue multiple queries to a server willing to support
them. Each query MUST have a unique xid. them. Each query MUST have a unique xid.
A server SHOULD allow configuration of the number of queries that can A server SHOULD allow configuration of the number of queries that can
be processed simultaneously over a single connection. A server be processed simultaneously over a single connection. A server
SHOULD read the number of queries it is configured to process SHOULD read the number of queries it is configured to process
simultaneously and only read any subsequent queries as current simultaneously and only read any subsequent queries as current
queries are processed. queries are processed.
A server that is processing multiple queries simultaneously MUST A server that is processing multiple queries simultaneously MUST NOT
interleave replies to the multiple queries within the stream of reply block sending replies on new queries until all replies for the
messages it sends. Requestors need to be aware that replies for existing query are complete. Requestors need to be aware that
multiple queries may be interleaved within the stream of reply replies for multiple queries may be interleaved within the stream of
messages. Requestors that are not able to process interleaved reply messages. Requestors that are not able to process interleaved
replies (based on xid) MUST NOT send more than one query over a replies (based on xid) MUST NOT send more than one query over a
single connection prior to the completion of the previous query. single connection prior to the completion of the previous query.
Requestors should be aware that servers are not required to process Requestors should be aware that servers are not required to process
more than one query over a connection at a time (the limiting case more than one query over a connection at a time (the limiting case
for the configuration described above), and that servers are likely for the configuration described above), and that servers are likely
to limit the rate at which they process queries from any one to limit the rate at which they process queries from any one
requestor. requestor.
7.7.1. Example 7.7.1. Example
skipping to change at page 27, line 29 skipping to change at page 27, line 37
<----- DHCPLEASEACTIVE xid 4 <----- DHCPLEASEACTIVE xid 4
<----- DHCPLEASEUNASSIGNED xid 3 <----- DHCPLEASEUNASSIGNED xid 3
<----- DHCPLEASEACTIVE xid 4 <----- DHCPLEASEACTIVE xid 4
<----- DHCPLEASEACTIVE xid 3 <----- DHCPLEASEACTIVE xid 3
<----- DHCPLEASEQUERYDONE xid 3 <----- DHCPLEASEQUERYDONE xid 3
<----- DHCPLEASEACTIVE xid 4 <----- DHCPLEASEACTIVE xid 4
<----- DHCPLEASEQUERYDONE xid 4 <----- DHCPLEASEQUERYDONE xid 4
7.8. Closing Connections 7.8. Closing Connections
The requestor SHOULD close the connection after the If a requestor as no additional queries to send, or doesn't know if
DHCPLEASEQUERYDONE message is received for the last outstanding query it has additional queries to send or not, then it SHOULD close the
that it has sent, if it has no more queries to send. connection after receiving the DHCPLEASEQUERYDONE message for the
last outstanding query that it has sent.
The requestor SHOULD close connections in a graceful manner and not
an abort. The requestor SHOULD NOT assume that the manner in which
the DHCP server closed a connection carries any special meaning.
Typically, the requestor is the entity which will close the
connection, as servers will often wait with an open connection in
case the requestor has additional queries.
If a server closes a connection with an exception condition, the
requestor SHOULD consider as valid any completely received
intermediate results, and the requestor MAY retry the Bulk Leasequery
operation.
8. Server Behavior 8. Server Behavior
8.1. Accepting Connections 8.1. Accepting Connections
Servers that implement DHCPv4 Bulk Leasequery listen for incoming TCP Servers that implement DHCPv4 Bulk Leasequery listen for incoming TCP
connections. Port numbers are discussed in Section 6.3. Servers connections. Port numbers are discussed in Section 6.3. Servers
MUST be able to limit the number of concurrently accepted and active MUST be able to limit the number of concurrently accepted and active
connections. The value BULK_LQ_MAX_CONNS SHOULD be the default; connections. The value BULK_LQ_MAX_CONNS SHOULD be the default;
implementations MAY permit the value to be configurable. Connections implementations MAY permit the value to be configurable. Connections
skipping to change at page 30, line 39 skipping to change at page 31, line 14
o Query End Time o Query End Time
If a query-end-time option appears in the DHCPBULKLEASEQUERY If a query-end-time option appears in the DHCPBULKLEASEQUERY
request, only IP address bindings that have changed on or before request, only IP address bindings that have changed on or before
the time specified in the query-end-time option should be returned. the time specified in the query-end-time option should be returned.
o VPN Id o VPN Id
If no vpn-id option appears in the DHCPBULKLEASEQUERY, the default If no vpn-id option appears in the DHCPBULKLEASEQUERY, the default
(global) VPN is used to satisfy the query. A vpn-id option [VpnId] (global) VPN is used to satisfy the query. A vpn-id option
value other than the wildcard value (254) allows the requestor to [RFC6607] value other than the wildcard value (254) allows the
specify a single VPN other than the default VPN. In addition, the requestor to specify a single VPN other than the default VPN. In
vpn-id option has been extended as part of this document to allow addition, the vpn-id option has been extended as part of this
specification of a type 254 which indicates that all configured document to allow specification of a type 254 which indicates that
VPN's be searched in order to satisfy the primary query. all configured VPN's be searched in order to satisfy the primary
query.
In all cases, if the information returned in a DHCPLEASEACTIVE or In all cases, if the information returned in a DHCPLEASEACTIVE or
DHCPLEASEUNASSIGNED message is for a VPN other than the default DHCPLEASEUNASSIGNED message is for a VPN other than the default
(global) VPN, a vpn-id option MUST appear in the packet. (global) VPN, a vpn-id option MUST appear in the packet.
The query-start-time and query-end-time qualifiers are used to The query-start-time and query-end-time qualifiers are used to
constrain the amount of data returned by a Bulk Leasequery request by constrain the amount of data returned by a Bulk Leasequery request by
returning only IP addresses whose address bindings have changed in returning only IP addresses whose address bindings have changed in
some way during the time window specified by the query-start-time and some way during the time window specified by the query-start-time and
query-end-time. query-end-time.
skipping to change at page 33, line 15 skipping to change at page 33, line 38
process simultaneously. process simultaneously.
This SHOULD be a feature that is administratively controlled. This SHOULD be a feature that is administratively controlled.
Servers SHOULD offer configuration that limits the number of Servers SHOULD offer configuration that limits the number of
simultaneous queries permitted from any one requestor, in order to simultaneous queries permitted from any one requestor, in order to
control resource use if there are multiple requestors seeking control resource use if there are multiple requestors seeking
service. service.
8.5. Closing Connections 8.5. Closing Connections
The DHCPv4 server SHOULD start a timer for BULK_LQ_DATA_TIMEOUT The DHCPv4 server SHOULD close connections in a graceful manner and
not abort the connection. The DHCPv4 server SHOULD NOT assume that
the manner in which the requestor closed a connection carries any
special meaning.
Typically, the DHCPv4 server will only close the connection after
some form of an exception or a timeout on the connection.
Using a timer to detect when a connection is idle, and then closing
that connection is designed to protect the DHCPv4 server from
consuming unnecessary resources.
The DHCPv4 server should start a timer for BULK_LQ_DATA_TIMEOUT
seconds for a particular connection after it sends a seconds for a particular connection after it sends a
DHCPLEASEQUERYDONE message over that connection and if there is no DHCPLEASEQUERYDONE message over that connection and if there is no
current query outstanding for that connection. It should clear this current query outstanding for that connection. It should restart
timer if a query arrives over that connection. If the timer expires, this timer if a query arrives over that connection. If the timer
the DHCPv4 server should close the connection. expires, the DHCPv4 server should close the connection.
The server MUST close its end of the TCP connection if it encounters The server MUST close its end of the TCP connection if it encounters
an error sending data on the connection. The server MUST close its an error sending data on the connection. The server MUST close its
end of the TCP connection if it finds that it has to abort an in- end of the TCP connection if it finds that it has to abort an in-
process request. A server aborting an in-process request SHOULD process request. A server aborting an in-process request SHOULD
attempt to signal that to its requestors by using the QueryTerminated attempt to signal that to its requestors by using the QueryTerminated
status code in the status-code option in a DHCPLEASEQUERYDONE status code in the status-code option in a DHCPLEASEQUERYDONE
message, including a message string indicating details of the reason message, including a message string indicating details of the reason
for the abort. If the server detects that the requesting end of the for the abort. If the connection is closed for any reason, all of
connection has been closed, the server MUST close its end of the the data flows associated with any currently outstanding
connection. DHCPBULKLEASEQUERY messages will be terminated.
If the server detects that the requesting end of the connection has
been closed, the server MUST close its end of the connection.
9. Security Considerations 9. Security Considerations
The "Security Considerations" section of [RFC2131] details the The "Security Considerations" section of [RFC2131] details the
general threats to DHCPv4. The DHCPv4 Leasequery specification general threats to DHCPv4. The DHCPv4 Leasequery specification
[RFC4388] describes recommendations for the Leasequery protocol, [RFC4388] describes recommendations for the Leasequery protocol,
especially with regard to authentication of LEASEQUERY messages, especially with regard to authentication of LEASEQUERY messages,
mitigation of packet-flooding DOS attacks, and restriction to trusted mitigation of packet-flooding DOS attacks, and restriction to trusted
requestors. requestors.
skipping to change at page 35, line 44 skipping to change at page 36, line 33
----- -----
1 AVAILABLE 1 AVAILABLE
2 ACTIVE 2 ACTIVE
3 EXPIRED 3 EXPIRED
4 RELEASED 4 RELEASED
5 ABANDONED 5 ABANDONED
6 RESET 6 RESET
7 REMOTE 7 REMOTE
8 TRANSITIONING 8 TRANSITIONING
New values for this name space may only be defined by IETF Consensus, New values for this name space may only be defined by IETF Review, as
as described in [RFC5226]. Basically, this means that they are described in [RFC5226].
defined by RFCs approved by the IESG.
IANA is requested to create a new registry on the same assignments IANA is requested to create a new registry on the same assignments
page, titled "DHCP Status Code TBD1 Values" (where TBD1 corresponds page, titled "DHCP Status Code TBD1 Values" (where TBD1 corresponds
to the assigned value of the status-code option, above). This to the assigned value of the status-code option, above). This
registry will have the following initial values: registry will have the following initial values:
Name status-code Name status-code
---- ----------- ---- -----------
Success 000 Success 000
UnspecFail 001 UnspecFail 001
QueryTerminated 002 QueryTerminated 002
MalformedQuery 003 MalformedQuery 003
NotAllowed 004 NotAllowed 004
New values for this name space may only be defined by IETF Consensus, New values for this name space may only be defined by IETF Review, as
as described in [RFC5226]. Basically, this means that they are described in [RFC5226].
defined by RFCs approved by the IESG.
IANA is requested to revise the registry that will be created on the
same assignments page when the [VpnId] option is approved. The
registry will be "Virtual Subnet Selection Type and Information". It
should be revised to appear as follows:
Type VSS Information format: IANA is requested to revise the registry "VSS Type Options" created
by [RFC6607] in the overall area "Dynamic Host Configuration Protocol
(DHCP) and Bootstrap Protocol (BOOTP) Parameters". It should be
revised to appear as follows. Note that the number range for
"Unassigned" has changed as well as the new line for "All VPN's
(wildcard)" which was added.
0 UTF-8 ASCII VPN identifier Type VSS Information Format
1 RFC2685 VPN-ID ------------------------------------------------------------
2-253 Not Allowed 0 Network Virtual Terminal (NVT) ASCII VPN identifier
254 All VPN's. (wildcard; only allowed in 1 RFC 2685 VPN-ID
DHCPBULKLEASEQUERY messages) 2-253 Unassigned
255 Global, default VPN. 254 All VPN's (wildcard)
255 Global, default VPN
11. Contributing Authors 11. Contributing Authors
The following authors were full participants in creating this The following authors were full participants in creating this
document. In order to facilitate the process of approval for this document. In order to facilitate the process of approval for this
work, they graciously volunteered to have their names appear in this work, they graciously volunteered to have their names appear in this
section instead of on the title page. section instead of on the title page.
Pavan Kurapati Pavan Kurapati
Juniper Networks Ltd. Juniper Networks Ltd.
skipping to change at page 37, line 30 skipping to change at page 38, line 19
leasequery-00.txt. Both documents acknowledged that significant text leasequery-00.txt. Both documents acknowledged that significant text
as well as important ideas were borrowed in whole or in part from the as well as important ideas were borrowed in whole or in part from the
DHCPv6 Bulk Leasequery RFC, [RFC5460] written by Mark Stapp. Further DHCPv6 Bulk Leasequery RFC, [RFC5460] written by Mark Stapp. Further
suggestions and improvements were made by participants in the DHC suggestions and improvements were made by participants in the DHC
working group, including Alfred Hoenes. working group, including Alfred Hoenes.
13. References 13. References
13.1. Normative References 13.1. Normative References
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets", RFC 1918,
February 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997. Requirement Levels", RFC 2119, March 1997.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997. March 1997.
[RFC2132] Alexander, S., Droms, R., "DHCP Options and BOOTP Vendor [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997. Extensions", RFC 2132, March 1997.
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC
3046, January 2001. 3046, January 2001.
[RFC3118] Droms, R. "Authentication for DHCP Messages", RFC 3118, [RFC3118] Droms, R. "Authentication for DHCP Messages", RFC 3118,
June 2001. June 2001.
[RFC4388] Woundy, R., K. Kinnear, "Dynamic Host Configuration [RFC4388] Woundy, R. and K. Kinnear, "Dynamic Host Configuration
Protocol (DHCP) Leasequery", RFC 4388, February 2006. Protocol (DHCP) Leasequery", RFC 4388, February 2006.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RelayId] Joshi, B., Rao, D. and M. Stapp, "The DHCPv4 Relay Agent [RelayId] Joshi, B., Rao, D., and M. Stapp, "The DHCPv4 Relay Agent
Identifier Suboption", draft-ietf-dhc-relay-id-suboption-10.txt, Identifier Suboption", draft-ietf-dhc-relay-id-suboption-11.txt,
(work in progress) January 2012. (work in progress) July 2012.
[VpnId] Kinnear, K., R. Johnson, M. Stapp and J. Kumarasamy, "Virtual [RFC6607] Kinnear, K., Johnson, R., and M. Stapp, "Virtual Subnet
Subnet Selection Options for DHCPv4 and DHCPv6" draft-ietf-dhc- Selection Options for DHCPv4 and DHCPv6", RFC 6607, April 2012.
vpn-option-15.txt, (work in progress) January 2012.
13.2. Informative References 13.2. Informative References
[RFC951] Croft, B., Gilmore, J., "Bootstrap Protocol (BOOTP)", RFC [RFC951] Croft, B. and J. Gilmore, "Bootstrap Protocol (BOOTP)", RFC
951, September 1985. 951, September 1985.
[RFC1542] Wimer, W., "Clarifications and Extensions for the Bootstrap [RFC1542] Wimer, W., "Clarifications and Extensions for the Bootstrap
Protocol", RFC 1542, October 1993. Protocol", RFC 1542, October 1993.
[RFC4614] Duke, M., R. Braden, W. Eddy, and E. Blanton, "A Roadmap [RFC4614] Duke, M., Braden, R., Eddy, W., and E. Blanton, "A Roadmap
for Transmission Control Protocol (TCP) Specification Documents", for Transmission Control Protocol (TCP) Specification Documents",
RFC 4614, September 2006. RFC 4614, September 2006.
[RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460, February [RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460, February
2009. 2009.
Authors' Addresses Authors' Addresses
Kim Kinnear Kim Kinnear
Cisco Systems Cisco Systems
 End of changes. 55 change blocks. 
122 lines changed or deleted 191 lines changed or added

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