pref_lifetime INT UNSIGNED, # Preferred lifetime
lease_type TINYINT, # Lease type (see lease6_types
# table for possible values)
- iaid INT UNSIGNED, # See Section 10 of RFC 3315
+ iaid INT UNSIGNED, # See Section 12 of RFC 8415
prefix_len TINYINT UNSIGNED, # For IA_PD only
fqdn_fwd BOOL, # Has forward DNS update been performed by a server
fqdn_rev BOOL, # Has reverse DNS update been performed by a server
pref_lifetime BIGINT, -- Preferred lifetime
lease_type SMALLINT, -- Lease type (see lease6_types
-- table for possible values)
- iaid INT, -- See Section 10 of RFC 3315
+ iaid INT, -- See Section 12 of RFC 8415
prefix_len SMALLINT, -- For IA_PD only
fqdn_fwd BOOLEAN, -- Has forward DNS update been performed by a server
fqdn_rev BOOLEAN, -- Has reverse DNS update been performed by a server
For each incoming packet, @ref isc::dhcp::Dhcpv6Srv::classifyPacket() method is
called. It attempts to extract content of the vendor class option and interprets
-as a name of the class. Although the RFC3315 says that the vendor class may
+as a name of the class. Although the RFC 8415 says that the vendor class may
contain more than one chunk of data, the existing code handles only one data
block, because that is what actual devices use. For now, the code has been
tested with two classes used in cable modem networks: eRouter1.0 and docsis3.0,
bool
Dhcpv6Srv::testServerID(const Pkt6Ptr& pkt) {
/// @todo Currently we always check server identifier regardless if
- /// it is allowed in the received message or not (per RFC3315).
+ /// it is allowed in the received message or not (per RFC 8415).
/// If the server identifier is not allowed in the message, the
/// sanityCheck function should deal with it.
OptionPtr server_id = pkt->getOption(D6O_SERVERID);
// information about client's leases from lease database. We treat this
// as no binding for the client.
if (!subnet) {
- // Per RFC3633, section 12.2, if there is no binding and we are
+ // Per RFC 8415, section 18.3.4, if there is no binding and we are
// processing a Renew, the NoBinding status code should be returned.
if (query->getType() == DHCPV6_RENEW) {
// Insert status code NoBinding
" for this duid/iaid."));
return (ia_rsp);
- // Per RFC3633, section 12.2, if there is no binding and we are
+ // Per RFC 8415, section 18.3.5, if there is no binding and we are
// processing Rebind, the message has to be discarded (assuming that
// the server doesn't know if the prefix in the IA_PD option is
// appropriate for the client's link). The exception being thrown
// be discarded.
} else {
- /// @todo: RFC3315bis will probably change that behavior. Client
- /// may rebind prefixes and addresses at the same time.
+ /// @todo: We may consider in which cases we could determine
+ /// whether the delegated prefixes are appropriate for the
+ /// link to which the client's interface is attached. Just not
+ /// being able to select the subnet may not be enough, because
+ /// there might be other DHCP servers around that are configured
+ /// to handle that subnet. Therefore we don't fully follow all
+ /// the paths in section 18.3.5 of RFC 8415 to respond with
+ /// zero lifetimes for the prefixes being rebound.
isc_throw(DHCPv6DiscardMessageError, "no subnet found for the"
" client sending Rebind to extend lifetime of the"
" prefix (DUID=" << duid->toText() << ", IAID="
Dhcpv6Srv::releaseLeases(const Pkt6Ptr& release, Pkt6Ptr& reply,
AllocEngine::ClientContext6& ctx) {
- // We need to release addresses for all IA_NA options in the client's
+ // We need to release addresses for all IA options in the client's
// RELEASE message.
- // @todo Add support for IA_TA
- // @todo Add support for IA_PD
- // @todo Consider supporting more than one address in a single IA_NA.
- // That was envisaged by RFC3315, but it never happened. The only
- // software that supports that is Dibbler, but its author seriously doubts
- // if anyone is really using it. Clients that want more than one address
- // just include more instances of IA_NA options.
+
+ /// @todo Add support for IA_TA
+ /// @todo Consider supporting more than one address in a single IA.
+ /// It is allowed by RFC 8415, but it is not widely implemented. The only
+ /// software that supports that is Dibbler, but its author seriously doubts
+ /// if anyone is really using it. Clients that want more than one address
+ /// or prefix just include more instances of IA options.
// Let's set the status to be success by default. We can override it with
// error status if needed. The important thing to understand here is that
}
}
- // To be pedantic, we should also include status code in the top-level
- // scope, not just in each IA_NA. See RFC3315, section 18.2.6.
- // This behavior will likely go away in RFC3315bis.
+ // Include top-level status code as well.
reply->addOption(createStatusCode(*release, general_status,
"Summary status for all processed IA_NAs"));
}
LOG_INFO(lease6_logger, DHCP6_DECLINE_FAIL_NO_LEASE)
.arg(decline->getLabel()).arg(decline_addr->getAddress().toText());
- // RFC3315, section 18.2.7: "For each IA in the Decline message for
- // which the server has no binding information, the server adds an
- // IA option using the IAID from the Release message and includes
- // a Status Code option with the value NoBinding in the IA option.
+ // According to RFC 8415, section 18.3.8:
+ // "For each IA in the Decline message for which the server has no
+ // binding information, the server adds an IA option using the IAID
+ // from the Decline message and includes a Status Code option with
+ // the value NoBinding in the IA option".
setStatusCode(ia_rsp, createStatusCode(*decline, *ia_rsp, STATUS_NoBinding,
"Server does not know about such an address."));
- // RFC3315, section 18.2.7: The server ignores addresses not
- // assigned to the IA (though it may choose to log an error if it
- // finds such an address).
+ // In the same section of RFC 8415:
+ // "The server ignores addresses not assigned to the IAs (though it may"
+ // choose to log an error if it finds such addresses)."
continue; // There may be other addresses.
}
/// @brief Check if the message can be sent to unicast.
///
- /// This function checks if the received message conforms to the section 15
- /// of RFC3315 which says that: "A server MUST discard any Solicit, Confirm,
- /// Rebind or Information-request messages it receives with a unicast
+ /// This function checks if the received message conforms to the section 16
+ /// of RFC 8415 which says that: "A server MUST discard any Solicit, Confirm,
+ /// Rebind or Information-request messages it receives with a Layer 3 unicast
/// destination address.
///
/// @param pkt DHCPv6 message to be checked.
/// @brief Processes incoming Confirm message and returns Reply.
///
/// This function processes Confirm message from the client according
- /// to section 18.2.2. of RFC3315. It discards the Confirm message if
+ /// to section 18.3.3. of RFC 8415. It discards the Confirm message if
/// the message sent by the client contains no addresses, i.e. it has
/// no IA_NA options or all IA_NA options contain no IAAddr options.
///
/// lease is found, an IA_NA response is generated with an appropriate
/// status code.
///
- /// @todo The behavior of this function will need to be extended to support
- /// draft-ietf-dhc-dhcpv6-stateful-issues. This draft modifies the behavior
- /// described in RFC3315 with respect to Renew and Rebind processing. Key
- /// changes are (version -05):
- /// - Renewing and Rebinding client MAY request additional bindings by
- /// putting an IA for all bindings it desires but has been unable to obtain.
- /// Server MAY allocate addresses if it finds that they are appropriate for
- /// the link that client is attached to.
- /// - When receiving Rebind, if the server determines that the addresses are
- /// not appropriate for the link the client is attached to, the server MAY
- /// send the IA with address lifetimes set to 0 or discard the message.
- ///
/// @param query client's message (Renew or Rebind)
/// @param answer server's response to the client's message. This
/// message should contain Client FQDN option being sent by the server
/// lease is found, an IA_NA response is generated with an appropriate
/// status code.
///
- /// As RFC 3315 requires that a single status code be sent for the whole message,
- /// this method may update the passed general_status: it is set to SUCCESS when
+ /// The server sends top-level Status Code option. This method may update the
+ /// passed value of that option, i.e. general_status. It is set to SUCCESS when
/// message processing begins, but may be updated to some error code if the
/// release process fails.
///
// Test that directly connected client's Confirm message is processed and Reply
// message is sent back. In this test case, the client sends Confirm for two
// addresses that belong to the same IAID and are sent within the same IA_NA
-// option (RFC3315, section 18.2.2).
+// option (RFC 8415, section 18.3.3).
TEST_F(ConfirmTest, directClientSameIAID) {
Dhcp6Client client;
// Configure client to request IA_NA.
// Test that directly connected client's Confirm message is processed and Reply
// message is sent back. In this test case, the client sends Confirm for two
// addresses that belong to different IAIDs and are sent within the different
-// IA_NA options (RFC3315, section 18.2.2).
+// IA_NA options (RFC 8415, section 18.3.3).
TEST_F(ConfirmTest, directClientDifferentIAID) {
Dhcp6Client client;
// Configure client to request IA_NA.
// Test that relayed client's Confirm message is processed and Reply message
-// is sent back (RFC3315, section 18.2.2).
+// is sent back (RFC 8415, section 18.3.3).
TEST_F(ConfirmTest, relayedClient) {
Dhcp6Client client;
// Client to send relayed message.
}
// Test that the Confirm message without any addresses is discarded
-// (RFC3315, section 18.2.2).
+// (RFC 8415, section 18.3.3).
TEST_F(ConfirmTest, relayedClientNoAddress) {
Dhcp6Client client;
// Configure the server.
}
// This test checks that the server processes Confirm message correctly if
-// the subnet can't be selected for the client (RFC3315, section 18.2.2).
+// the subnet can't be selected for the client (RFC 8415, section 18.3.3).
TEST_F(ConfirmTest, relayedClientNoSubnet) {
Dhcp6Client client;
// Client to send relayed message.
}
// This test checks that the relayed Confirm message is processed by the server
-// when sent to unicast address RFC3315, section 18.2.8).
+// when sent to unicast address.
TEST_F(ConfirmTest, relayedUnicast) {
Dhcp6Client client;
// Client to send relayed message.
}
// This test checks that the Confirm message is discarded by the server if it
-// has been sent to unicast address (RFC3315, section 15).
+// has been sent to unicast address (RFC 8415, section 18.3.3).
TEST_F(ConfirmTest, unicast) {
Dhcp6Client client;
// Configure client to request IA_NA.
// No failure here. There's really no way for test LL DUID. It doesn't
// even make sense to check if that Link Layer is actually present on
- // a physical interface. RFC3315 says a server should write its DUID
+ // a physical interface. RFC 8415 says a server should write its DUID
// and keep it despite hardware changes.
break;
}
<< "server accepts message type "
<< static_cast<int>(not_allowed_unicast[i])
<< "being sent to unicast address; this message should"
- " be discarded according to section 15 of RFC3315";
+ " be discarded according to section 18.4 of RFC 8415";
}
// Explicitly list client/relay message types which are allowed to
// be sent to unicast.
checkIA_NAStatusCode(ia, STATUS_Success, 0, 0);
checkMsgStatusCode(reply, STATUS_Success);
- // There should be no address returned in RELEASE (see RFC3315, 18.2.6)
+ // There should be no address returned in RELEASE (see RFC 8415, 18.3.7)
// There should be no prefix
EXPECT_FALSE(tmp->getOption(D6O_IAADDR));
EXPECT_FALSE(tmp->getOption(D6O_IAPREFIX));
/// @todo Extend PD tests to cover same prefix by different length.
// This test checks that the Rebind message is discarded by the server if it
-// has been sent to unicast address (RFC3315, section 15).
+// has been sent to unicast address (RFC 8415, section 18.4).
TEST_F(RebindTest, unicast) {
Dhcp6Client client;
// Configure client to request IA_NA.
Lease6 lease_client = client.getLease(0);
// Set the unicast destination address for the Rebind message.
// The Rebind should be discarded when sent to unicast address,
- // according to section 15 of RFC3315.
+ // according to section 18.4 of RFC 8415.
client.setDestAddress(IOAddress("2001:db8:1::1"));
// Send the Rebind message to a unicast address.
ASSERT_NO_THROW(client.doRebind());
}
// Get server argument
- // NoteFF02::1:2 and FF02::1:3 are defined in RFC3315 as
+ // NoteFF02::1:2 and FF02::1:3 are defined in RFC 8415 as
// All_DHCP_Relay_Agents_and_Servers and All_DHCP_Servers
// addresses
check(optind < argc -1, "extra arguments?");
duid_template_[2] = HWTYPE_ETHERNET >> 8;
duid_template_[3] = HWTYPE_ETHERNET & 0xff;
- // As described in RFC3315: 'the time value is the time
+ // As described in RFC 8415: 'the time value is the time
// that the DUID is generated represented in seconds
// since midnight (UTC), January 1, 2000, modulo 2^32.'
ptime now = microsec_clock::universal_time();
EXPECT_TRUE(std::equal(new_duid.begin(), new_duid.begin() + 4,
duid_llt_and_hw));
- // As described in RFC3315: 'the time value is the time
+ // As described in RFC 8415: 'the time value is the time
// that the DUID is generated represented in seconds
// since midnight (UTC), January 1, 2000, modulo 2^32.'
uint32_t duid_time = 0;
/* DHCPv6 Option codes: */
enum DHCPv6OptionType {
- D6O_CLIENTID = 1, /* RFC3315 */
+ D6O_CLIENTID = 1, /* RFC 8415 */
D6O_SERVERID = 2,
D6O_IA_NA = 3,
D6O_IA_TA = 4,
};
/*
- * Status Codes, from RFC 3315 section 24.4, and RFC 3633, 5007, 5460.
+ * Status Codes, from RFC 8415 section 21.13, 5007, 5460.
*/
enum DHCPv6StatusCode {
STATUS_Success = 0,
};
/*
- * DHCPv6 message types, defined in section 5.3 of RFC 3315
+ * DHCPv6 message types, defined in section 7.3 of RFC 8415
*/
enum DHCPv6MessageType {
DHCPV6_SOLICIT = 1,
extern const char *dhcpv6_type_names[];
extern const int dhcpv6_type_name_max;
-// DUID type definitions (RFC3315 section 9).
+// DUID type definitions (RFC 8415 section 11).
// see isc::dhcp::DUID::DUIDType enum in dhcp/duid.h
// Define hardware types
static const uint16_t LQ_QUERY_OFFSET = 17;
/*
- * DHCPv6 well-known multicast addresses, from section 5.1 of RFC 3315
+ * DHCPv6 well-known multicast addresses, from section 7.1 of RFC 8415
*/
// TODO
#define ALL_DHCP_RELAY_AGENTS_AND_SERVERS "ff02::1:2"
static const uint16_t DHCP6_SERVER_PORT = 547;
/*
- * DHCPv6 Retransmission Constants (RFC3315 section 5.5, RFC 5007)
+ * DHCPv6 Retransmission Constants (RFC 8415 section 7.6, RFC 5007)
*/
// TODO
-// Copyright (C) 2012-2016 Internet Systems Consortium, Inc. ("ISC")
+// Copyright (C) 2012-2018 Internet Systems Consortium, Inc. ("ISC")
//
// This Source Code Form is subject to the terms of the Mozilla Public
// License, v. 2.0. If a copy of the MPL was not distributed with this
class DUID {
public:
/// @brief maximum duid size
- /// As defined in RFC3315, section 9.1
+ /// As defined in RFC 8415, section 11.1
static const size_t MAX_DUID_LEN = 128;
/// @brief minimum duid size
- /// There's no explicit minimal DUID size specified in RFC3315,
- /// so let's use absolute minimum
+ /// The minimal DUID size specified in RFC 8415 is 1.
static const size_t MIN_DUID_LEN = 1;
/// @brief specifies DUID type
typedef enum {
DUID_UNKNOWN = 0, ///< invalid/unknown type
- DUID_LLT = 1, ///< link-layer + time, see RFC3315, section 9.2
- DUID_EN = 2, ///< enterprise-id, see RFC3315, section 9.3
- DUID_LL = 3, ///< link-layer, see RFC3315, section 9.4
- DUID_UUID = 4, ///< UUID, see RFC6355
+ DUID_LLT = 1, ///< link-layer + time, see RFC3315, section 11.2
+ DUID_EN = 2, ///< enterprise-id, see RFC3315, section 11.3
+ DUID_LL = 3, ///< link-layer, see RFC3315, section 11.4
+ DUID_UUID = 4, ///< UUID, see RFC3315, section 11.5
DUID_MAX ///< not a real type, just maximum defined value + 1
} DUIDType;
-// Copyright (C) 2015 Internet Systems Consortium, Inc. ("ISC")
+// Copyright (C) 2015-2018 Internet Systems Consortium, Inc. ("ISC")
//
// This Source Code Form is subject to the terms of the Mozilla Public
// License, v. 2.0. If a copy of the MPL was not distributed with this
/// @brief Factory for generating DUIDs (DHCP Unique Identifiers).
///
-/// DHCPv6 clients and servers are identified by DUIDs (see RFC3315).
+/// DHCPv6 clients and servers are identified by DUIDs (see RFC 8415).
/// DUIDs are unique identifiers carried in the appropriate DHCP
-/// options. RFC3315 defines 3 types of DUIDs:
+/// options. RFC 8415 defines 4 types of DUIDs:
/// -# DUID-LLT
/// -# DUID-EN
/// -# DUID-LL
+/// -# DUID-UUID
///
/// of which the DUID-LLT is recommended for all general purpose computing
-/// devices. RFC6355 defines new DUID-UUID and any future specifications may
-/// define new DUID types. The current implementation of the class only
-/// supports DUID types defined in RFC3315.
+/// devices. Future specifications may define new DUID types. The current
+/// implementation of the class only supports DUID types defined in RFC 8415.
///
/// In most cases DUIDs can be generated automatically, i.e. no manual
/// configuration is required. For example, DUID-LLT is composed of the
/// @brief Packet reception buffer size
///
- /// RFC3315 states that server responses may be
+ /// RFC 8415 states that server responses may be
/// fragmented if they are over MTU. There is no
/// text whether client's packets may be larger
/// than 1500. For now, we can assume that
/// @brief This class represents Authentication (11) DHCPv6 option.
///
-/// For details, see draft-ietf-rfc3315bis-13, Section 21.11.
+/// For details, see RFC 8415 Section 21.11.
class Option6Auth: public Option {
public:
-// Copyright (C) 2015-2017 Internet Systems Consortium, Inc. ("ISC")
+// Copyright (C) 2015-2018 Internet Systems Consortium, Inc. ("ISC")
//
// This Source Code Form is subject to the terms of the Mozilla Public
// License, v. 2.0. If a copy of the MPL was not distributed with this
/// @brief Pointer to the @c isc::dhcp::Option6StatusCode.
typedef boost::shared_ptr<Option6StatusCode> Option6StatusCodePtr;
-/// @brief This class represents Status Code option (13) from RFC3315.
+/// @brief This class represents Status Code option (13) from RFC 8415.
class Option6StatusCode: public Option {
public:
/// @brief Constructor, used for options constructed (during transmission).
/// this is a single value the option type points to the data type of the
/// value. For example, DHCPv6 option 8 comprises a two-byte option code, a
/// two-byte option length and two-byte field that carries a uint16 value
-/// (RFC 3315 - http://ietf.org/rfc/rfc3315.txt). In such a case, the option
+/// (RFC 8415 - http://ietf.org/rfc/rfc8415.txt). In such a case, the option
/// type is defined as "uint16". Length and string tuples are a length
/// on one (DHCPv4) or two (DHCPv6) bytes followed by a string of
/// the given length.
///
/// Array types should be used when the option contains multiple contiguous
/// data values of the same type laid. For example, DHCPv6 option 6 includes
-/// multiple fields holding uint16 codes of requested DHCPv6 options (RFC 3315).
+/// multiple fields holding uint16 codes of requested DHCPv6 options (RFC 8415).
/// Such an option can be represented with this class by setting the option
/// type to "uint16" and the array indicator (array_type) to true. The number
/// of elements in the array is effectively unlimited (although it is actually
-// Copyright (C) 2012-2016 Internet Systems Consortium, Inc. ("ISC")
+// Copyright (C) 2012-2018 Internet Systems Consortium, Inc. ("ISC")
//
// This Source Code Form is subject to the terms of the Mozilla Public
// License, v. 2.0. If a copy of the MPL was not distributed with this
/// This class extends the base class with the support for enterprise numbers.
/// The enterprise numbers are assigned by IANA to various organizations
/// and they are carried as uint32_t integers in DHCPv6 Vendor Specific
-/// Information Options (VSIO). For more information refer to RFC3315.
+/// Information Options (VSIO). For more information refer to RFC 8415.
/// All option spaces that group VSIO options must have enterprise number
/// set. It can be set using a constructor or \ref setVendorSpace function.
/// The extra functionality of this class (enterprise numbers) allows to
-// Copyright (C) 2014-2017 Internet Systems Consortium, Inc. ("ISC")
+// Copyright (C) 2014-2018 Internet Systems Consortium, Inc. ("ISC")
//
// This Source Code Form is subject to the terms of the Mozilla Public
// License, v. 2.0. If a copy of the MPL was not distributed with this
/// @brief This class encapsulates DHCPv6 Vendor Class and DHCPv4 V-I Vendor
/// Class options.
///
-/// The format of DHCPv6 Vendor Class option (16) is described in section 22.16
-/// of RFC3315 and the format of the DHCPv4 V-I Vendor Class option (124) is
+/// The format of DHCPv6 Vendor Class option (16) is described in section 21.16
+/// of RFC 8415 and the format of the DHCPv4 V-I Vendor Class option (124) is
/// described in section 3 of RFC3925. Each of these options carries enterprise
/// id followed by the collection of tuples carrying opaque data. A single tuple
/// consists of the field holding opaque data length and the actual data.
///
/// For DHCPv6, The Vendor Class option mandates a 2-byte
/// OPTION_VENDOR_CLASS followed by a 2-byte option-len with a 4-byte
- /// enterprise-number. While section 22.16 of RFC3315 specifies that the
+ /// enterprise-number. While section 21.16 of RFC 8415 specifies that the
/// information contained within the data area can contain one or more
/// opaque fields, the inclusion of the vendor-class-data is not mandatory
/// and therefore not factored into the overall possible minimum length.
for (vector<RelayInfo>::iterator relay = relay_info_.begin();
relay != relay_info_.end(); ++relay) {
- // build relay-forw/relay-repl header (see RFC3315, section 7)
+ // build relay-forw/relay-repl header (see RFC 8415, section 9)
buffer_out_.writeUint8(relay->msg_type_);
buffer_out_.writeUint8(relay->hop_count_);
buffer_out_.writeData(&(relay->linkaddr_.toBytes()[0]),
/// The DHCPv6 server uses DHCPv6 Unique Identifier (DUID) to identify itself
/// to the clients. Typically, the server generates the DUID on the first
/// startup and writes it to the persistent storage so as it doesn't change
-/// across restarts of the server. RFC3315 and RFC6355 define different DUID
-/// types. Kea allows for selecting a type of DUID that the server should
-/// generate. It also allows for overriding entire default DUID or parts of
-/// it via configuration file. This class holds the DUID configuration
-/// specified in the server configuration file.
+/// across restarts of the server. RFC 8415 defines different DUID types.
+/// Kea allows for selecting a type of DUID that the server should generate.
+/// It also allows for overriding entire default DUID or parts of it via
+/// configuration file. This class holds the DUID configuration specified
+/// in the server configuration file.
class CfgDUID : public data::UserContext, public isc::data::CfgToElement {
public:
/// @brief key for authentication .
///
/// key is a 16 byte value to be used in the authentication field.
- /// Server replies will contain the below key in authentication field as specified in the RFC 3315bis.
- // While sending reconfigure message authentication field
- /// shall contain MD5 hash computed using this key.
+ /// Server replies will contain the below key in authentication field
+ /// as specified in the RFC 8415. While sending reconfigure message
+ /// authentication field shall contain MD5 hash computed using this key.
AuthKey key_;
};
pref_lifetime INT UNSIGNED, # Preferred lifetime
lease_type TINYINT, # Lease type (see lease6_types
# table for possible values)
- iaid INT UNSIGNED, # See Section 10 of RFC 3315
+ iaid INT UNSIGNED, # See Section 12 of RFC 8415
prefix_len TINYINT UNSIGNED, # For IA_PD only
fqdn_fwd BOOL, # Has forward DNS update been performed by a server
fqdn_rev BOOL, # Has reverse DNS update been performed by a server
pref_lifetime BIGINT, -- Preferred lifetime
lease_type SMALLINT, -- Lease type (see lease6_types
-- table for possible values)
- iaid INT, -- See Section 10 of RFC 3315
+ iaid INT, -- See Section 12 of RFC 8415
prefix_len SMALLINT, -- For IA_PD only
fqdn_fwd BOOLEAN, -- Has forward DNS update been performed by a server
fqdn_rev BOOLEAN, -- Has reverse DNS update been performed by a server
projects / thirdparty / kea.git / commitdiff
