Internet DRAFT - draft-ev-6man-cga-light
draft-ev-6man-cga-light
IPv6 Maintenance (6man) Working Group E. Vasilenko
Internet Draft Huawei Technologies
Updates: None
Intended status: Standards Track September 22, 2022
Expires: March 2023
Cryptographically Generated Addresses (CGA) Light
draft-ev-6man-cga-light-01
Abstract
This document specifies a method for securely associating link-layer
addresses (MAC) to the IPv6 address by a cryptography method similar
to blockchain mining.
It permits guarantee security at the IPv6 layer to the same degree
as at the link layer (that node is dependent on anyway).
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 2021.
Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
Expires March 22, 2023 [Page 1]
Internet-Draft ND-prefix-robustness September 2022
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
Table of Contents
1. Terminology and pre-requisite..................................2
2. Introduction...................................................3
3. Strength Evaluation............................................5
4. IID generation technical details...............................6
5. IID validation technical details..............................10
6. ND extensions to exchange relevant information................11
7. Compatibility with other ND functionality.....................12
8. Security Considerations.......................................13
9. IANA Considerations...........................................14
10. References...................................................14
10.1. Normative References....................................14
10.2. Informative References..................................15
11. Acknowledgments..............................................16
1. Terminology and pre-requisite
Many terms are inherited from [CGA] and [SEND].
Information for IID - the collection of information needed to
distinguish IIDs generated for different purposes in
compliance with other standards; local information to the
node.
Digest of IID information - hash from "Information for IID"; public
information distributed by ND.
Chg parameter - a number between 0 and 15 (4 bits) that participates
in the calculation (A+B*Chg) of leading zero bits that should
be in a validated hash; "A" and "B" are constants fixed in
this specification
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
Expires March 22, 2023 [Page 2]
Internet-Draft ND-prefix-robustness September 2022
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Introduction
There are many attack vectors to ND. [ND Trust Model] section 4.1
has the name "Non-router related threats" and could be summarized:
. A malicious node could answer DAD for any request of a
legitimate node (denial of service attack)
. A malicious node could poison the cache of another node
(especially the router) to intercept traffic directed to
another node (man in the middle attack); it is possible for
neighbor solicitation and neighbor advertisement in many
different cases.
The potential bunch of attacks based on the above is discussed in
detail in [ND MITM] section 3:
. Rewrite cache by unsolicited NA
. Be the first and suppress DAD
. Win the race just after DAD
The [SEND] plus [CGA] have proposed cryptographic solutions to the
problem. The [CGA] was positioned as dependent on [SEND] not a
separate solution, it was used primarily to avoid unnecessary
signature verifications (pre-check) for denial of service requests.
Unfortunately, [SEND] has a pre-request to organize PKI (public key
infrastructure) which is a well-known problem for enterprises. It is
assumed that trusted anchor management in the [SEND] solution was
the primary reason for low adoption.
The same problem is relevant to the [HBA] solution that needs
distribution and management for symmetric keys.
Effectively, it could be said that previous solutions have low
adoption for the same reason as IPSec: a challenge to organize key
management.
Blockchain's general success has shown that cryptography could be
valuable even in a situation when the trusted anchor is not
considered.
This document is based on the [CGA] with minor modifications needed
to satisfy the requirements of many other standards developed since
then. This document fulfills the [CGA] promise: "The protection
works without a certification authority or any security
infrastructure".
Expires March 22, 2023 [Page 3]
Internet-Draft ND-prefix-robustness September 2022
The [CGA] was associating the "public key" to "IID" as a backup to
public key management in the certification authority.
In contrast, this document proposes a "Link-layer" to "IPv6"
addresses associated with cryptography assurance.
Link-layer address to IP layer address mapping is the primary
function of [ND] protocol that is protected by this specification.
The link-layer address is cryptographically protected in the case of
wireless and very often protected in the case of wireline (802.1x).
It is possible to have the link with nodes supporting this
specification and legacy nodes that could not check the address
ownership. ND cache could be poisoned on unprotected nodes in a
mixed environment. The router is the key target for ND cache
poisoning. Hence, router support for this specification is
especially valuable.
A reminder that hash function is by design has no correlation
between output and input. Hence, only brute input trials are needed
to find output with any desired property (like some number of
leading zeroes).
The protection principles here are the same as for blockchain mining
or [CGA]: the legal node needs 2^(A+B*Chg+1-1) calculations on
average for IID mining but the malicious node would need
2^(A+B*Chg+60-1) calculations on average because in addition to the
same amount of leading zeroes it needs additionally the particular
combination of 60 trailing bits at the same time. "+1" in the above
calculations is because the hash is double for mining. "-1" in the
above calculation is because of the average (50% probability).
Hence, the intruder needs 2^59 times more hash calculations to find
a proper "Digest of IID information" that would match his link-layer
address (MAC).
[Hash in Sec] has a discussion that if many hash algorithms are
available on the link then intruder can attack the weakest. [Hash in
Sec] has proposed to encode hash type in the IID (borrowing security
level space), IANA "CGA SEC" registry has been created. Hence, [CGA]
security level ("Sec" parameter) has a different meaning from the
"Chg" parameter used in this specification.
Attack vector on hash type downgrade has been dealt with in this
specification by rewrite rules of ND cache where hash type is
considered.
Let's overview IID mining:
Expires March 22, 2023 [Page 4]
Internet-Draft ND-prefix-robustness September 2022
0. Choose the Chg parameter that points to how many leading zeroes
should be in the hash on step 3.
1. Initially, all relevant information for IID creation is
concatenated in the clear text block that would be named
"Information for IID". It is primarily the information needed
for:
a. Guaranty IID uniqueness (Time, Nonce, Collision count)
b. Guaranty stable but different IID for different link
attachments (interface name, network name)
2. Then "Information for IID" is hashed. The result is the "Digest
of IID information" that would be made public by [ND] protocol.
3. "Digest of IID information" is concatenated with Prefix and link-
layer (MAC) and then hashed again.
4. If the hash result of step 3 already has the needed number of
leading zeroes then 60 lowest bits are used for IID and
"Information for IID" should be saved in non-volatile memory.
Else (not enough leading zeroes) any bits (Nonce, Time) or fields
order in the "Information for IID" should be changed and this
algorithm loops to step 2.
The algorithm convergence may need 2^(A+B*Chg) calculations in an
average of the selected hash function, it has a good probability to
converge for 2^(A+B*Chg+1) hash calculations.
Any other node may do a simple check of validity for the
Prefix/IID/Link-Layer combination before rewriting ND cache:
0. Extract Chg from 4 high order IID bits.
1. Hash the "Digest of IID information" concatenated with Prefix and
link-layer address (MAC).
2. Check that the leading A+B*Chg bits of the hash are zeroes.
Discard ND update otherwise.
3. Check that the trailing 60 bits of the hash are equal to the IID
claimed by the node. Discard ND update otherwise.
4. Accept ND update.
3. Strength Evaluation
Bitcoin is a good reference for such a type of evaluation.
It uses a double hash like this specification, the type is SHA-256.
The different hash algorithms (SHA-512 is recommended below for this
specification) may improve security that would be ignored for this
estimation.
Bitcoin has started from the requirement for 32 bits leading zeroes
(for the genesis block) and has moved to 80 bits now.
It has surpassed 200EH/s (2*10^20 hashes per second) to crack 80
Expires March 22, 2023 [Page 5]
Internet-Draft ND-prefix-robustness September 2022
bits for 10 minutes on average.
The principal difference is that the Bitcoin block (to hash) is much
bigger (around 1MB+-50%) compare needed to CGA (around 280B). Hence,
Bitcoin's difficulty is around 2^12 bigger just because of the
bigger input.
Let's justify the "A" and "B" parameters for "A+B*Chg" leading
zeroes.
"A" leading zeroes should be easy to calculate even for the smallest
system. The smallest IoT system may spend as high as 200us for one
SHA-256 in software (hardware acceleration is available very often
then the performance is better). 1 minute is the assumption for the
time permitted to spend for mining then A=8 leading zeroes that are
needed for mining at a minimum.
The challenge for the intruder would be 2^67 hashes. The whole
Bitcoin infrastructure would crack it for 18us. It would be just a
problem to persuade mining owners to proceed.
Let "B" would be big enough for the whole Bitcoin infrastructure
would not crack IID in 1000 years. 1000 years is different from 10
min in 2^26. Additionally, our hashed block is 2^12 smaller. Hence,
it should be an 80+26+12=118 bits challenge. Then B=4.
The challenge for mining IID would be 2^68. Some GPUs are capable of
3GH/s then IID mining would be around 3000 years on one GPU which is
probably a good room for growth. It means that the Chg parameter at
the highest values (>12) would be seen as very rare for some time.
Summary: for respective A+B*Chg, A=8, B=4.
Chg is transmitted in every ND update as the high-order bits of IID.
It is the compromise between the possibility of mining on the
smallest node and maximum protection that is desired to achieve in
the future for a very important server.
In general, knowing the node capability for the number of hashes per
second (for chosen hash type) - it is easy to predict the average
time of mining for the specific level of protection (Chg parameter).
4. IID generation technical details
IID generation should be done separately per every link/network
according to [Different IIDs]. It would be needed to perform this
procedure after any new prefix (PIO) announcement or link-layer
address change.
The implementation MAY have the capability to get initial parameters
from the configuration when it is possible to do mining on a
Expires March 22, 2023 [Page 6]
Internet-Draft ND-prefix-robustness September 2022
different system. In that case, the target system SHOULD go through
the algorithm below anyway to check the consistency. It would cost 2
hash calculations to check that all data are consistent.
Decide about the needed level of protection for the address. Chg
parameter has 4 bits that permit 16 levels of protection, every next
level of protection would request "B" additional zero leading bits
in the second hash mining. All nodes SHOULD have a possibility of
administrator configuration for the level of IID protection (Chg
parameter) on every sub-interface. The default protection level for
the particular system is up to the implementer.
Like all other cases in cryptography, even well-protected IID (high
levels of Chg) MUST be refreshed after some time.
Pay attention that Chg increase by one would increase the strength
of IID by 2^B. It does not permit giving default configuration
recommendations because different hash algorithms by themselves may
have different strengths and different target systems may have a few
orders of magnitude different attractiveness for an intruder that
may bring principally different resources for mining.
Hence, the table of lifetimes for every level of Chg is
implementation-specific. It may be different for different hash
algorithms.
Reminder, that [IID significance] has deprecated special meaning for
"u" and "g" bits in IID. Hence, all 64 bits are available for our
specification. 4 bits were used for the protection level. Hence, 60
bits are left for random ID.
Step 1:
As discussed in [Temporary addresses] that "Information for IID"
should have a prefix, link-layer address, network name, time, DAD
counter, and some nonce to make it possible for temporary address
generation. Prefix and link-layer addresses would be added to the
second hash calculation. Hence, initially, the "Information for IID"
text should have:
. Nonce to easy change the "Information for IID" hash
. Time in any format, better to follow [Temporary addresses]
assumptions
. Network name (like SSID) for links that have such parameter
. DAD collision count that is regulated by other specifications
. Any other parameters are permitted because all parameters of
"Information for IID" have local meaning - they would be not
advertised by [ND]
Expires March 22, 2023 [Page 7]
Internet-Draft ND-prefix-robustness September 2022
The size of the parameters is up to the implementer. An especially
big block of "Information for IID" may affect the performance of IID
mining.
The order of information concatenation is not important. Moreover,
as it would be shown later the order may be changed during the
mining process.
Special warning about Nonce size. It is RECOMMENDED to choose it
longer than chosen A+B*Chg bits. Or else would be the same problem
as for Bitcoin: Nonce could be looped around, but mining is not
successful yet. In this case, like for Bitcoin, it is possible to
change parameters (for example, read new time) or reorder the above-
mentioned fields or introduce extraNonce as an additional field to
the "Information for IID". To avoid this additional algorithm
complexity, it is better to define Nonce as A+B*15 bits which should
be enough for the most secure IID mining. Anyway, it is a local
implementation matter.
It does not make sense to spend resources on additional mathematical
functions upon "Information for IID" because later it would be
hashed anyway for good randomization. The hash function is good
enough to satisfy [Temporary addresses] requirements.
Step 2:
Then "Information for IID" is hashed. The result is the "Digest of
IID information" that would be made public by [ND] protocol together
with the corresponding link-layer address and prefix intended for
IID.
The hash at this stage has local significance. Hence, the hash type
may be different from the hash type in Step 3 which should be
synchronized between nodes on the link. Simplicity should have both
hashes of the same type.
Step 3:
"Digest of IID information" is concatenated with Prefix and link-
layer address into one block that is hashed again.
It is MANDATORY to keep the order and size mentioned in this Step
parameters to have consistent hash results on all nodes of the link
(to check validity).
"Digest of IID information" on the input MUST have the same size as
the output of the chosen hash type for this step. If there is any
Expires March 22, 2023 [Page 8]
Internet-Draft ND-prefix-robustness September 2022
difference then Digest should be truncated or fitted with leading
zeroes. Most probably, both steps (step 2 and step 3) would use the
same hash type then the hash size would be equal automatically.
The prefix MUST be populated with trailing zeroes up to 128 bits to
support any prefix boundary in the future.
Link Layer address MUST be fitted leading zeroes to 64 bits to be
capable to accommodate any L2 technology.
Step 4:
Check for how many leading zeroes the second hash has (from the
previous step). Mining SHOULD be processed till A+B*Chg leading bits
are zeroed.
If successful then the resulted "Information for IID" and "Digest of
IID information" SHOULD be memorized in non-volatile memory.
Else "Information for IID" should be modified and the mining
algorithm should be looped to step 2.
"Information for IID" has many ways to be modified:
. Increment Nonce
. Reorder fields in the "Information for IID"
. Change fields (update time)
. Add field (like extraNonce)
It is potentially possible in Step 4 to memorize the "Information
for IID" for the best result seen. Then it is possible to break from
the mining with the correction of the Chg to the achieved number.
Hence, it is possible to loop in the mining cycle for a limited
time. It is NOT RECOMMENDED because it does not permit achieving the
desired level of security. But it may be needed for the high
protection levels (high Chg) or on systems with low hash processing
rates to avoid the system hanging in the mining for an unaccepted
period.
Step 5:
According to the [SLAAC] procedure, the new IID should be checked
for uniqueness by DAD. If DAD is positive then Collision Counter in
the "Information for IID" is incremented and the mining is looped to
step 2. It is up to other specifications to regulate how many
collisions are tolerable and what to do after it would be reached
(for example, ask a manual intervention).
Expires March 22, 2023 [Page 9]
Internet-Draft ND-prefix-robustness September 2022
5. IID validation technical details
The validation node SHOULD check the IP/Link-layer pair association
before any modification in the ND cache. And even after the validity
is checked, there is an additional procedure to check overwrite
rights (see at the end of this section).
Every record in the ND cache should have a flag "validated" and
additional fields used for validation (at least "Digest of IID
information" and hash type). Let's call legacy ND records and
updates as Not-Protected.
The validating node should receive an ND message with all needed
information (hash algorithm type, "Digest of IID information",
Prefix, link-layer address) by mechanisms specified in section 6.
Partial presence of needed parameters (for example "Digest of IID
information" is present but the hash type is absent) is treated as
an update request from a node not supporting this specification
(Not-Protected node).
The mining challenge parameter (Chg) should be extracted from 4
high-order bits of IID.
See details in section 4. Step 3 for the importance of the order and
size of all concatenated fields to get consistent results. Then hash
the "Digest of IID information" concatenated with Prefix and link-
layer address. Resulted hash should be checked for:
. leading A+B*Chg bits of the hash are zero
. trailing 60 bits of the hash are equal to the IID claimed by
the node
If any check is negative then the ND update MUST be dropped. The
update that claims to be protected but failed validation should not
be considered in principle.
If both checks are positive then proceed to the final check that is
especially needed in the mixed environment:
. The Not-Protected record SHOULD be overwritten by a Validated
ND update.
. The Validated record SHOULD be overwritten by a Validated ND
update that satisfies two checks: 1) equal or high permitted
hash type number (see section 6. about the possibility to
exclude some hash types from consideration) and 2) high Chg
parameter (more leading zeroes for protection).
Expires March 22, 2023 [Page 10]
Internet-Draft ND-prefix-robustness September 2022
. The Validated record MUST NOT be overwritten by 1) a Not-
Protected ND update or 2) by a Validated update with an equal
or lower protection level (the smaller or equal Chg parameter)
or 3) by a Validated update with lower permitted (see section
6. about the possibility to exclude some has types from
consideration) hash type number. Effectively, the last rule may
be presented in a simpler form: The Validated record MUST NOT
be overwritten in all other cases.
6. ND extensions to exchange relevant information
For the other node to check address ownership, it needs "Digest of
IID information" concatenated with Prefix and link-layer address.
Three parameters and the type of the hash function should be
advertised.
ND option 39 (Crypto-ID Parameters) would be reused for the hash
type signaling. All other parameters delivered by this option except
hash function type would be ignored for this specification. Crypto-
Type number 1 is pointing to SHA-512 which is RECOMMENDED as the
default. Crypto-type section of the [ICMPv6] registry currently has
types 0 or 2 that choose SHA-256. Crypto-type registry may be
extended as needed. Different nodes can have different crypto-types
on the link, hence, nodes (especially routers) may need to support
all active hash types on the link.
Nodes MUST have the capability to restrict the list of hash types
accepted on the link. It is needed to block failed or weak hash
algorithms in the future. The implementation MAY just treat such
updates as Not-Protected without checking the validity and following
rewrite rules for Not-Protected updates. It is RECOMMENDED that by
default node should accept in ND updates only the hash type that the
node itself is using for mining, all other hash types are better to
provision consciously.
It is the primary purpose of ND to deliver a link-layer address.
[ND] protocol is already asking to include link-layer address
options for all relevant cases:
. It should be included for Router Solicitation (except the IP
address is still unspecified)
. It may be omitted for Router Advertisement
. It must be included for multicast and should be included for
unicast of Neighbor Solicitation
. It must be included for multicast and should be included for
unicast of Neighbor Advertisement (except IP address is still
unspecified)
Expires March 22, 2023 [Page 11]
Internet-Draft ND-prefix-robustness September 2022
Hence, it may be assumed that the link-layer address would be
available at the time needed.
ND protocol is based on IP. Hence, the prefix could be extracted
from the source IP address.
The only parameter left is the "Digest of IID information".
It is defined in this specification:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Digest |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ of IID information (hash) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The type number is TBD by IANA.
"Digest of IID information" and "Crypto-type" options SHOULD be sent
in all cases when link-layer information is sent, i.e. on all
occasions when [ND] uses option 1 (source link-layer address) or
option 2 (target link-layer address).
If the node does not support this specification or requested hash
type then it could not protect other node address ownership. Hence,
it is mandatory to support this specification and all needed hash
types at least on routers.
7. Compatibility with other ND functionality
This specification applies to all types of IPv6 addresses: LLA, ULA,
and GUA.
IID generation should be done separately per every link/network
according to [Different IIDs]. It is important for privacy. There is
a discussion in the industry that link-layer addresses should be
changed too to get better privacy. It is not a problem for the
proposed algorithm to have a separate MAC for the separate link.
Expires March 22, 2023 [Page 12]
Internet-Draft ND-prefix-robustness September 2022
[Temporary addresses] recommendations have been reused in the
proposed algorithm for compliance. It is not a problem to change the
link-layer address together with IID at the time of mining (to have
the link-layer address temporary too).
ND Proxy claims the ownership of link-layer addresses on different
media. Hence, it would be operational for its primary purpose - to
interconnect separate media. ND Proxy fully impersonalizes the
IP/Link-layer relationship for the different media. ND Proxy does
not need to do mining - it should reuse all parameters received from
the original node owning the IP/Link-layer association.
This specification does not influence the protocol exchange. Hence,
it is compatible with [ND] and its many modifications (Optimistic
DAD, NUD improvements, Gratuitous ND, Multihoming, etc).
The proposal may replace deep snooping and automatic filtering by
SAVI.
Many node redundancy schemes share link-layer addresses (MAC) then
it is not a problem to share "Information for IID" between such
nodes and keep IP to link-layer association protected.
The load balancer should have no problem distributing traffic
between unique IP/Link-layer pairs.
There is a special situation with Anycast if it is localized on one
link because the same IP could not have a different link-layer
address. Hence, this specification should be disabled on the routers
for this link.
Anycast distributed between links (a more typical situation) is not
a problem because the IP to the link-layer association has a local
significance for the link.
A duplicate link-layer address initiates flapping which is a typical
problem for switching infrastructure. It should be investigated
anyway. Switches typically have the functionality to automatically
suppress flapping link-layer addresses or ports.
8. Security Considerations
This document closes some ND vulnerabilities by cryptographic
methods popular in the blockchain. IP Address ownership is securely
associated with the link-layer address.
Expires March 22, 2023 [Page 13]
Internet-Draft ND-prefix-robustness September 2022
This specification does not prevent replay attacks. If the victim
node is absent on the link then the malicious node could change his
link-layer address (MAC) to the victims' then claim IP/Link-layer
association replaying previously saved ND messages. It may not
happen for link layers that are protected by themselves (typically
encryption implemented on any wireless). If successful, then the
intruder may impersonate the absent victim and ask for credentials
as a minimum. It has a low probability because the server is
typically always available but the client is not receiving incoming
connections. As it was stated in the abstract the level of
protection is equal to the level of link layer protection. If it is
possible to impersonate the address at the link-layer then IP layer
protection would not help, certification authority and end-to-end
traffic encryption are needed.
Replay protection needs different Nonce included into every message
then encrypt and decrepit every message that is a very expensive
proposition for [ND].
Canceling a trusted anchor would make all nodes equal that does not
permit the restriction of the router's functionality to particular
nodes. Hence, this specification could not deprecate [RA-Guard] and
[RA-Guard+].
This specification does not prevent denial of service attacks in
general. It is possible to generate many legal IP/Link-layer
associations (presumably with a low level of mining by Chg
parameter) and try to overwhelm other nodes on the link with
additional states.
9. IANA Considerations
The new option "Digest of IID information Option" is specified with
the type number TBD.
It is registered in the section "IPv6 Neighbor Discovery Option
Formats" of the [ICMPv6] registry.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI
10.17487/RFC2119, March 1997, <https://www.rfc-
editor.org/info/rfc2119>.
Expires March 22, 2023 [Page 14]
Internet-Draft ND-prefix-robustness September 2022
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[ND] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007, <https://www.rfc-
editor.org/info/rfc4861>.
[SLAAC] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, DOI
10.17487/RFC4862, September 2007, <https://www.rfc-
editor.org/info/rfc4862>.
[IID significance] B. Carpenter, S. Jiang, D. Thaler, W. Liu,
"Significance of IPv6 Interface Identifiers", RFC 7136,
DOI 10.17487/RFC7136, February 2014, <https://www.rfc-
editor.org/info/rfc7136>.
[Different IIDs] F. Gont, A. Cooper, D. Thaler, W. Liu,
"Recommendation on Stable IPv6 Interface Identifiers", RFC
8064, DOI 10.17487/RFC8064, February 2017,
<https://www.rfc-editor.org/info/rfc8064>.
[Temporary addresses] F. Gont, S. Krishnan, T. Narten, R. Draves,
"Temporary Address Extensions for Stateless Address
Autoconfiguration in IPv6", RFC 8981, DOI
10.17487/RFC8981, February 2021, <https://www.rfc-
editor.org/info/rfc8981>.
[ND Trust Model] P. Nikander, J. Kempf, E. Nordmark, "IPv6 Neighbor
Discovery (ND) Trust Models and Threats", RFC 3756, DOI
10.17487/RFC3756, May 2004, <https://www.rfc-
editor.org/info/rfc3756>.
10.2. Informative References
[SEND] J. Arkko, J. Kempf, B. Zill, P. Nikander, "SEcure Neighbor
Discovery (SEND)", RFC 3971, DOI 10.17487/RFC3971, June
2004, <https://www.rfc-editor.org/info/rfc3971>.
[HBA] M. Bagnulo, "Hash-Based Addresses (HBA)", RFC 5535, DOI
10.17487/RFC5535, June 2009, <https://www.rfc-
editor.org/info/rfc5535>.
Expires March 22, 2023 [Page 15]
Internet-Draft ND-prefix-robustness September 2022
[CGA] T. Aura, "Cryptographically Generated Addresses (CGA)", RFC
3972, DOI 10.17487/RFC3972, March 2005, <https://www.rfc-
editor.org/info/rfc3972>.
[Hash in Sec] M. Bagnulo, J. Arkko, "Support for Multiple Hash
Algorithms in Cryptographically Generated Addresses
(CGAs)", RFC 4982, DOI 10.17487/RFC4982, July 2007,
<https://www.rfc-editor.org/info/rfc4982>.
[ICMPv6] IANA, "Internet Control Message Protocol version 6 (ICMPv6)
Parameters", <http://www.iana.org/assignments/icmpv6-
parameters/>.
[RA-Guard] E. Levy-Abegnoli, G. Van de Velde, C. Popoviciu, J.
Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, DOI
10.17487/RFC6105, February 2011, <https://www.rfc-
editor.org/info/rfc6105>.
[RA-Guard+] F. Gont, "Implementation Advice for IPv6 Router
Advertisement Guard (RA-Guard)", RFC 7113, DOI
10.17487/RFC7113, February 2014, <https://www.rfc-
editor.org/info/rfc7113>.
[ND MITM] E. Vasilenko, X. Xiao, " ND improvement to prevent Man-in-
the-middle attack", draft-vasilenko-6man-nd-mitm-
protection-00 (work in progress), September 2020.
11. Acknowledgments
Thanks to the 6man working group for problem discussion.
Authors' Addresses
Eduard Vasilenko
Huawei Technologies
17/4 Krylatskaya st, Moscow, Russia 121614
Email: vasilenko.eduard@huawei.com
Expires March 22, 2023 [Page 16]
