RFC 4135

Goals of Detecting Network Attachment in IPv6

📅 published August 2005, from ietf

RFC 4135: Goals of Detecting Network Attachment in IPv6 🦋

  • Network Working Group 🌸
  • Authors: JH. Choi (Samsung AIT) and G. Daley (CTIE Monash University) 💖
  • Category: Informational 📚
  • Date: August 2005 📅
  • Obsoletes / Updates: nothing is listed in this header, so it doesn't obsolete or update any other RFC 🙅‍♀️

Status of This Memo ✨

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

Copyright (C) The Internet Society (2005).

Abstract 💅

okay so, when a host makes a brand new link-layer connection, it might or might not have a valid IP configuration for Internet connectivity 🌈 it can check for a link change (aka figure out whether it actually moved to a different link), and then decide whether its IP config is still good ✨ during link identity detection, it can also gather what it needs to start a new IP configuration if the IP subnet changed 🫶 this memo calls that whole procedure Detecting Network Attachment (DNA) 🦋 DNA schemes should be precise, sufficiently fast, secure, and of limited signaling 👑

Table of Contents 🧚

   1. Introduction ....................................................2
   2. Problems in Detecting Network Attachment ........................3
      2.1. Wireless Link Properties ...................................3
      2.2. Link Identity Detection with a Single RA ...................3
      2.3. Delays .....................................................4
   3. Goals for Detecting Network Attachment ..........................5
      3.1. Goals List .................................................6
   4. Security Considerations .........................................6
   5. Acknowledgements ................................................7
   6. References ......................................................8
      6.1. Normative References .......................................8
      6.2. Informative References .....................................8

1. Introduction 🍓

okay bestie, so when a host has set up a new link-layer connection, it can send and receive some IPv6 packets on that link, including the ones used for configuration 💖 but it only has Internet connectivity when it can exchange packets with off-link destinations 🌸

When a link-layer connection gets set up or re-set up, the host might not know whether its existing IP configuration still works for Internet connectivity 🤔 a subnet change could have happened when the host switched its point of attachment 🦋

In practice, the host doesn't know which of its addresses are valid on the newly attached link 😭 it also doesn't know whether its existing default router is on this link, or whether its neighbor cache entries are valid 💀 getting each of these components right is necessary in order to send packets on and off the link ✨

To check the status of the existing configuration, a host may check whether a 'link change' has occurred 🔍 in this document, the term 'link' is as defined in RFC 2461 [1] 🎀 the notion 'link' is not identical with the notion 'subnet', as defined in RFC 3753 [2] 🧚 for example, there may be more than one subnet on a link, and a host connected to a link may be part of one or more of the subnets on the link 🌈

Today, a link change means an IP configuration change 🔥 whenever a host detects that it has stayed at the same link, it can usually assume its IP configuration is still valid 💅 otherwise, the existing one is no longer valid, and a new configuration must be acquired 💀 so, to check whether an IP configuration is still valid, all that is required is that the host checks for link change 👑

While checking for link change, a host may collect some of the info it needs for a new IP configuration, like on-link prefixes ✨ so when an IP subnet change has happened, the host can immediately start getting a new IP configuration 🚀 this may reduce handoff delay and minimize signaling 🫶

Rapid attachment detection is required for a device that changes subnet while it has ongoing sessions 🔥 this may be the case if a host is connected intermittently, is a mobile node, or has urgent data to send when it attaches to a link 😭

Detecting Network Attachment (DNA) is the process by which a host collects the appropriate information and detects the identity of its currently attached link, so it can confirm that its IP configuration is valid 🦋

DNA schemes are typically run per interface 🌸 when a host has multiple interfaces, it checks for link changes separately on each one 💖

Here's a key thing: the DNA process does not include the actual IP configuration procedure 🙈 for example, with respect to DHCP, the DNA process may determine that the host needs to get some configuration information from a DHCP server 🧚 but actually retrieving that info from a DHCP server is outside the scope of DNA 🫶

This document only looks at the DNA procedure from the IPv6 point of view, unless it explicitly says otherwise 🌈 so the term "IP" should be understood to mean IPv6, by default 💅 for the IPv4 case, refer to [7] ✨

2. Problems in Detecting Network Attachment 💀

A bunch of issues make DNA complicated 😭 first, wireless connectivity is not as clear-cut as wired connectivity 📡 second, it's hard for a single Router Advertisement (RA) message to indicate a link change 🙅‍♀️ third, the current Router Discovery specification says that routers wait a random delay of 0-.5 seconds before responding with a solicited RA ⏳ that delay can be significant and may cause service disruption 💔

Unlike in wired environments, what counts as a wireless link changes over time and space 🌊 wireless links don't have clear boundaries 🫧 this is shown by the fact that a host may be within the coverage area of multiple (802.11) access points at the same time 🙈 on top of that, connectivity on a wireless link can be super volatile, which can make link identity detection hard 😵‍💫 for example, it takes time for a host to check for link change 🕰️ if the host ping-pongs between two links and doesn't stay long enough on a given link, it can't finish the DNA procedure 🏃‍♀️💨

Usually, a host gets the info it needs for IP configuration from RA messages 📨 based on the current definition [1], it's hard for a host to check for link change when it receives a single RA 😤

To detect link identity, a host may compare the information in an RA, such as router address or prefixes, with the info it has stored locally 🗂️

The host may use received router addresses to check for link change 🧐 however, the router address in the source address field of an RA is of link-local scope, so its uniqueness isn't guaranteed outside a link 🫣 if two different router interfaces on different links happen to have the same link-local address, the host can't detect that it moved from one link to another by checking the router address in RA messages 💀

The set of all global prefixes assigned to a link can represent link identity 💜 the host may compare the prefixes in an incoming RA with the ones it currently has stored 🔎 but an unsolicited RA message can omit some prefixes for convenience [1], and it's not easy for a host to get and keep all the prefixes on a link with certainty 😩 so neither the absence of a previously known prefix nor the presence of a previously unknown prefix in the RA guarantees that a link change has occurred 🙃

Heads up: a missing or brand-new prefix in one RA is NOT proof that the link changed. Don't jump to conclusions, bestie 🙅‍♀️

2.3. Delays ⏳

The following issues cause DNA delay that may result in communication disruption 😬

1) Delay for receiving a hint 🎯

A hint is an indication that a link change might have occurred 👀 the hint itself doesn't confirm a link change, but it starts the appropriate DNA procedures to detect the identity of the currently attached link 🔍

Hints come in various forms and differ in how they indicate a possible link change 🌈 they can be link-layer event notifications [6], the lack of an RA from the default router, or the receipt of a new RA 📬 the time taken to receive a hint also varies ⏱️

As soon as a new link-layer connection has been made, the link layer may send a link-up notification to the IP layer 🔔 a host may interpret the new link-layer connection as a hint for a possible link change 💡 with link-layer support, a host can receive such a hint almost instantly ⚡

Mobile IPv6 [4] defines the use of RA Interval Timer expiry as a hint 🧚‍♀️ a host keeps monitoring for periodic RAs and interprets the lack of them as a hint 🕵️‍♀️ it may implement its own policy to decide how many missing RAs are needed before it treats that as a hint 📊 so the delay depends on the Router Advertisement interval ⏰

Without schemes such as those above, a host must receive a new RA from a new router to detect a possible link change 😤 the detection time then also depends on the Router Advertisement frequency 📈

Periodic RA beaconing transmits packets within an interval that varies randomly between MinRtrAdvInterval and MaxRtrAdvInterval seconds 🎲 because a network attachment is unrelated to the advertisement time on the new link, hosts are expected to arrive, on average, halfway through the interval 🫠 this is approximately 1.75 seconds with Neighbor Discovery [1] advertisement rates 🌸

2) Random delay execution for RS/RA exchange 🎲

Router Solicitation and Router Advertisement messages are used for Router Discovery 📮 according to [1], it is sometimes necessary for a host to wait a random amount of time before it may send an RS, and for a router to wait before it may reply with an RA ⏳

According to RFC 2461 [1], the following apply:

  • Before a host sends an initial solicitation, it SHOULD delay the transmission for a random amount of time between 0 and MAX_RTR_SOLICITATION_DELAY (1 second). 🙏
  • Furthermore, any RA sent in response to a Router Solicitation MUST be delayed by a random time between 0 and MAX_RA_DELAY_TIME (0.5 seconds). 🫶

3. Goals for Detecting Network Attachment 🎯

The DNA working group was chartered to define an improved scheme for detecting IPv6 network attachment 🥰 in this section, we define the goals that any such solution should aim to meet 💖

DNA solutions should correctly determine whether a link change has occurred ✅ they should also be fast enough that there is no service disruption or at most minimal disruption ⚡ and they should neither flood the link with related signaling nor introduce new security holes 🙅‍♀️🔒

When defining new solutions, it's necessary to look into the usage of the available tools: Neighbor Solicitation/Neighbor Advertisement messages, RS/RA messages, link-layer event notifications [6], and other features 🧰 this will allow a precise description of procedures for efficient DNA Schemes 🌈

Part 2 is coming next with the Goals List, Security Considerations, Acknowledgements, and References, so stay tuned, bestie 🎀✨

3.1. Goals List 💅

Okay bestie, here's the wishlist for DNA schemes 🧚 Ten goals, no cap.

G1 okay so DNA schemes should figure out which link they're attached to 🔍, so they can check whether the IP configuration they already have is still valid 🎀. They should also notice whether a link change has happened and, if it has and they need one, kick off the process of getting a new configuration 💖.

G2 DNA schemes should detect the identity of an attached link with minimal latency, lest there should be service disruption 😭. Nobody wants the connection going dark mid-stream 💀.

G3 if a host hasn't actually changed links 🙅‍♀️, DNA schemes should not falsely assume that it did, and an IP configuration change should not happen either 🌸.

G4 DNA schemes should not cause undue signaling on a link 🔇. Nobody needs the whole network spammed with messages, periodt 💅.

G5 DNA schemes should make use of existing signaling mechanisms where available ♻️. Why reinvent the wheel when the wheel already exists 👑?

G6 DNA schemes should make use of signaling within the link (particularly link-local scope messages) 🏠, because communication off-link may not be achievable in the case of a link change 📵. Talking to the outside world might be impossible right after a switch, so keeping it local is the move ✨.

G7 DNA schemes should be compatible with security schemes such as Secure Neighbor Discovery [3] 🔐. Security and DNA need to be besties, not enemies 🫶.

G8 DNA schemes should not introduce new security vulnerabilities. A node that supports DNA schemes should not expose itself, or other nodes on the link, to additional man-in-the-middle, identity-revealing, or denial-of-service attacks 🚨. This one is giving serious main character energy in the worst way 😤, so guard it hard 🛡️.

G9 nodes (such as routers or hosts) that support DNA schemes should work appropriately with unmodified nodes that don't 🤝. Be inclusive, even to the old-school devices 🍓.

G10 hosts, especially in wireless environments, may perceive routers as reachable on different links 📡. DNA schemes should take into consideration the case where a host is attached to more than one link at the same time 🦋. Multitasking, but make it networking 🧠.

4. Security Considerations ✨

Okay, this part is serious, so let's go 🥺. The DNA process is super intertwined with the Neighbor Discovery protocol [1], and its trust model and threats have a lot in common with the ones in RFC 3756 [5] 🕸️. Nodes connected over wireless interfaces may be especially vulnerable to jamming, monitoring, and packet-insertion attacks 📻💀.

With unsecured DNA schemes, it is inadvisable for a host to adjust its security based on which network it believes it is attached to 🚫. For example, it would be inappropriate for a host to switch off its personal firewall just because it thinks it's on the home network 🏠🔥. Not that deep, not that trusting 🙅‍♀️.

Even when authoritative information (routing and prefix state) is advertised, wireless network attackers may still stop soliciting nodes from receiving packets 🙈. This may cause unnecessary IP configuration changes in some devices 😩. Attacks like this may also be used to push a host toward a particular configuration or network access 👀.

Devices that receive confirmations of reachability (for example, from upper-layer protocols) should know that, unless these indications are sufficiently authenticated, an attacker may falsely make reachability look real 🎭. Similarly, even if a reachability test is known to come from a trusted source, it should be ignored for reachability confirmation if the packets are not fresh or have been replayed 🔁. This can shrink the window of opportunity for attackers who replay otherwise legit data ⏳.

It may be dangerous to receive link-change notifications from the link layer and the network layer if they come from devices that aren't sufficiently authenticated 🚩. In particular, a notification that authentication has completed at the link layer does not necessarily mean a security relationship exists at the network layer 💔. Additional authentication may be required at the network layer before changing the IP configuration 🔐✨.

5. Acknowledgements 🫶

Erik Nordmark contributed a lot to the work that came before this document 👑. Ed Remmell's comments on the inconsistency of RA information were super illuminating 💡. The authors wish to express appreciation to Pekka Nikander for valuable feedback 🌷. We gratefully acknowledge the generous help we got from Shubhranshu Singh in clarifying the structure of the arguments 🧚. Thanks also to Brett Pentland, Nick Moore, Youn-Hee Han, JaeHoon Kim, Alper Yegin, Jim Bound, and Jari Arkko for their contributions to this document 💖.

6. References 📚

6.1. Normative References

  • [1] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
  • [2] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004.
  • [3] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.

6.2. Informative References

  • [4] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
  • [5] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, May 2004.
  • [6] Yegin, A., "Link-layer Event Notifications for Detecting Network Attachments", work in progress, July 2005.
  • [7] Aboba, B., "Detecting Network Attachment (DNA) in IPv4", work in progress, June 2005.

Authors' Addresses 🎀

JinHyeock Choi
Samsung AIT
Communication & N/W Lab
P.O.Box 111 Suwon 440-600
KOREA

Phone: +82 31 280 9233
EMail: jinchoe@samsung.com


Greg Daley
CTIE Monash University
Centre for Telecommunications and Information Engineering
Monash University
Clayton 3800 Victoria
Australia

Phone: +61 3 9905 4655
EMail: greg.daley@eng.monash.edu.au

Copyright (C) The Internet Society (2005).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights 📝.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE 🙃.

Intellectual Property 🔍

The IETF takes no position on the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or on whether any license under such rights might or might not be available 🤷‍♀️. It also doesn't claim to have made any independent effort to identify such rights. Info about how rights work for RFC documents lives in BCP 78 and BCP 79 📖.

Copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the result of an attempt to get a general license or permission for implementers or users of this specification can be found in the IETF online IPR repository at http://www.ietf.org/ipr 🔗.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology required to implement this standard 🫶. Send that info to the IETF at ietf-ipr@ietf.org 💌.

Acknowledgement 🌈

Funding for the RFC Editor function is currently provided by the Internet Society 💜.

📦 where this page comes from