RFC 6059
Simple Procedures for Detecting Network Attachment in IPv6
RFC 6059 💖
Simple Procedures for Detecting Network Attachment in IPv6, okay bestie, this one is from November 2010 and it's a Standards Track doc 🎀 Authored by S. Krishnan (Ericsson) and G. Daley (Netstar Logicalis), published by the Internet Engineering Task Force (IETF), with ISSN 2070-1721. The title block doesn't list anything it obsoletes or updates ✨
Abstract ✨
Detecting Network Attachment lets a host check whether its current addresses or routing setup still work on a brand new network 🦋 This doc gives hosts some simple ways to do that in IPv6, plus what routers need to do to help out 💅
Status of This Memo 📜
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
Want the latest info on this doc, any errata, or how to send feedback? Check http://www.rfc-editor.org/info/rfc6059 🌸
Copyright Notice ©️
Copyright (c) 2010 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) as they stand on the date this document was published. Please read these carefully, because they spell out your rights and restrictions for this doc. Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as described in the Simplified BSD License 🫶
Table of Contents 🗂️
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Link Identification Model . . . . . . . . . . . . . . . . 4
1.4. DNA Overview . . . . . . . . . . . . . . . . . . . . . . . 4
1.5. Working Assumptions . . . . . . . . . . . . . . . . . . . 5
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. The Simple DNA Address Table (SDAT) . . . . . . . . . . . . . 7
5. Host Operations . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. On Receipt of a Router Advertisement . . . . . . . . . . . 7
5.2. After Assignment of a DHCPv6 Address . . . . . . . . . . . 8
5.3. Steps Involved in Detecting Link Change . . . . . . . . . 8
5.4. Link-Layer Indication . . . . . . . . . . . . . . . . . . 8
5.5. Sending Neighbor Discovery probes . . . . . . . . . . . . 9
5.5.1. Sending Router Solicitations . . . . . . . . . . . . . 9
5.5.2. Sending Neighbor Solicitations . . . . . . . . . . . . 9
5.5.3. Concurrent Sending of RS and NS Probes . . . . . . . . 9
5.5.4. Initiating DHCPv6 Exchange . . . . . . . . . . . . . . 9
5.6. Contents of the Neighbor Discovery Messages . . . . . . . 10
5.6.1. Neighbor Solicitation Messages . . . . . . . . . . . . 10
5.6.2. Router Solicitation Messages . . . . . . . . . . . . . 10
5.7. Response Gathering . . . . . . . . . . . . . . . . . . . . 11
5.7.1. Receiving Neighbor Advertisements . . . . . . . . . . 11
5.7.2. Receiving Router Advertisements . . . . . . . . . . . 11
5.7.3. Conflicting Results . . . . . . . . . . . . . . . . . 11
5.8. Further Host Operations . . . . . . . . . . . . . . . . . 11
5.9. On Connecting to a New Point of Attachment . . . . . . . . 12
5.10. Periodic Maintenance of the SDAT . . . . . . . . . . . . . 12
5.11. Recommended Retransmission Behavior . . . . . . . . . . . 12
6. Pseudocode for Simple DNA . . . . . . . . . . . . . . . . . . 13
7. Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8. Relationship to DNAv4 . . . . . . . . . . . . . . . . . . . . 15
9. Security Considerations . . . . . . . . . . . . . . . . . . . 15
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
11.1. Normative References . . . . . . . . . . . . . . . . . . . 17
11.2. Informative References . . . . . . . . . . . . . . . . . . 17
Appendix A. Issues with Confirming Manually Assigned Addresses . 181. Introduction 🌈
Hosts need a way to quickly and reliably figure out whether they've moved onto a network they were on recently 🔍 To spot a reconnection to a network they've visited before, they use router and neighbor discovery messages to gather reachability and configuration info. The host uses that info to decide if it's probably still attached to a link where its address and other config are still valid, and it can keep using them until Neighbor Discovery or DHCPv6 confirms it ✅
This doc pulls in feedback from host and router OS implementors, because they want IPv6 change detection to be simple enough for everyday use 🙌
1.1. Goals 🎯
The goal here is a simple procedure for Detecting Network Attachment (Simple DNA) with these traits:
- Routers do not have to be modified to support this scheme.
- The most common use cases are optimized.
- In the worst case, detection latency is equal to that of standard neighbor discovery so that performance is never degraded.
- False positives are not acceptable. A host must not wrongly conclude that it has reattached to a previously visited network.
- False negatives are acceptable. A host may fail to identify a previously visited link correctly and attempt to acquire fresh addressing and configuration information.
False positives are the big no-no 🙅♀️ A host must not wrongly think it reattached to a network it visited before, but a missed match is totally fine. The host can just go get fresh addressing and config 💀
1.2. Applicability 🦋
Simple DNA gives you real benefits over standard neighbor discovery [RFC4861] in some scenarios, and in other scenarios it doesn't help at all. That's on purpose, since Simple DNA was built for simplicity rather than completeness 💅 It's strongest when a host bounces between a small set of known links. When a host moves to a completely new link it's never seen, Simple DNA performs exactly the same as standard neighbor discovery procedures [RFC4861]. In that case, the main win is that it flushes out the dead addresses and configuration right away instead of waiting for them to time out ⏰
Simple DNA supports addresses configured with either IPv6 Stateless Address Autoconfiguration [RFC4862] or DHCPv6 [RFC3315]. It does not support manually configured addresses, since those aren't widely used and can cause unpredictable results and/or aggressive probing behavior (see Appendix A) 🙅♀️
1.3. Link Identification Model 🔗
Earlier ways of Detecting Network Attachment, like the procedure defined in [DNA-PROTOCOL], checked whether the host was still connected to the same link. If it was, everything about that link, like its routers, prefixes, and config parameters, was treated as valid 👑
Simple DNA takes a different route. It probes each previously known router to decide whether to use the information it learned from THAT router. This lets Simple DNA probe routers it learned from multiple earlier attachments, which makes moving around a known set of links way smoother 🧚
1.4. DNA Overview 🧭
Hosts do Detecting Network Attachment after they see a link-layer "up" indication ✨ The host uses a mix of unicast Neighbor Solicitations (NSs) and multicast Router Solicitations (RSs) to find out whether previously encountered routers are on the link. If they are, the host can reuse the existing config. If they aren't, then IPv6 Stateless Address Autoconfiguration and/or DHCPv6 handles configuration 🎀
Hosts running Simple DNA may also send DHCPv6 packets, as described in Section 5.5.4. Simple DNA doesn't change the DHCPv6 protocol or its state machine, so DHCPv6 works exactly as it always has 🫶
Routers that follow the standard neighbor discovery procedure described in [RFC4861] delay the router advertisement (RA) by a random period between 0 and MAX_RA_DELAY_TIME (defined to be 500 ms), as described in Section 6.2.6 of [RFC4861]. On top of that, RAs sent to the all-nodes multicast address are rate limited to no more than one advertisement every MIN_DELAY_BETWEEN_RAS (defined to be 3 seconds). In the absence of any packet loss, that adds up to a worst-case delay of 3.5 seconds 🥲
Hosts running Simple DNA can detect a previously encountered router using unicast Neighbor Solicitations. So when a host with a valid config returns to a link it's seen before, RA delays won't hold up configuration as long as the NS probing works 🙌 But when a host attaches to a link for the first time, or it doesn't have a valid IP address on the link, it has to wait for an RA for stateless autoconfiguration. In those cases, RA delays can be significant and may cause service disruption 😭
1.5. Working Assumptions 📝
A few assumptions about the network environment hold all of this together:
- The combination of the link-layer address and the link-local IPv6 address of a router is unique across links.
- Hosts receive indications when a link layer comes up. Without this, they would not know when to commence the DNA procedure.
If these assumptions don't hold, host change detection systems won't work optimally. They might occasionally detect change spuriously or experience some delay in Detecting Network Attachment. Those delays will be no longer than the ones caused by following the standard neighbor discovery procedure described in [RFC4861] 🌸
2. Requirements Notation 💜
The big BCP 14 key words in this document, "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL", are to be interpreted as described in [RFC2119] 🤓
3. Terminology ✨
Okay bestie, let's lock in the vocab first 🎀 These terms show up everywhere in Simple DNA, so you need them down cold 💅
+---------------------+---------------------------------------------+
| Term | Definition |
+---------------------+---------------------------------------------+
| Valid IPv6 address | An IPv6 address configured on the node that |
| | has a valid lifetime greater than zero. |
| | |
| Operable IPv6 | An IPv6 address configured on the node that |
| address | can be used safely on the current link. |
| | |
| Router identifier | Identifier formed using the link-local |
| | address of a router along with its |
| | link-layer address. |
| | |
| D-Flag | Flag indicating whether the address was |
| | obtained using Stateless Address |
| | Autoconfiguration (SLAAC) or DHCPv6. If it |
| | is set to 0, then SLAAC was used to |
| | configure the address. If it is set to 1, |
| | then DHCPv6 was used to configure the |
| | address. |
| | |
| O-Flag | Flag indicating whether the address is |
| | operable. If it is set to 0, the address |
| | is inoperable. If it is set to 1, the |
| | address is operable. |
| | |
| S-Flag | Flag indicating whether SEND [RFC3971] was |
| | used in the Router Advertisement that |
| | resulted in the creation/modification of |
| | this SDAT entry. If it is set to 0, then |
| | SEND was not used. If it is set to 1, then |
| | SEND was used. |
| | |
| Candidate Router | A router address in the SDAT that is |
| Address | associated with at least one valid address. |
| | |
| Candidate Router | A set of router addresses that has been |
| Set | identified for NS-based probing. |
+---------------------+---------------------------------------------+
Table 1: Simple DNA Terminology4. The Simple DNA Address Table (SDAT) 🦋
To pull off the procedure in this document, the host has to keep a data structure called the Simple DNA address table (SDAT) 📋 It's needed for every interface where the host does Simple DNA. Each SDAT entry is indexed by the router identifier (the router's link-local address + its link-layer address) and has at least the parameters below. Fields tagged [S] are for addresses made with SLAAC, [D] is for addresses from DHCPv6, and [S+D] covers both 🫶
[S+D]Link-local IPv6 address of the router(s)[S+D]Link-layer (MAC) address of the router(s)[S+D]Flag saying whether the address came from SLAAC or DHCPv6 (theD-Flag)[S+D]IPv6 address and its related params, like valid lifetime, preferred lifetime, etc.[S]Prefix the address was formed from[S]Flag saying whether SEND was used (theS-Flag)[D]DHCP-specific info for when DHCPv6 [RFC3315] was used to get the address. This includes the DUID, the IAID, a flag for IA_NA/IA_TA, and config info like DNS server address, NTP server address, etc.[S+D]Flag saying whether the address is operable (theO-Flag)
5. Host Operations ⭐
When the host connects to a new point of attachment, it runs the Detecting Network Attachment procedure to check whether its existing addressing and config info still work 🔍
5.1. On Receipt of a Router Advertisement 📡
So a Router Advertisement shows up and the router identifier isn't in the SDAT yet. The host processes the RA as specified in Section 6.3.4 of [RFC4861], and then it does some extra stuff too. If the RA is protected by SEND, the S-Flag MUST be set to 1 in the SDAT entries created or modified by this RA 🔒
- The host configures addresses out of the autoconfigurable prefixes advertised in the RA, as specified in [RFC4862]. The host MUST add an SDAT entry (indexed by this router identifier) for each such address the host configures.
- The host might have already configured addresses out of the autoconfigurable prefixes advertised in the RA. This could be a result of receiving the prefix in an RA from another router on the same link. The host MUST add an SDAT entry (indexed by this router identifier) for each such address the host had already configured.
- The host might have DHCPv6-assigned addresses that are known to be operable on the link. The host MUST add an SDAT entry (indexed by this router identifier) for each such DHCPv6 address.
5.2. After Assignment of a DHCPv6 Address 🎁
Once a DHCPv6 server hands the host an address, the host has to tie it to the routers on the link. The host MUST create one SDAT entry for each of the on-link routers associated with the DHCPv6-assigned address.
5.3. Steps Involved in Detecting Link Change 🧩
Basic network attachment detection has three steps:
- Link-layer indication
- Sending of neighbor discovery probes
- Response gathering and assessment
We'll break each one down below 👇
5.4. Link-Layer Indication 🔌
To kick off detection, the host typically needs a link-layer indication that the medium has become available [RFC4957]. Once that indication arrives, the host MUST mark all currently configured (non-tentative) IP addresses as inoperable until the change detection process completes. It MUST also set all Neighbor Cache (NC) entries for the routers on its Default Router List to STALE. This helps it grab a new default router faster if it's landed on a link it hasn't visited before 🏃
5.5. Sending Neighbor Discovery probes 📨
5.5.1. Sending Router Solicitations 🙋
When a host gets a link-layer "up" indication, it SHOULD immediately send a Router Solicitation (as specified in Section 6.3.7 of [RFC4861]). The Router Solicitation goes to the all-routers multicast address, using a link-local address as the source address [RFC4861]. Even if the host has more than one valid IPv6 address, it MUST send only one router solicitation, using a valid link-local address as the source address.
5.5.2. Sending Neighbor Solicitations 🎯
The host walks through the SDAT to pick out candidate routers for NS-based probing. Each router in the SDAT that has at least one valid address gets added to the candidate router set exactly once. For each router in the candidate router set, the host MUST send a unicast Neighbor Solicitation to the router's link-local address it got from the SDAT lookup. The host MUST set the link-layer destination address in each of these neighbor solicitations to the link-layer address of the router stored in the SDAT. The host MUST NOT send unicast Neighbor Solicitations to a router that isn't associated with a valid address in the SDAT. If at least one SDAT entry for a given router had the S-Flag set, the host SHOULD use SEND to secure the NS probe being sent to that router. Lowkey important stuff 🔐
5.5.3. Concurrent Sending of RS and NS Probes ⚡
The host SHOULD send the Neighbor-Solicitation-based unicast probes in parallel with the multicast Router Solicitation. Since sending NSs is just an optimization, doing the NSs and the RS in parallel means the procedure doesn't run slower than it would if it only used a Router Solicitation.
NOTE: A Simple DNA implementation SHOULD limit its NS-based probing to at most six previously seen routers. 🚨
5.5.4. Initiating DHCPv6 Exchange 🔁
When the link-layer "up" indication arrives, the host starts a DHCPv6 exchange (with the timing and protocol specified in [RFC3315]). The goal is to verify whether the addresses and configuration obtained using DHCPv6 are still usable on the link. Heads up: DHCPv6, as specified today, only tries to confirm addresses obtained on the most recently attached link 🙈
5.6. Contents of the Neighbor Discovery Messages 📦
5.6.1. Neighbor Solicitation Messages 💌
This section describes what the neighbor solicitation probe messages look like during the probing procedure.
Source Address: A link-local address assigned to the
probing host.
Destination Address: The link-local address of the router being
probed as learned from the SDAT.
Hop Limit: 255
ND Options:
Target Address: The link-local address of the router being
probed as learnt from the SDAT.
Link-Layer Header:
Destination Address: The link-layer (MAC) address of the router
being probed as learnt from the SDAT.The probing node SHOULD include the source link-layer address option in the probe messages.
5.6.2. Router Solicitation Messages 📬
This section describes what the router solicitation probe message looks like during the probing procedure.
Source Address: A link-local address assigned to the
probing host.
Destination Address: The all-routers multicast address.
Hop Limit: 255The probing node SHOULD NOT include the source link-layer address option in the probe messages.
5.7. Response Gathering 🕵️
5.7.1. Receiving Neighbor Advertisements 🥰
When a Neighbor Advertisement comes back from a router in response to an NS probe, the host MUST verify that both the IPv6 and link-layer (MAC) addresses of the router match the expected values before using the configuration tied to the detected network (prefixes, MTU, etc.). The host MUST then go through the SDAT and mark the addresses (both SLAAC and DHCPv6 acquired) associated with the router as operable.
5.7.2. Receiving Router Advertisements 📣
On receiving a Router Advertisement, the host MUST go through the SDAT and mark all the addresses associated with the router (both SLAAC and DHCPv6 acquired) as inoperable. The host MUST then process the Router Advertisement as specified in Section 6.3.4 of [RFC4861].
5.7.3. Conflicting Results 🥊
5.7.3.1. Conflicting Results between RS and NS Probes
okay so, if the NS/NA answer from a router and the RS/RA answer from that same router disagree, the RS/RA result wins 💅. If the NA was secured with SEND but the RA wasn't, the host MUST wait for SEND_NA_GRACE_TIME to see if a SEND-secured RA shows up 👀. If that never happens, then the NS/NA conclusions are the ones that count 🫶.
5.7.3.2. Conflicting Results between DHCPv6 and NS Probes
when the NS/NA answer for a DHCPv6-assigned address and the DHCPv6 exchange don't agree, the DHCPv6 result is definitive 🎀. no debate, periodt 💖.
5.8. Further Host Operations
what happens next depends on whether the host has reconnected to a network it visited before 🦋.
once the host has confirmed that its router is reachable with an NS/NA pair, it does these things:
- The host SHOULD rejoin any solicited nodes' multicast groups for addresses it continues to use. 🌸
- The host SHOULD select a default router as described in Section 6.3.6 of [RFC4861]. 👑
if the host figured out that it reattached to a link it's been on before, it SHOULD NOT perform duplicate address detection on the addresses that were confirmed to be operable. they already work, bestie ✨.
if the NS-based probe with a router didn't finish, or if the RS-based probe on that same router finished with different prefixes than the ones in the SDAT, the host MUST begin address configuration techniques, as indicated in a received Router Advertisement [RFC4861] [RFC4862]. 🍓
5.9. On Connecting to a New Point of Attachment
a host usually keeps SDAT entries from a bunch of networks it visited before 🧚. when it attaches to a network it has never seen, it MAY need to discard some of the older SDAT entries. that's just housekeeping ✨.
5.10. Periodic Maintenance of the SDAT
the host SHOULD keep its SDAT table tidy by removing entries when the valid lifetime for the prefix and address runs out. that's the same moment the prefix gets removed from the Prefix List in [RFC4861] 🕰️. the host SHOULD also remove a router from an SDAT entry when that router stops advertising a particular prefix. 🙈
if three RAs in a row from a particular router don't include a prefix, then the router should be removed from the matching SDAT entry. and if a router starts advertising a prefix that already has an SDAT entry, then that router should be added to that entry 🦋. main character energy for the table, honestly 💅.
5.11. Recommended Retransmission Behavior
okay this part is so logical 🧠. when the NS probe doesn't complete, it usually means the host isn't attached to the network whose configuration is being tested. so there's typically not much point in aggressively retransmitting unicast neighbor solicitations that don't get a response 😭.
when unicast Neighbor Solicitations and Router Solicitations get sent in parallel, one strategy is to give up on retransmitting Neighbor Solicitations and only retransmit Router Solicitations or DHCPv6 messages. to cut down on the fighting between unicast NSs, RSs, and DHCPv6 retransmissions, a DNAv6 implementation that does retransmit may use the retransmission strategy from the DHCPv6 specification [RFC3315], scheduling DNAv6 retransmissions between Router Solicitations or DHCPv6 retransmissions 🌈.
if a response comes back to any unicast Neighbor Solicitation, any pending retransmissions of that same NS MUST be canceled 🛑. a Simple DNA implementation SHOULD NOT retransmit a Neighbor Solicitation more than twice ✋. and to add some damping when there are spurious link-up indications, the host SHOULD NOT perform the Simple DNA procedure more than once a second ⏱️.
6. Pseudocode for Simple DNA ✨
okay here's the pseudocode, and it's giving clean 🍓:
/* Link-up indication received on INTERFACE */
/* Start Simple DNA process */
/* Mark all addresses as inoperable */
Configured_Address_List=Get_Address_List(INTERFACE);
for each Configured_Address in Configured_Address_List
{
if (Get_Address_State(Configured_Address)!=AS_TENTATIVE)
{
Set_Address_State(Configured_Address,AS_INOPERABLE);
}
}
/* Mark all routers' NC entries as STALE to speed up */
/* acquisition of new router if link change has occurred */
for each Router_Address in DEFAULT_ROUTER_LIST
{
NCEntry=Get_Neighbor_Cache_Entry(Router_Address);
Set_Neighbor_Cache_Entry_State(NCEntry,NCS_STALE);
}
/* Thread A : Send Router Solicitation */
RS_Target_Address=FF02::2;
RS_Source_Address=Get_Any_Link_Local_Address(INTERFACE);
Send_Router_Solicitation(RS_Source_Address,RS_Target_Address);
/* Thread B : Send Neighbor Solicitation(s) */
Previously_Known_Router_List=Get_Router_List_from_SDAT();
NS_Source_Address=Get_Any_Link_Local_Address(INTERFACE);
for each Router_Address in Previously_Known_Router_List
{
if (Get_Any_Valid_Address_from_SDAT(Router_Address))
{
Send_Neighbor_Solicitation(NS_Source_Address,
Router_Address.L3_Address,
Router_Address.L2_Address);
}
}
/* Thread C : Response collection of RAs */
/* Received Router Advertisement processing */
/* Only for RAs received from routers in the SDAT */
L3_Source=Get_L3_Source(RECEIVED_MESSAGE);
L2_Source=Get_L2_Source(RECEIVED_MESSAGE);
SDAT_Entry_List=Get_Entries_from_SDAT_L2L3(L3_Source,L2_Source));
/* Mark all the addresses associated with the router as inoperable */
for each SDAT_Entry in SDAT_Entry_List
{
Set_Address_State(SDAT_Entry,AS_INOPERABLE);
}
/* Ignore further NAs from this router */
/* after delaying for x milliseconds */
Add_Router_to_NA_Ignore_List(L3_Source,SEND_NA_GRACE_PERIOD);
/* Perform Standard RA processing as per RFC 4861 / RFC 4862 */
/* Thread D : Response collection of NAs */
/* Received Neighbor Advertisement processing */
/* Only for NAs received as response to DNA NSs */
L3_Source=Get_L3_Source(RECEIVED_MESSAGE);
L2_Source=Get_L2_Source(RECEIVED_MESSAGE);
if (Is_Router_on_NA_Ignore_List(L3_Source)) {
/* Ignore message and wait for next message */
continue;
}
SDAT_Entry_List=Get_Entries_from_SDAT_L2L3(L3_Source,L2_Source));
for each SDAT_Entry in SDAT_Entry_List
{
/* Address is operable. */
Set_Address_State(SDAT_Entry,AS_OPERABLE);
/* Configure on Interface */
}Figure 1: Pseudocode for Simple DNA
NOTE: This section does not include any pseudocode for sending of the DHCPv6 packets since the DHCPv6 exchange is orthogonal to the Simple DNA process. 🙃
7. Constants 🌟
SEND_NA_GRACE_TIME- Definition: An optional period to wait after Neighbor Solicitation before adopting a non-SEND RA's link change information. ⏳
- Value: 40 milliseconds
8. Relationship to DNAv4 🦋
DNAv4 [RFC4436] has its own set of steps that optimize the common case of reattaching to an IPv4 network you've been on before, by trying to reuse an earlier configuration that's still valid. this document has the same goal as DNAv4, which is cutting the handover latency when you move between points of attachment 🏃♀️, but the steps it takes to get there are different. another difference is that this document also supports stateless autoconfiguration of addresses, on top of addresses configured with DHCPv6 💜.
9. Security Considerations 🔐
okay this section is serious, bestie 😤. a host may receive Router Advertisements from non-SEND devices after it gets a link-layer indication. it's necessary to figure out quickly whether a host has moved to another network, but the host's current secured SEND [RFC3971] router information must not be replaced by an attacker who spoofs an RA and claims to change the link 🚨.
so the host SHOULD send a Neighbor Solicitation to the existing SEND router upon link-up indication, as described above in Section 5.4. the host SHOULD then make sure that unsecured router information doesn't cause the deletion of existing SEND state within MIN_DELAY_BETWEEN_RAS, so that a SEND router that is still there has time to respond 🫣.
if the current default router is a SEND-secured router, the host SHOULD wait SEND_NA_GRACE_TIME after transmission before adopting a new default router ⚠️.
even when SEND signatures on RAs are used, it may not be immediately clear whether the router is authorized to make those advertisements. so a host SHOULD NOT treat such devices as secure until and unless authorization delegation discovery is successful 🛑.
Unless SEND or another form of secure address configuration is used, the DNA procedure by itself does not provide positive, secure authentication of the router(s) on the network, or authentication of the network itself. That's the kind of assurance you'd get from, for example, mutual authentication at the link layer 💀. so when that assurance isn't available, the host MUST NOT make any security-sensitive decisions based on the DNA procedure alone. in particular, it MUST NOT decide that it has moved from an untrusted network to a trusted one, and it MUST NOT make any security decisions that depend on that transition having happened 🚫.
10. Acknowledgments 🫶
this document came out of a discussion the authors had with Bernard Aboba, Thomas Narten, Erik Nordmark, and Dave Thaler at IETF 69 🎀. the authors want to thank them for clearly laying out the requirements of the solution, the goals it needed to hit, and for helping explore the solution space 🌸. the authors also want to thank the authors and editors of the complete DNA specification for laying out the overall problem space and solutions 📚. they'd like to thank Jari Arkko for driving the evolution of a simple, probabilistic DNA solution 👑. and a big group thank-you to Bernard Aboba, Thomas Narten, Jari Arkko, Sathya Narayan, Julien Laganier, Domagoj Premec, Jin Hyeock-Choi, Alfred Hoenes, Frederic Rossi, Ralph Droms, Ted Lemon, Erik Nordmark, Lars Eggert, Brian Carpenter, and Yaron Sheffer for reviewing the document and leaving valuable comments that moved it forward 💖✨.
11. References 📖
11.1. Normative References
[RFC2119]Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.[RFC3315]Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.[RFC3971]Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.[RFC4861]Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
11.2. Informative References 📚
These are the extra reading picks if you want the full backstory 🤓
[DNA-PROTOCOL] Narayanan, S., Ed., "Design Alternative for Detecting
Network Attachment in IPv6 Networks (DNAv6 Design
Alternative)", Work in Progress, November 2009.
[RFC4436] Aboba, B., Carlson, J., and S. Cheshire, "Detecting
Network Attachment in IPv4 (DNAv4)", RFC 4436, March
2006.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6
Stateless Address Autoconfiguration", RFC 4862,
September 2007.
[RFC4957] Krishnan, S., Montavont, N., Njedjou, E., Veerepalli,
S., and A. Yegin, "Link-Layer Event Notifications for
Detecting Network Attachments", RFC 4957, August
2007.Appendix A. Issues with Confirming Manually Assigned Addresses ✨
Okay so DNAv4 [RFC4436] does support verifying manually assigned addresses 🤔, but honestly this feature has not been widely implemented or used. Confirming manual addresses with Simple DNA comes with two big issues, bestie 💀
- Issue one: retransmissions 🔁. When the probes are for DHCPv6 or SLAAC addresses, there is no need to aggressively retransmit lost probes. Why? Because the address configuration just falls back to vanilla DHCPv6 or SLAAC, and the host will eventually get an address anyway 🫶. That is NOT the vibe with manually assigned addresses. If the probes get lost, the host could end up with no addresses at all 😭. So aggressive retransmissions are necessary here.
- Issue two: moving between networks 🏃♀️. Picture a host moving between a network that uses manual addressing (let's call it
NET1) and one that uses dynamic addressing, either stateless autoconfiguration or DHCPv6 (let's call itNET2) 🌈. Since the host can get a dynamic address in some situations, it needs to send Simple DNA probes and might also run a DHCPv6 exchange. Now say the host moves toNET1, the NS probes get lost, and no RA shows up either 🙈. The host can't confirm it attached toNET1, so it can't confirm it should use the manual configuration for that network. If DHCPv6 is enabled onNET1, the host could mistakenly grab a dynamic address and configuration instead of using the manual one 💅. To stop this, Simple DNA probing has to keep going even after the DHCPv6 exchange finishes, and DNA probes need to take precedence over DHCPv6. Yes, that's a plot twist, and it goes against the advice in Section 5.7.3 🔥.
Given all of that, it is NOT RECOMMENDED to use manual addressing with Simple DNA 🚫. Main character energy belongs to the dynamic addressing crew this time 👑.
Authors' Addresses 🫶
Suresh Krishnan
Ericsson
8400 Decarie Blvd.
Town of Mount Royal, QC
Canada
Phone: +1 514 345 7900 x42871
EMail: suresh.krishnan@ericsson.com
Greg Daley
Netstar Logicalis
Level 6/616 St Kilda Road
Melbourne, Victoria 3004
Australia
Phone: +61 401 772 770
EMail: hoskuld@hotmail.comThat's the whole thing, bestie 🌈💖✨
📦 where this page comes from
- ietf: rfc6059 2010-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms