draft-ietf-dhc-sedhcpv6-14.txt   draft-ietf-dhc-sedhcpv6-15.txt 
DHC Working Group S. Jiang DHC Working Group S. Jiang
Internet-Draft Huawei Technologies Co., Ltd Internet-Draft Huawei Technologies Co., Ltd
Intended status: Standards Track L. Li Intended status: Standards Track L. Li
Expires: April 11, 2017 Y. Cui Expires: April 19, 2017 Y. Cui
Tsinghua University Tsinghua University
T. Jinmei T. Jinmei
Infoblox Inc. Infoblox Inc.
T. Lemon T. Lemon
Nominum, Inc. Nominum, Inc.
D. Zhang D. Zhang
October 8, 2016 October 16, 2016
Secure DHCPv6 Secure DHCPv6
draft-ietf-dhc-sedhcpv6-14 draft-ietf-dhc-sedhcpv6-15
Abstract Abstract
DHCPv6 includes no deployable security mechanism that can protect DHCPv6 includes no deployable security mechanism that can protect
end-to-end communication between DHCP clients and servers. This memo end-to-end communication between DHCP clients and servers. This
describes a mechanism for using public key cryptography to provide document describes a mechanism for using public key cryptography to
such security. The mechanism provides encryption in all cases, and provide such security. The mechanism provides encryption in all
can be used for authentication based either on pre-sharing of cases, and can be used for authentication based on pre-sharing of
authorized certificates. authorized certificates.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted 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). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 11, 2017. This Internet-Draft will expire on April 19, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 39 skipping to change at page 2, line 39
8. Relay Agent Behavior . . . . . . . . . . . . . . . . . . . . 14 8. Relay Agent Behavior . . . . . . . . . . . . . . . . . . . . 14
9. Processing Rules . . . . . . . . . . . . . . . . . . . . . . 14 9. Processing Rules . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Increasing Number Check . . . . . . . . . . . . . . . . . 14 9.1. Increasing Number Check . . . . . . . . . . . . . . . . . 14
10. Extensions for Secure DHCPv6 . . . . . . . . . . . . . . . . 15 10. Extensions for Secure DHCPv6 . . . . . . . . . . . . . . . . 15
10.1. New DHCPv6 Options . . . . . . . . . . . . . . . . . . . 15 10.1. New DHCPv6 Options . . . . . . . . . . . . . . . . . . . 15
10.1.1. Certificate Option . . . . . . . . . . . . . . . . . 15 10.1.1. Certificate Option . . . . . . . . . . . . . . . . . 15
10.1.2. Signature option . . . . . . . . . . . . . . . . . . 16 10.1.2. Signature option . . . . . . . . . . . . . . . . . . 16
10.1.3. Increasing-number Option . . . . . . . . . . . . . . 18 10.1.3. Increasing-number Option . . . . . . . . . . . . . . 18
10.1.4. Encrypted-message Option . . . . . . . . . . . . . . 18 10.1.4. Encrypted-message Option . . . . . . . . . . . . . . 18
10.2. New DHCPv6 Messages . . . . . . . . . . . . . . . . . . 19 10.2. New DHCPv6 Messages . . . . . . . . . . . . . . . . . . 19
10.3. Status Codes . . . . . . . . . . . . . . . . . . . . . . 19 10.3. Status Codes . . . . . . . . . . . . . . . . . . . . . . 20
11. Security Considerations . . . . . . . . . . . . . . . . . . . 20 11. Security Considerations . . . . . . . . . . . . . . . . . . . 20
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
14. Change log [RFC Editor: Please remove] . . . . . . . . . . . 22 14. Change log [RFC Editor: Please remove] . . . . . . . . . . . 23
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
15.1. Normative References . . . . . . . . . . . . . . . . . . 24 15.1. Normative References . . . . . . . . . . . . . . . . . . 25
15.2. Informative References . . . . . . . . . . . . . . . . . 26 15.2. Informative References . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction 1. Introduction
The Dynamic Host Configuration Protocol for IPv6 (DHCPv6, [RFC3315]) The Dynamic Host Configuration Protocol for IPv6 (DHCPv6, [RFC3315])
allows DHCPv6 servers to flexibly provide addressing and other allows DHCPv6 servers to flexibly provide addressing and other
configuration information relating to local network infrastructure to configuration information relating to local network infrastructure to
DHCP clients. The protocol provides no deployable security DHCP clients. The protocol provides no deployable security
mechanism, and consequently is vulnerable to various attacks. mechanism, and consequently is vulnerable to various attacks.
This document provides a brief summary of the security This document provides a brief summary of the security
skipping to change at page 5, line 7 skipping to change at page 5, line 7
profile does not work in cases where the client wants to maintain profile does not work in cases where the client wants to maintain
anonymity from eavesdroppers but must identify itself to the DHCP anonymity from eavesdroppers but must identify itself to the DHCP
server with which it intends to communicate. server with which it intends to communicate.
Privacy consideration for DHCPv6 [RFC7824] presents an analysis of Privacy consideration for DHCPv6 [RFC7824] presents an analysis of
the privacy issues associated with the use of DHCPv6 by Internet the privacy issues associated with the use of DHCPv6 by Internet
users. No solutions are presented. users. No solutions are presented.
Current DHCPv6 messages are still transmitted in cleartext and the Current DHCPv6 messages are still transmitted in cleartext and the
privacy information within the DHCPv6 message is not protected from privacy information within the DHCPv6 message is not protected from
passive attack, such as pervasive monitoring [RFC7258]. passive attack, such as pervasive monitoring [RFC7258]. The privacy
information of the IPv6 host, such as DUID, may be gleaned to find
location information, previous visited networks and so on. [RFC7258]
claims that pervasive monitoring should be mitigated in the design of
IETF protocol, where possible.
To better address the problem of passive monitoring and to achieve To better address the problem of passive monitoring and to achieve
authentication without requiring a symmetric key distribution authentication without requiring a symmetric key distribution
solution for DHCP, this document defines an asymmetric key solution for DHCP, this document defines an asymmetric key
authentication and encryption mechanism. This protects against both authentication and encryption mechanism. This protects against both
active attacks, such as spoofing, and passive attacks, such as active attacks, such as spoofing, and passive attacks, such as
pervasive monitoring. pervasive monitoring.
5. Secure DHCPv6 Overview 5. Secure DHCPv6 Overview
skipping to change at page 6, line 41 skipping to change at page 6, line 41
5.2. New Components 5.2. New Components
The new components of the mechanism specified in this document are as The new components of the mechanism specified in this document are as
follows: follows:
o Servers and clients that use certificates first generate a public/ o Servers and clients that use certificates first generate a public/
private key pair and then obtain a certificate that signs the private key pair and then obtain a certificate that signs the
public key. The Certificate option is defined to carry the public key. The Certificate option is defined to carry the
certificate of the sender. certificate of the sender.
o A signature generated using the private key which is used by the o A signature is generated using the private key to verify the
receiver to verify the integrity of the DHCPv6 messages and then integrity of the DHCPv6 messages. The Signature option is defined
authentication of the client/server. The Signature option is to carry the signature.
defined to carry the signature.
o A Increasing-number that can be used to detect replayed packet. o A Increasing-number is used to detect replayed packet. The
The Timestamp is one of the possible implementation choices. The Timestamp is one of the possible implementation choices. The
Increasing-number option is defined to carry a strictly-increasing Increasing-number option is defined to carry a strictly-increasing
serial number. serial number.
o The Encrypted-message option that contains the encrypted DHCPv6 o The Encrypted-message option contains the encrypted DHCPv6
message. message.
o The Encrypted-Query message that is sent from the secure DHCPv6 o The Encrypted-Query message is sent from the secure DHCPv6 client
client to the secure DHCPv6 server. The Encrypted-Query message to the secure DHCPv6 server. The Encrypted-Query message MUST
MUST contain the Encrypted-message option. In addition, the contain the Encrypted-message option. In addition, the Server
Server Identifier option MUST be contained if it is contained in Identifier option MUST be contained if it is contained in the
the original DHCPv6 message. The Encrypted-Query message MUST NOT original DHCPv6 message. The Encrypted-Query message MUST NOT
contain other options except the above options. contain other options except the above options.
o The Encrypted-Response message that is sent from the secure DHCPv6 o The Encrypted-Response message is sent from the secure DHCPv6
server to the secure DHCPv6 client. The Encrypted-Response server to the secure DHCPv6 client. The Encrypted-Response
message MUST contain the Encrypted-message option. The Encrypted- message MUST contain the Encrypted-message option. The Encrypted-
Response message MUST NOT contain any other options except it. Response message MUST NOT contain any other options except it.
5.3. Support for Algorithm Agility 5.3. Support for Algorithm Agility
In order to provide a means of addressing problems that may emerge In order to provide a means of addressing problems that may emerge
with existing hash algorithms, signature algorithm and encryption with existing hash algorithms, signature algorithm and encryption
algorithms in the future, this document provides a mechanism to algorithms in the future, this document provides a mechanism to
support algorithm agility. The support for algorithm agility in this support algorithm agility. The support for algorithm agility in this
document is mainly a algorithm notification mechanism between the document is mainly a algorithm notification mechanism between the
client and the server. The same client and server SHOULD use the client and the server. The same client and server SHOULD use the
same algorithm in a single communication session. same algorithm in a single communication session. The sender can
offer a set of algorithms, and then the receiver selects one
algorithm for the future communication.
If the server does not support the algorithm used by the client, the If the server does not support the algorithm used by the client, the
server SHOULD reply with an AlgorithmNotSupported status code server SHOULD reply with an AlgorithmNotSupported status code
(defined in Section 10.3) to the client. Upon receiving this status (defined in Section 10.3) to the client. Upon receiving this status
code, the client MAY resend the message protected with the mandatory code, the client MAY resend the message protected with the mandatory
algorithm. algorithm.
5.4. Caused change to RFC3315 5.4. Caused change to RFC3315
This protocol changes DHCPv6 message exchanges quite substantially: This protocol changes DHCPv6 message exchanges quite substantially:
skipping to change at page 9, line 18 skipping to change at page 9, line 20
DHCPv6 client discards any DHCPv6 messages that meet any of the DHCPv6 client discards any DHCPv6 messages that meet any of the
following conditions: following conditions:
o the Signature option is missing, o the Signature option is missing,
o multiple Signature options are present, o multiple Signature options are present,
o the Certificate option is missing. o the Certificate option is missing.
And then the client first checks the support of the hash algorithm, And then the client first checks the support of the hash algorithm,
signature algorithm and encryption algorithm that the server signature algorithm and encryption algorithms that the server
supports. If the check fails, the Reply message is dropped. If the supports. If the checks fails, the Reply message is dropped. If the
hash algorithm field is zero, then it indicates that the hash hash algorithm field is zero, then it indicates that the hash
algorithm is fixed according to the corresponding signature algorithm is fixed according to the corresponding signature
algorithm. If all the algorithms are supported, then the client also algorithm. If all the algorithms are supported, then the client
selects one hash algorithm, signature algorithm and encryption
algorithm from the provided algorithms set. And then the client also
uses the same algorithms in the return messages. uses the same algorithms in the return messages.
Then the client checks the authority of the server. The client Then the client checks the authority of the server. The client
validates the certificates through the pre-configured local trusted validates the certificates through the pre-configured local trusted
certificates list or other methods. A certificate that finds a match certificates list or other methods. A certificate that finds a match
in the local trust certificates list is treated as verified. The in the local trust certificates list is treated as verified. The
message transaction-id is used as the identifier of the authenticated message transaction-id is used as the identifier of the authenticated
server's public key for further message encryption. At this point, server's public key for further message encryption. At this point,
the client has either recognized the certificate of the server, or the client has either recognized the certificate of the server, or
decided to drop the message. decided to drop the message.
skipping to change at page 13, line 14 skipping to change at page 13, line 14
The server SHOULD first check the support of the hash function, The server SHOULD first check the support of the hash function,
signature algorithm, encryption algorithm that the client supports. signature algorithm, encryption algorithm that the client supports.
If the hash algorithm field is zero, then the corresponding hash If the hash algorithm field is zero, then the corresponding hash
algorithm is fixed according to the signature algorithm. If the algorithm is fixed according to the signature algorithm. If the
check fails, the server SHOULD reply with an AlgorithmNotSupported check fails, the server SHOULD reply with an AlgorithmNotSupported
error status code, defined in Section 10.3, back to the client. error status code, defined in Section 10.3, back to the client.
Because the server does not support the acknowledged algorithm, the Because the server does not support the acknowledged algorithm, the
Reply message with the AlgorithmNotSupported error status code is Reply message with the AlgorithmNotSupported error status code is
encrypted with the mandatory algorithm. If all the algorithms are encrypted with the mandatory algorithm. If all the algorithms are
supported, the server then checks the authority of this client. supported, the server then uses the acknowledged algorithms in the
future communication.
The server validates the client's certificate through the local pre- The server validates the client's certificate through the local pre-
configured trusted certificates list. A certificate that finds a configured trusted certificates list. A certificate that finds a
match in the local trust certificates list is treated as verified. match in the local trust certificates list is treated as verified.
The message that fails authentication validation MUST be dropped. In The message that fails authentication validation MUST be dropped. In
such failure, the DHCPv6 server replies with an AuthenticationFail such failure, the DHCPv6 server replies with an AuthenticationFail
error status code, defined in Section 10.3, back to the client. The error status code, defined in Section 10.3, back to the client. The
Reply message with the AuthenticationFail error status code is also Reply message with the AuthenticationFail error status code is also
encrypted. At this point, the server has either recognized the encrypted. At this point, the server has either recognized the
authentication of the client, or decided to drop the message. authentication of the client, or decided to drop the message.
skipping to change at page 15, line 6 skipping to change at page 15, line 6
increasing number during the transaction with the DHCPv6 server. In increasing number during the transaction with the DHCPv6 server. In
addition, the client can forget the increasing number information addition, the client can forget the increasing number information
after the transaction is finished. after the transaction is finished.
It is essential to remember that the increasing number is finite. It is essential to remember that the increasing number is finite.
All arithmetic dealing with sequence numbers must be performed modulo All arithmetic dealing with sequence numbers must be performed modulo
2^64. This unsigned arithmetic preserves the relationship of 2^64. This unsigned arithmetic preserves the relationship of
sequence numbers as they cycle from 2^64 - 1 to 0 again. sequence numbers as they cycle from 2^64 - 1 to 0 again.
In order to check the Increasing-number option, the following In order to check the Increasing-number option, the following
comparison is needed. The symbol ">=" means "more or equal" (modulo comparison is needed. The symbol means "less or equal" (modulo
2^64). 2^64).
NUM.STO = the stored number in the client/server NUM.STO = the stored number in the client/server
NUM.REC = the acknowledged number from the received message NUM.REC = the acknowledged number from the received message
The Increasing-number option in the received message passes the The Increasing-number option in the received message passes the
increasing number check if it meets the following condition: increasing number check if NUM.REC is more than NUM.STO. And then,
the value of NUM.STO is changed into the value of NUM.REC.
NUM.REC >= NUM.STO
And then, the value of NUM.STO is changed into the value of NUM.REC.
The increasing number check fails if NUM.REC is less than NUM.STO. The increasing number check fails if NUM.REC is equal or less than
NUM.STO
10. Extensions for Secure DHCPv6 10. Extensions for Secure DHCPv6
This section describes the extensions to DHCPv6. Four new DHCPv6 This section describes the extensions to DHCPv6. Four new DHCPv6
options, two new DHCPv6 messages and five new status codes are options, two new DHCPv6 messages and five new status codes are
defined. defined.
10.1. New DHCPv6 Options 10.1. New DHCPv6 Options
10.1.1. Certificate Option 10.1.1. Certificate Option
The Certificate option carries the certificate(s) of the client/ The Certificate option carries the certificate(s) of the client/
server. The format of the Certificate option is described as server. The format of the Certificate option is described as
follows: follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_CERTIFICATE | option-len | | OPTION_CERTIFICATE | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EA-id | | | EA-num | EA-id | EA-id | ... .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cert-len | |
+-+-+-+-+-+-+-+-+ .
. Certificate (variable length) .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cert-len | |
+-+-+-+-+-+-+-+-+ . +-+-+-+-+-+-+-+-+ .
. Certificate (variable length) . . Certificate (variable length) .
. . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. ... .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_CERTIFICATE (TBA1). option-code OPTION_CERTIFICATE (TBA1).
option-len 1 + Length of certificate in octets. option-len 1 + length of EA-id list + length of certificate
list in octets.
EA-num The number of the supported encryption algorithm.
EA-id Encryption Algorithm id. The encryption algorithm EA-id Encryption Algorithm id. The encryption algorithm
is used for the encrypted DHCPv6 configuration is used for the encrypted DHCPv6 configuration
process. This design is adopted in order to provide process. This design is adopted in order to provide
encryption algorithm agility. The value is from the encryption algorithm agility. The value is from the
Encryption Algorithm for Secure DHCPv6 registry in Encryption Algorithm for Secure DHCPv6 registry in
IANA. A registry of the initial assigned values IANA. A registry of the initial assigned values
is defined in Section 12. is defined in Section 12.
cert-len The length of the certificate.
Certificate A variable-length field containing certificates. The Certificate A variable-length field containing certificates. The
encoding of certificate and certificate data MUST encoding of certificate and certificate data MUST
be in format as defined in Section 3.6, [RFC7296]. be in format as defined in Section 3.6, [RFC7296].
The support of X.509 certificate is mandatory. The support of X.509 certificate is mandatory.
10.1.2. Signature option 10.1.2. Signature option
The Signature option allows a signature that is signed by the private The Signature option allows a signature that is signed by the private
key to be attached to a DHCPv6 message. The Signature option could key to be attached to a DHCPv6 message. The Signature option could
be in any place within the DHCPv6 message while it is logically be in any place within the DHCPv6 message while it is logically
created after the entire DHCPv6 header and options. It protects the created after the entire DHCPv6 header and options. It protects the
entire DHCPv6 header and options, including itself. The format of entire DHCPv6 header and options, including itself. The format of
the Signature option is described as follows: the Signature option is described as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_SIGNATURE | option-len | | OPTION_SIGNATURE | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SA-id | HA-id | | | SA-num | SA-id | SA-id | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HA-num | HA-id | HA-id | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. Signature (variable length) . . Signature (variable length) .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_SIGNATURE (TBA2). option-code OPTION_SIGNATURE (TBA2).
option-len 2 + Length of Signature field in octets. option-len 2 + length of SA-id list + length of HA-id list +
length of Signature field in octets.
SA-id Signature Algorithm id. The signature algorithm is SA-id Signature Algorithm id. The signature algorithm is
used for computing the signature result. This used for computing the signature result. This
design is adopted in order to provide signature design is adopted in order to provide signature
algorithm agility. The value is from the Signature algorithm agility. The value is from the Signature
Algorithm for Secure DHCPv6 registry in IANA. The Algorithm for Secure DHCPv6 registry in IANA. The
support of RSASSA-PKCS1-v1_5 is mandatory. A support of RSASSA-PKCS1-v1_5 is mandatory. A
registry of the initial assigned values is defined registry of the initial assigned values is defined
in Section 12. in Section 12.
skipping to change at page 18, line 11 skipping to change at page 18, line 25
way that the authentication mechanism defined in RFC3315 does not way that the authentication mechanism defined in RFC3315 does not
understand. So the Authentication option SHOULD NOT be used if understand. So the Authentication option SHOULD NOT be used if
Secure DHCPv6 is applied. Secure DHCPv6 is applied.
10.1.3. Increasing-number Option 10.1.3. Increasing-number Option
The Increasing-number option carries the number which is higher than The Increasing-number option carries the number which is higher than
the local stored number on the client/server. It adds the anti- the local stored number on the client/server. It adds the anti-
replay protection to the DHCPv6 messages. It is optional. replay protection to the DHCPv6 messages. It is optional.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_INCREASING_NUM | option-len | | OPTION_INCREASING_NUM | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| InreasingNum (64-bit) | | InreasingNum (64-bit) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_INCREASING_NUM (TBA3). -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_INCREASING_NUM (TBA3).
option-len 8, in octets. option-len 8, in octets.
IncreasingNum A number for the replay attack detection which is more IncreasingNum A strictly increasing number for the replay attack detection
or equal compared with the local stored number. which is more than the local stored number.
10.1.4. Encrypted-message Option 10.1.4. Encrypted-message Option
The Encrypted-message option carries the encrypted DHCPv6 message The Encrypted-message option carries the encrypted DHCPv6 message
with the recipient's public key. with the recipient's public key.
The format of the Encrypted-message option is: The format of the Encrypted-message option is:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 End of changes. 33 change blocks. 
60 lines changed or deleted 83 lines changed or added

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