Skip to main content

Cryptographically Generated Addresses (CGA) Light
draft-ev-6man-cga-light-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Author Eduard V
Last updated 2022-07-08
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-ev-6man-cga-light-00
IPv6 Maintenance (6man) Working Group                      E. Vasilenko
Internet Draft                                      Huawei Technologies
Updates: None
Intended status: Standards Track                           July 8, 2022
Expires: January 2023

            Cryptographically Generated Addresses (CGA) Light
                        draft-ev-6man-cga-light-00

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 January 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 January 8, 2023                 [Page 1]
Internet-Draft           ND-prefix-robustness                 July 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...............................9
   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 January 8, 2023                 [Page 2]
Internet-Draft           ND-prefix-robustness                 July 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.
   Effectively, it could be said that [SEND] has 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".

   The [CGA] was associating the "public key" to "IID" as a backup to
   public key management in the certification authority.

                       Expires January 8, 2023                 [Page 3]
Internet-Draft           ND-prefix-robustness                 July 2022

   In contrast, this document proposes a "Link-layer" to "IPv6"
   addresses associated with cryptography assurance.

   Link-layer to IP layer mapping is the primary function of [ND]
   protocol that is protected by this specification.

   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:

   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

                       Expires January 8, 2023                 [Page 4]
Internet-Draft           ND-prefix-robustness                 July 2022

     "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
   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,

                       Expires January 8, 2023                 [Page 5]
Internet-Draft           ND-prefix-robustness                 July 2022

   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.
   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
   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.

                       Expires January 8, 2023                 [Page 6]
Internet-Draft           ND-prefix-robustness                 July 2022

   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). 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]

   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.

                       Expires January 8, 2023                 [Page 7]
Internet-Draft           ND-prefix-robustness                 July 2022

   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
   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.

                       Expires January 8, 2023                 [Page 8]
Internet-Draft           ND-prefix-robustness                 July 2022

   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.

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

                       Expires January 8, 2023                 [Page 9]
Internet-Draft           ND-prefix-robustness                 July 2022

   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
        (see section 6.  about the possibility to exclude some has
        types from consideration) hash type number and 2) high Chg
        parameter (more leading zeroes for protection).
     . 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

                       Expires January 8, 2023                [Page 10]
Internet-Draft           ND-prefix-robustness                 July 2022

        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. 3
   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)

   Hence, it may be assumed that the link-layer address would be
   available at the time needed.

                       Expires January 8, 2023                [Page 11]
Internet-Draft           ND-prefix-robustness                 July 2022

   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.

   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.

                       Expires January 8, 2023                [Page 12]
Internet-Draft           ND-prefix-robustness                 July 2022

   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.

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.

   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].

                       Expires January 8, 2023                [Page 13]
Internet-Draft           ND-prefix-robustness                 July 2022

   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>.

   [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>.

                       Expires January 8, 2023                [Page 14]
Internet-Draft           ND-prefix-robustness                 July 2022

   [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

   [CGA] T. Aura, "Cryptographically Generated Addresses (CGA)", RFC
             3792, DOI 10.17487/RFC3792, March 2005, <https://www.rfc-
             editor.org/info/rfc3792

   [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>.

                       Expires January 8, 2023                [Page 15]
Internet-Draft           ND-prefix-robustness                 July 2022

   [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 January 8, 2023                [Page 16]