RFC 4651
A Taxonomy and Analysis of Enhancements to Mobile IPv6 Route Optimization
RFC 4651: A Taxonomy and Analysis of Enhancements to Mobile IPv6 Route Optimization 🦋
okay bestie, let's get into this one 💅 it's an Informational RFC from February 2007, written by C. Vogt (Universitaet Karlsruhe (TH)) and J. Arkko (Ericsson Research NomadicLab). It's a research doc, not a standard, so it's giving "here are ideas, go explore" energy 🌸 The title block doesn't list anything it obsoletes or updates, so it's standing on its own ✨
Status of This Memo ✨
ngl this part is super boring, but it's the legal-ish bit 🙈 This memo gives information to the Internet community. It does not specify an Internet standard of any kind, and distribution of it is unlimited 🌈
Copyright Notice 🎀
Copyright (C) The IETF Trust (2007).
IESG Note 💜
this one's important: the RFC is a product of the Internet Research Task Force (IRTF) and is not a candidate for any level of Internet Standard 😭 The IRTF publishes research and development results about the Internet, and those results might not be suitable for deployment, so don't just ship this stuff to production bestie 💀
Abstract 🦋
this doc looks at ways to make Mobile IPv6 Route Optimization better, using ideas that already exist. The goal is to push further research forward 🚀 It came out of the IP Mobility Optimizations (MobOpts) Research Group, so it's very much a group project 🫶
Table of Contents 🌸
1. Introduction ....................................................3
1.1. A Note on Public-Key Infrastructures .......................4
1.2. A Note on Source Address Filtering .........................5
2. Objectives for Route Optimization Enhancement ...................7
2.1. Latency Optimizations ......................................8
2.2. Security Enhancements ......................................8
2.3. Signaling Optimizations ....................................9
2.4. Robustness Enhancements ....................................9
3. Enhancements Toolbox ............................................9
3.1. IP Address Tests ..........................................10
3.2. Protected Tunnels .........................................10
3.3. Optimistic Behavior .......................................11
3.4. Proactive IP Address Tests ................................11
3.5. Concurrent Care-of Address Tests ..........................12
3.6. Diverted Routing ..........................................13
3.7. Credit-Based Authorization ................................14
3.8. Heuristic Monitoring ......................................17
3.9. Crypto-Based Identifiers ..................................18
3.10. Pre-Configuration ........................................19
3.11. Semi-Permanent Security Associations .....................20
3.12. Delegation ...............................................21
3.13. Mobile Networks ..........................................21
3.14. Location Privacy .........................................22
4. Discussion .....................................................22
4.1. Cross-Layer Interactions ..................................23
4.2. Experimentation and Measurements ..........................23
4.3. Future Research ...........................................24
5. Security Considerations ........................................24
6. Conclusions ....................................................25
7. Acknowledgments ................................................25
8. References .....................................................26
8.1. Normative References ......................................26
8.2. Informative References ....................................261. Introduction 🧚
okay so, Mobile IPv6 is what lets mobile nodes keep their active connections and app sessions while switching from one IPv6 address to another 📱✨ The main spec, RFC 3775 [1], brings in a "home agent" that stands in for a mobile node at its permanent "home address" 🏠 When the mobile node roams, it connects to the home agent through a bidirectional tunnel, and from its local "care-of address" it can talk as if it were still at home 💅 It keeps the home agent updated on its current care-of address using IPsec-protected signaling messages [40] 🔐
now, if the correspondent node doesn't have proper mobility support, it talks to the mobile node's home address, so every single data packet gets routed through the home agent 😩 This mode, Bidirectional Tunneling, makes packet-propagation delays worse 🐢 So RFC 3775 also defines a Route Optimization mode, which lets the two peers talk on the direct path ⚡ The catch is that the correspondent node has to be able to cache a binding between the mobile node's home address and its current care-of address 🧠 The real challenge is that there's usually no administrative relationship between the mobile node and the correspondent node, so you can't just assume trust 🤔 So how do the two of them authenticate and authorize the signaling messages they swap? 👀
Mobile IPv6 solves this by checking a routing property of the mobile node 🛣️ Specifically, the mobile node has to be reachable at both its home address and its current care-of address, meaning it must prove it received a home keygen token and a care-of keygen token, respectively 🔑 This is called the "return-routability procedure" 🎀 It happens right before a mobile node registers a new care-of address with a correspondent node, and it gets repeated now and then if the mobile node hasn't moved in a while 🔁
the nice thing about return-routability is that it's lightweight and doesn't need pre-shared authentication material 💜 It also needs no state at the correspondent node 🙌 BUT, the two reachability tests can cause a handoff delay that's unacceptable for lots of real-time or interactive apps, like Voice over IP (VoIP) and video conferencing 📞😬 Also, the security return-routability gives might not be enough for security-sensitive apps 🔓 And finally, refreshing a registration at a correspondent node over and over adds hidden signaling overhead, which may stop mobile nodes from hibernating during quiet periods 🔋💀
so yeah, a bunch of enhancements for Route Optimization have been suggested 🌈 This document looks at various strategies based on those existing proposals, and it's meant to be a conceptual framework for future work, which turned out to be unavoidable for Route Optimization 🧩 Many scientists volunteered to review it, and they're all credited in Section 7 🫶 Section 2 breaks down the strengths and weaknesses of Route Optimization and finds potential objectives for enhancement 🎯 Section 3 covers the different enhancement strategies based on existing proposals ✨ Section 4 discusses the approaches and points out opportunities for more research 🔬 Section 5 and Section 6 wrap things up 🌸
this doc represents the consensus of the MobOpts Research Group 💖 Research Group members active in the specific area reviewed it, and at their chairs' request, multiple active contributors to the IETF MIP6 Working Group reviewed it thoroughly too 👑 At the time of writing, some of its ideas had been adopted by the Mobility for IP: Performance, Signaling and Handoff Optimization (mipshop) Working Group in the IETF 🙌🔥
1.1. A Note on Public-Key Infrastructures 🔐
okay this part is the spicy PKI discussion 🌶️ Mobile IPv6 Route Optimization checks a mobile node's authenticity through a routing property 🛣️ The alternative is cryptographic authentication, which needs a binding between a node's identity and some secret information 🗝️ Some proposals suggest installing shared secrets into end nodes when possible (see Section 3.10), but pre-configuration isn't an option for general Internet use because of scalability 📈❌ A Public-Key Infrastructure (PKI) doesn't need pair-wise pre-configuration 💅 Here, the secret info is the private component of a public/private-key pair, and the link between a node's identity and its private key exists indirectly, through the cryptographic properties of those key pairs plus a binding between the identity and the public key 🧠 An authority that both end nodes trust issues a certificate that makes that latter binding happen 📜
BUT, a large-scale PKI was considered unsuitable for mobility management, and here's why 🙈
- there are differing opinions on whether a PKI could scale up to hundreds of millions of mobile nodes 🤷♀️ Some people say yes, since there are already certification authorities responsible for millions of certificates 💅 But the bigger deal would be a shift in application patterns 😳 Right now, public-key crypto is only used for apps that need strong cryptographic authentication 🔐
if it were used for mobility management too, certificate checks would become mandatory for any type of app, so there'd be more checks per user 😩 Busy servers with mobility support might not be willing to spend the processing resources on that, depending on the service they provide 🖥️💀
- revoked certificates are listed on Certificate Revocation Lists (CRLs), which correspondent nodes with mobility support would have to get from certification authorities 📋 CRLs have to stay up to date, which means periodic downloads ⬇️ That, plus the act of checking a certificate against a CRL, creates overhead some correspondent nodes might not want to take on 😤
- certificate verification can take some time, which can interrupt ongoing apps ⏳ That's super disturbing from the user's perspective, especially when Route Optimization kicks in mid-session or the session is very short anyway 🙃
- the bigger a PKI grows, the more attractive it becomes as an attack target, which endangers the Internet as a whole 🚨😱
- there's little experience with using home addresses as identifiers in certificates 🤔 The home address could theoretically go into a certificate's Subject Alternate Name field, but the entities responsible for IP-address assignment and for certification are usually not the same, so coordinating the two may not be easy 🧩
so for these reasons, this document does not consider direct authentication of mobile nodes based on a PKI 🙅♀️ That said, it does evaluate certificate-based techniques that make the problems above more manageable, see Section 3.12 💜
to be continued, bestie! 🦋 part 2 is where the toolbox gets opened 🧰✨
1.2. A Note on Source Address Filtering ✨
okay so RFC 3775 uses care-of-address tests to check that a mobile node is really where it says it is 🧐 but there's another option. The mobile node's local access network can do the checking instead, with infrastructure that verifies the IP source addresses of every packet leaving the network are correct. "Ingress filtering" [38][43] does this, to the extent that it inspects the prefix of IP source addresses and makes sure they're topologically correct 🦋 Network-access providers that use ingress filtering usually deploy it in their first-hop and site-exit routers. ISPs can also filter packets coming from a downstream network 🌸
Ingress filtering might eventually replace care-of-address tests 👑 but there are still some big question marks rn:
- By definition, ingress filtering can only stop source-address spoofing from networks that actually deploy it 😭 So it needs to be widely deployed, ideally universally, to protect the whole Internet. As long as an attacker can get network access without filters, every Internet node stays vulnerable 💀
- ISPs have basically no reason to deploy ingress filtering except for being conscientious 🫶 There's no legal or regulatory requirement, and no financial motivation either. A corrupt ISP might even have a financial reason not to deploy it, if redirection-based denial-of-service (DoS) attacks using Route Optimization ever become possible and get exploited for money 🙈 Email spam had a similar problem, for example.
- Ingress filtering works best, and is easiest to configure, at the first-hop router. But since only prefixes get checked, the filters get less precise the further upstream they're enforced 🍓 This is baked into the technique itself, so the best move is checking packets as close to the originating nodes as possible, ideally in the first-hop routers themselves.
- A popular implementation of ingress filtering is "Reverse Path Forwarding" (RPF) 💅 It relies on routes being symmetric, which is often the case between edge networks and ISPs, but much less often between peering ISPs. The alternatives to RPF are either manually configured access lists or dynamic approaches that are more relaxed, and therefore less secure, than RPF [43].
- Multi-homing is another problem for ingress filtering 🌀 When a router tries to forward a packet to one ISP with a source-address prefix from a different ISP, the filters at the second ISP would block it. The IETF is looking for a way around this [39]. For instance, the packet could be tunneled to the topologically correct ISP, or source-address changes could be allowed through a locator-identifier split [45].
- Lastly, RFC 3775 defines an Alternative Care-of Address option that mobile nodes can use to carry a care-of address within a Binding Update message, outside of the IPv6 header ✨ That address isn't inspected by ingress filtering, so it would have to be verified some other way [14].
Even though these problems are expected to get solved eventually, we don't really know yet how applicable and deployable ingress filtering will be as a candidate for care-of-address verification 🤔 High investments or administrative hurdles could stop a large, ideally universal, deployment, and that would weaken Internet-wide protection, as the first bullet pointed out. So for these reasons, this document does not treat ingress filtering as a viable alternative to care-of-address tests, although things may be different in the future 🦋
2. Objectives for Route Optimization Enhancement 🎀
Wireless environments with frequently moving nodes have a bunch of salient properties that set them apart from environments with stationary nodes, or nodes that only move now and then 🌈 One big thing is how efficient mobility management is. Nodes don't really care about a few round-trip times of handoff latency if they don't change their point of IP attachment often 😌 But the negative impact a mobility protocol can have on application performance grows with the level of mobility. So to maximize user satisfaction, it's important to cut down the handoff latency the mobility protocol adds on top of delays already happening elsewhere in the network stack 💖 A related issue is robustness, since a temporary outage of mobility support can leave mobile nodes unable to keep communicating 💀
The wireless nature of data transmission also makes it potentially easier for an attacker to eavesdrop on other nodes' data, or to send data on behalf of other nodes 👀 Applications can usually authenticate and encrypt their payload if needed, but similar security measures may not be feasible for a mobility protocol's signaling packets, especially if the communicating end nodes have no pre-existing relationship 🔒
Wireless bandwidth is typically limited, so resources ought to be spent economically 💸 This matters especially for how much signaling a mobility protocol requires.
Efforts to enhance RFC 3775 Route Optimization generally aim for reduced handoff latency, higher security, lower signaling overhead, or more protocol robustness 🧚 These objectives are discussed here from a requirements perspective. The technical means of reaching them isn't considered, and neither is whether achieving them is feasible 🫶
2.1. Latency Optimizations ⚡
One important goal for improving Route Optimization is cutting handoff latencies 🏃♀️ Assuming the home-address test dominates the care-of-address test in terms of latency, a Mobile IPv6 handoff takes one round-trip time between the mobile node and the home agent for the home registration. It also takes a round-trip time between the mobile node and the home agent, plus a round-trip time between the home agent and the correspondent node, for the home-address test. And it takes a one-way time from the mobile node to the correspondent node to propagate the Binding Update message. The first packet sent to the new care-of address needs an extra one-way time to get from the correspondent node to the mobile node 📦 The mobile node can resume communications right after it sends the Binding Update message. But if it requests a Binding Acknowledgment message from the correspondent node, communications are usually delayed until that comes back 😤
These delays stack up and aren't absorbed by other delays at the IP layer or link layer 🙃 They can cause noticeable quality drops for interactive and real-time applications 📉 TCP bulk-data transfers get hit too, since long handoff latencies can lead to successive retransmission timeouts and degraded throughput 😭
2.2. Security Enhancements 🔐
The return-routability procedure was designed to give a level of security that compares to today's non-mobile Internet [46] 💅 So it protects against impersonation, denial of service, and redirection-based flooding attacks that wouldn't be possible without Route Optimization. The approach rests on the assumption that a mobile Internet can't become any safer than the non-mobile Internet 🤷♀️
Applications that need a higher security level than the return-routability procedure can provide are generally advised to use end-to-end protection, like IPsec or Transport Layer Security (TLS) 🛡️ But even then they're still vulnerable to denial of service, which is why research into stronger Route Optimization security is happening 🔍 Security enhancements may also become necessary if future technological improvements mitigate some of the existing mobility-unrelated vulnerabilities ✨
One particular issue with Route Optimization is location privacy, because route-optimized packets carry both home and care-of addresses in plaintext 🫣 A standard workaround is to fall back to Bidirectional Tunneling when location privacy is needed. Packets with the care-of address then only travel between the mobile node and the home agent, where they can be encrypted through IPsec Encapsulating Security Payload (ESP) [42] 🧁 But even Bidirectional Tunneling requires the mobile node to periodically re-establish IPsec security associations with the home agent, so it can stay untraceable through Security Parameter Indexes (SPIs) 🥹
2.3. Signaling Optimizations 📡
Route Optimization needs periodic signaling even when the mobile node isn't moving 🔁 The signaling overhead amounts to 7.16 bits per second if the mobile node communicates with a stationary node [6]. It doubles if both peers are mobile 😳 That overhead might be negligible while the nodes are actively communicating, but it can be a real issue for mobile nodes that are inactive and stay in the same place for a while 🔋 Those nodes usually prefer to go into standby mode to save battery power. Also, the periodic refreshes eat up a fraction of the wireless bandwidth that could be used more efficiently 🥺 Optimizations for reduced signaling overhead could help with these issues 💜
2.4. Robustness Enhancements 🛠️
Route Optimization could, conceptually, keep communications going during periods when the home agent is temporarily unavailable 🌤️ RFC 3775 doesn't achieve this independence, though, because the home agent plays an active role in the return-routability procedure 🙁 Appropriate enhancements could increase independence from the home agent, and that would make robust Route Optimization possible even without the home agent around 🌸
3. Enhancements Toolbox 🧰
A lot of effort has gone into improving Mobile IPv6 Route Optimization recently 🌟 Some of the proposed techniques modify the return-routability procedure, while others replace it with alternative mechanisms 🔄 Some operate end-to-end, and others introduce network-side mobility support 🌐 In most cases, it's a combination of techniques that's needed to get a complete, meaning efficient and secure, route-optimization mechanism 👑
3.1. IP Address Tests ✨
okay so RFC 3775 uses IP-address tests to make sure a mobile node is actually alive and on the path to a specific destination address 👀 There are two of them. The home-address test shows that the mobile node is the legit owner of its home address, and the care-of-address test catches spoofed care-of addresses and stops redirection-based flooding attacks 🛡️ Both tests can run in parallel, which is so efficient, bestie 💅
A home-address test should be started by the mobile node so the correspondent node can hold off on creating state until the mobile node has authenticated. The care-of-address test can conceptually be started by either side 🦋 It starts with the mobile node in RFC 3775, but with the correspondent node in [16] and [22]. The correspondent-node-driven approach makes sense when authentication happens through some other means than a home-address test, obviously 🙄
The big perks of IP-address tests are zero-configurability and not needing any ancillary infrastructure, which is giving low-maintenance icon behavior 🌸 The tea is that they can only guarantee a node is on the path to the probed address, not that the node truly owns that address 😬 BUT it doesn't open any new security threats, because the stuff an on-path attacker can do with Route Optimization is already possible on the non-mobile Internet [46]. So we're fine, fr fr 🫶
3.2. Protected Tunnels 🔐
RFC 3775 protects certain signaling messages between a mobile node and its home agent by sending them through an authenticated and encrypted tunnel 🎀 This keeps unauthorized nodes on that path from listening in, including eavesdroppers on the mobile node's wireless access network 🙈
Here's the catch: a pre-existing end-to-end security relationship between the mobile node and the correspondent node can't generally be assumed, so this protection only covers the mobile node's side 💔 If the correspondent node is immobile, the path between the home agent and the correspondent node stays unprotected. That's a path between two stationary nodes, so every type of attack a villain could wage on it is already possible on the non-mobile Internet 🦹 If the correspondent node is mobile, it has its own home agent, and only the path between the two (stationary) home agents stays unprotected ✨
3.3. Optimistic Behavior 🏃♀️
Lots of Mobile IPv6 implementations [29][31] wait to do a correspondent registration until the matching home registration has finished successfully 🐢 That's the "conservative" vibe. The "optimistic" move is to kick off the return-routability procedure at the same time as the home registration [52] 🚀 Conservative behavior avoids a pointless return-routability procedure if the home registration fails, but it costs extra handoff delay when the home registration works. Optimistic behavior saves that delay, but the return-routability procedure will be wasted if the home registration doesn't succeed 😭
Running the home registration and the return-routability procedure in parallel is totally doable within RFC 3775, but the spec doesn't let mobile nodes continue with the correspondent registration, by sending a Binding Update message to the correspondent node, until a Binding Acknowledgment message saying the home registration succeeded has come back 🙅♀️ Usually that's not a big deal, since the return-routability procedure tends to take longer than the home registration anyway. BUT some optimizations (see Section 3.4) shrink the delay from the return-routability procedure, so it's a useful upgrade to let Binding Update messages go to correspondent nodes even before the home registration has been acknowledged 🌈
The downside of optimistic behavior is that a lost, reordered, or rejected Binding Update message can make data packets get discarded 😵 Still, packet loss would hurt conservative approaches too, so the mobile node has to be ready for possibly losing these packets either way 🫠
3.4. Proactive IP Address Tests ⏰
The critical handoff phase is when the mobile node and the correspondent node can't fully talk to each other 😤 It spans the home registration and the correspondent registration, including the return-routability procedure. One way to shorten it is to do some of the signaling proactively, before the handoff 🧚 Specifically, the home-address test can be done in advance without breaking the RFC 3775 specs [52][51] ✨
To have a fresh home keygen token ready for a future handoff, the mobile node should start a proactive home-address test at least once per token lifetime, which is every 3.5 minutes ⏱️ This at most doubles the signaling overhead spent on home-address tests, since correspondent registrations have to be refreshed every 7 minutes even when the mobile node hasn't moved for a while 💅 There's also an optimization where the mobile node's local link layer can anticipate handoffs and trigger the home-address test in that case. [6] or [54] cut the frequency of home-address tests even further 🙌
Proactive care-of-address tests are only possible if the mobile node can attach to two networks at once. Dual attachment is possible if the link-layer technology allows it with a single interface [10], or if the mobile node has multiple interfaces [7] 📡
3.5. Concurrent Care-of Address Tests 🤹♀️
Without the assumption that a mobile node can attach to multiple networks at the same time, proactive care-of-address tests (done before handoff) aren't an option 🙃 So a correspondent node may instead let a mobile node put off the care-of-address test until an early, tentative binding has been registered [52][51]. Paired with a technique that gets rid of the handoff delay of home-address tests (see Section 3.4 and Section 3.9), this makes it possible to resume two-way communication early after the handoff 🏎️ The care-of address is called "unverified" during the concurrent care-of-address test, and it's called "verified" once the correspondent node has evidence that the mobile node is actually at that address ✅ A tentative binding's lifetime can be limited to a few seconds ⏳
Home-address tests must not run concurrently, though, because they exist to do authentication 🔒 They guarantee that only the legit mobile node can create or update a binding for a particular home address 💖
mobile node home agent correspondent node
| | |
| | |
|--Home Test Init------>|---------------------->|
| | |
| | |
|<----------------------|<-----------Home Test--|
| | |
| |
~~+~~ handoff |
| |
|--Early Binding Update------------------------>| -+-
|--Care-of Test Init -------------------------->| |
| | |
| | | care-of
|<----------------Early Binding Acknowledgment--| | address
|<-------------------------------Care-of Test---| | unverified
| | |
| | |
|--Binding Update------------------------------>| -+-
| |
| |
|<----------------------Binding Acknowledgment--|
| |Figure 1: Concurrent Care-of Address Tests 📊
Figure 1 shows how concurrent care-of-address tests are used in [52][51] 🎬 Right after a handoff, once the mobile node has set up a new care-of address, it sends the correspondent node an Early Binding Update message. Only a home keygen token, from a proactive home-address test, is needed to sign this message 🔑 The correspondent node creates a tentative binding for the new, unverified care-of address as soon as it gets the Early Binding Update message, and that address can be used right away 🚀 Then, once the concurrent care-of-address test is done, the mobile node sends a (standard) Binding Update message to the correspondent node 🎉 Credit-Based Authorization (see Section 3.7) stops misuse of care-of addresses while they're unverified 🛡️
3.6. Diverted Routing 🛣️
Since a home registration is faster than a correspondent registration when there are no extra optimizations, the mobile node may ask for its traffic to be routed through the home address until a new binding has been set up at the correspondent node [52][51] 🌸 How well this diverted routing works depends on the propagation properties of the routes involved, though 🤷♀️
For packets to be diverted via the home address, signaling is needed with both the home agent and the correspondent node 📨 The home agent has to be told about the new care-of address so it can correctly forward packets it intercepts at the home address. The correspondent node keeps sending packets to the old care-of address until it gets a Binding Update message saying the current binding is no longer valid and should be removed 🗑️ That request needs authentication through a home-address test so unauthorized nodes can't cause denial of service 🚫 The test can be done proactively (see Section 3.4) 💅
The mobile node may send packets via the home address as soon as it has sent the Binding Update message to the home agent. It may send outgoing packets along the direct path once a Binding Update message for the new care-of address has been sent to the correspondent node 🏃♀️
How long the correspondent node should keep sending packets to the home address depends on the propagation latency of the end-to-end path via the home agent compared with the latency of the direct path 🌍 If the former path is slow, it may be better to queue some of the packets until the correspondent registration is complete and packets can go along the direct route 🧠💜
3.7. Credit-Based Authorization ✨
okay bestie, so concurrent care-of-address tests (see Section 3.5) need protection from spoofed, unverified care-of addresses and from redirection-based flooding attacks 🚨 enter Credit-Based Authorization [50] 💅 It's built on three hypotheses:
- A flooding attacker usually wants to multiply the packets it builds for the attack, because bandwidth is plentiful for lots of juicy victims 🍓
- An attacker can always do unamplified flooding by making bogus packets itself and sending them straight to the victim 💀
- So the extra effort of setting up a redirection-based flooding attack only pays off for the attacker if amplification actually happens that way 🙄
So instead of trying to kill malicious packet redirection entirely, Credit-Based Authorization just blocks any amplification you could get out of it 🛡️ The trick is that it limits how much data a correspondent node can send to an unverified care-of address of a mobile node, based on how much data it has recently received from that mobile node 🧠 (check Section 3.5 for when a care-of address counts as verified vs. unverified.) Basically, a redirection-based flood is now no more attractive than plain direct flooding, where the attacker sends bogus packets to the victim itself. Honestly it's even less attractive, since the attacker also has to keep Mobile IPv6 state to coordinate the redirection 😤
mobile node correspondent node
| |
| |
address |--data----------------->| credit += size(data)
verified | |
|--data----------------->| credit += size(data)
|<-----------------data--| don't change credit
| |
address + address change |
unverified |<-----------------data--| credit -= size(data)
|--data----------------->| credit += size(data)
|<-----------------data--| credit -= size(data)
| |
|<-----------------data--| credit -= size(data)
| X credit < size(data)
| | ==> Do not send!
address | |
verified |<-----------------data--| don't change credit
| |Figure 2: Credit-Based Authorization
Figure 2 shows Credit-Based Authorization in action with a little exchange of data packets 📦 The correspondent node keeps track of the bytes it gets from the mobile node. When the mobile node registers a new care-of address, the correspondent node marks it "unverified" and keeps sending packets there as long as the total packet size stays under the amount of data it has measured coming in 📊 Meanwhile, a concurrent care-of-address test is running 🕵️♀️ Once that address is verified, the correspondent node flips the label from "unverified" to "verified", and then packets can go there with no limits at all ✨ But if the credit runs low while the address is still "unverified", the correspondent node stops sending more packets until verification finishes 🛑 During that pause it may drop those packets, send them to the mobile node's home address instead, or buffer them until the care-of address is verified 📬 Also, Figure 2 doesn't show Mobile IPv6 signaling packets, so don't be confused about that 🙈
The correspondent node also makes sure the mobile node's credit gradually drains over time 🫧 This is called "aging", and it stops the mobile node from stockpiling credit forever. Without it, a malicious node with a slow Internet connection could save up for a burst of redirected packets that has nothing to do with its own upstream capacity 🚫
Now, when the credit is allocated based on the packets the mobile node sends, and reduced based on the packets it receives, that's called "Inbound Mode" 📥 (The correspondent node is the one in charge of allocating credit, and it works out the credit from the inbound packets it gets from the mobile node.) The best part of Inbound Mode is that it doesn't need any support from the mobile node 🥰 The mobile node doesn't have to know that Credit-Based Authorization is running at the correspondent node, and it doesn't need to track how much credit it has at any given moment. Iconic behavior from a protocol, honestly 👑
Inbound Mode works great for apps that send similar amounts of data in both directions 🤝 But it can be a problem for asymmetric apps. Take file transfers and media streaming: they push a lot of throughput toward the client (typically the mobile node) and barely any back toward the serving correspondent node 📉 In those cases, the mobile node may never collect enough credit for a handoff 😭
That's why there's an extra "Outbound Mode" designed for asymmetric traffic patterns 🎀 In Outbound Mode, the packets the correspondent node sends to the mobile node decide two things: how much credit goes up while the current care-of address is verified, and how much it goes down while that address is unverified. That fixes the asymmetric traffic problem 💖
The security of Outbound Mode rests on one extra hypothesis: the mobile node spends comparable effort on receiving and sending packets, in terms of bandwidth, memory, and processing capacity 💪 That's what justifies turning credit earned from packets the mobile node receives into packets the correspondent node is allowed to send. The tricky question is how the correspondent node can tell how many of the packets it sent to the mobile node were actually received and processed 🤔 You can't rely on transport-layer acknowledgments, because those are easy to fake 🙅♀️ So Outbound Mode defines its own feedback mechanism, Care-of Address Spot Checks, which holds up against spoofing 🔍 The correspondent node periodically tags some packets going to the mobile node with a random, unguessable number called a Spot Check Token 🎲 When the mobile node gets a packet with a Spot Check Token attached, it holds onto the token until it sends its next packet to the correspondent node, and then it includes the token in that packet 📤 When the correspondent node receives it, it checks whether the returned token matches one it recently sent 🧐 New credit is handed out in proportion to the ratio of successfully returned Spot Check Tokens to the total number of tokens sent. So basically, new credit tracks the fraction of packets that made it at least up to the mobile node's IP stack 🧠 And here's a cute tradeoff: how precise the Spot Checks are depends on how often packets get tagged with tokens, so more precision means more overhead ⚖️
Okay, but could Outbound Mode be abused by an attacker with an asymmetric Internet connection? 👀 Good question! Lots of DSL lines, for example, have way more download speed than upload speed ⬇️⬆️ That limited upload rate makes most direct-flooding attempts pointless. The catch is that the attacker could use its strong download rate to build up credit at one or more correspondent nodes, and then spend that credit on a stronger, redirection-based flood 😈 The reason this hasn't been a big deal so far is that to rack up enough credit at the far end, the attacker would first have to get hit by the same packet flood it wants to redirect at the victim 🌊 Not very appealing, lol.
3.8. Heuristic Monitoring 🔎
Heuristics are another option for stopping misuse of unverified care-of addresses (see Section 3.5), and they're worth thinking about 🧩 A heuristic running at the correspondent node, maybe paired with a strict lifetime limit for tentative bindings, can stop that misuse or at least seriously discourage it 🙌 The hard part is finding a heuristic that works. On one hand, it has to be rigid enough to react fast to malicious intent on the other side. On the other hand, it shouldn't hurt a fair-minded mobile node's communications 😬
Heuristics have another catch too: they're usually reactive. The correspondent node can only respond to bad behavior after it has shown up 🕰️ If sanctions land quickly, attacks might just stop being worth the effort ⚡ But jumping the gun is bad too, so premature measures should be avoided 🚫 Also keep in mind that an attacker may be able to use different home addresses, and it's generally impossible for the correspondent node to figure out that a set of home addresses belongs to the same node 🫠 On top of that, the attacker might work with multiple correspondent nodes to try to amplify its result 📈
3.9. Crypto-Based Identifiers ✨
okay so a Crypto-Based Identifier (CBID) is an identifier that's strongly locked to the public half of its owner's public/private-key pair [33] 🔐 the owner proves they own it by signing a piece of data with their private key, then sending that signature to the verifier along with their public key and the parameters needed to recompute the CBID. the verifier recomputes the CBID and checks that the owner actually knows the matching private key 💅
CBIDs have three main perks, and they're iconic 👑 First, spoofing a CBID is way harder than attacking a non-cryptographic identifier like a domain name or a Mobile IPv6 home address. an attacker can always make their own CBID, but it's super unlikely they'll find a public/private-key pair that produces someone else's 🙈 Second, a CBID doesn't need a PKI, since it's inherently bound to the owner's public key 🫶 Third, a CBID can tie a public key to an IP address, and when it does that it's called a Cryptographically Generated Address (CGA) [44][34][47]. a CGA is syntactically just a regular IPv6 address 🦋 it has a standard routing prefix, and its interface identifier is generated from a hash of the CGA owner's public key plus some extra parameters.
there are so many situations where CGAs are the move 🌸 In Mobile IPv6, CGAs can bind a mobile node's home address to its public key [35][5], which means they can skip the home-address test in most correspondent registrations. that speeds up registration and lets the peers talk without needing the home agent to be up 🚀
ngl, only the interface identifier of a CGA is cryptographically protected, so its network prefix can still be spoofed, and flooding attacks against networks are still a problem 💀 that's why an initial home-address test is still required to validate the network prefix, even when the home address is a CGA. for the same reason, CGAs are rarely used as care-of addresses 🙅♀️
one limitation of CGAs compared to other CBIDs is that the cryptographically protected part is at most 62 bits long 😭 the rest of the address is taken up by a 64-bit network prefix plus the universal/local and individual/group bits. (the specification in [44] also hard-codes a 3-bit security parameter into the address, which shrinks the protected part down to 59 bits.) so a brute-force attack might turn up a public/private key public/private-key pair that produces a certain CGA 😱 this can be contained by including the network prefix in the hash computation for the interface identifier. that way, even if an attacker found the right key pair, they couldn't form CGAs for multiple networks with it 🛡️
to sort out collisions when generating CGAs, a collision count is part of the input to the hash function. changing it gives you a different CGA ✨ the catch is that the collision count also lowers the complexity of a brute-force attack, because it lets the same private/public-key pair generate multiple CGAs. so the collision count is limited to just a few values 🙃
if you want more security, go with longer CBIDs 💪 for example, a node's primary identifier in the Host Identity Protocol [21] is a 128-bit hash of the node's public key. it's used as an IP-address replacement at the stack layers above IP. this CBID isn't routable, so if a node only knows a peer's identifier, there needs to be some external localization mechanism to find that peer 🗺️
3.10. Pre-Configuration 🎀
when mobile and correspondent nodes can be pre-configured with a shared key bound to the mobile node's home address, you can swap out the home-address test for a cryptographic mechanism 🔑 this has three advantages. First, cryptography allows for stronger authentication than address tests 💜 Second, strong authentication makes it possible to have binding lifetimes longer than the 7-minute limit that RFC 3775 sets for correspondent registrations. Third, handoffs are usually faster with cryptographic approaches, because the round-trips of the home-address test can be skipped 🏃♀️ the disadvantage is that pre-configuration has limited applicability 😬
two proposals for pre-configuration are being discussed within the IETF right now 👀 [25] gives mobile nodes the information they need to compute the home and care-of keygen tokens themselves, instead of getting them through the return-routability procedure. [15] uses the Internet Key Exchange protocol to set up an IPsec security association between the peers.
technically speaking, pre-configuration can only replace a home-address test. a test of the care-of address is still needed to verify that the mobile node is actually present at that address 🧐 [25] gets around this by assuming the correspondent node trusts the mobile node enough to believe the care-of address is correct. but that assumption makes pre-configuration a bad fit wherever that trust doesn't exist 🚫 for example, a mobile-phone operator might be able to give subscribers secret keys to authorize them for a particular service, but it may not be able to vouch that every subscriber uses that service responsibly. and even trustworthy users can have their mobile nodes infected with malware and start acting unreliably 🦠
another way to skip care-of-address verification is to rely on access networks to filter out packets with incorrect IP source addresses [38][43]. [15] takes this approach. the problem with local filtering is that it can only stop a network from being the source of an attack, not from falling victim to one 😤 so the technique is potentially unreliable unless it's deployed in access networks worldwide (see Section 1.2).
care-of-address tests make pre-configuration work even without trust relationships or in access networks that lack local filtering techniques 🙌 for better performance, concurrent care-of-address tests can be combined with Credit-Based Authorization or heuristic monitoring ⚡
3.11. Semi-Permanent Security Associations 🦋
a middle ground between the return-routability procedure and pre-configuration is semi-permanent security associations 🌈 one gets established between a mobile node and a correspondent node on first contact, and then it's used to authenticate the mobile node during later correspondent registrations. semi-permanent security associations get rid of the need for periodic home-address tests, and they allow correspondent registrations with lifetimes longer than the 7-minute limit in RFC 3775 🎉
it's really important to verify a mobile node's home address before a security association is bound to it 🚨 otherwise an impersonator could create a security association for a victim's IP address and redirect the victim's traffic however they want until that association expires 😱 an initial home-address test helps here, because the attacker would have to be on the path between the victim and the victim's peer at least while the security association is being set up. stronger security comes from cryptographically generated home addresses (see Section 3.9) 🔐
semi-permanent security associations on their own don't verify care-of addresses at all, so they have to be backed up by care-of-address tests 💁♀️ those tests can run concurrently for shorter handoff delays. semi-permanent security associations were first developed in [8], where they were called "purpose-built keys" 🍓
3.12. Delegation 👑
Section 1.1 lists plenty of problems PKIs have when it comes to authenticating mobile nodes 🙄 but those problems get way more manageable if correspondent nodes authenticate home agents instead of mobile nodes, and the home agents vouch for how authentic and trustworthy the mobile nodes are [37]. this kind of delegation fixes the scalability issue with PKIs, since home agents are expected to be far less numerous than mobile nodes 📈 revoking certificates also gets less delicate, because home agents are usually run by a mobility provider and should be more accountable than mobile nodes ✅
another perk of delegation is that it avoids public-key computations at the mobile nodes 🙌 the trade-off is that the processing overhead at correspondent nodes goes up. whether that's a problem depends on the resources the correspondent node has compared to the services it provides 🤷♀️ and if the correspondent node is itself mobile, cryptographic operations could be a real headache 😵 plus, the extra overhead means a higher risk of resource-exhaustion attacks 💀
3.13. Mobile Networks 🚆
sometimes mobile nodes move as a group and connect to the Internet through a "mobile router" that travels with them 🚄 think trains or aircraft, where passengers talk over a local wireless network that's globally connected through a satellite link ✈️
supporting this kind of network mobility [41] is pretty straightforward, using a single home agent and a tunnel between the mobile router and that home agent 🙌 the mobile nodes themselves don't have to be mobility-aware. Route Optimization for moving networks [36][26][27][55], though, is way more complicated 😩 one option is to have the mobile router handle Route Optimization on behalf of the mobile nodes. that means the mobile router has to modify incoming and outgoing packets so they can be routed along the direct path between the end nodes, and it would also have to run Mobile IPv6 signaling for the mobile nodes 🧠 similarly, a network of correspondent nodes can talk to mobile nodes through a "correspondent router" in a route-optimized way, without offering mobility support themselves 🌟
3.14. Location Privacy 🕵️♀️
RFC 3775 doesn't hide a mobile node's current position, since route-optimized packets always carry both the home and care-of addresses 😬 that means both the correspondent node and any third party can track where the mobile node is 👀 a workaround is to fall back to bidirectional tunneling wherever location privacy matters. then packets carrying the mobile node's care-of address only travel between the mobile node and the home agent, where they can be encrypted with IPsec ESP [42]. but even then, the mobile node should periodically re-establish its IPsec security associations so it can't be traced through its SPIs 🫥 early efforts on location privacy in Route Optimization include [17][13][24][30] 💜
4. Discussion ✨
okay so bestie, the big takeaway across everything in Section 3 is that every single proposal is basically a trade-off 💅. On one side you've got effectiveness (low latency, strong security, less signaling, more robustness 🔥). On the other side you've got how economical it is to deploy, how much admin overhead it dumps on people, and how widely it can be used 🌸. You can't max out all of them at once, sorry not sorry 😭
The standard return-routability procedure is lowkey the MVP here 👑 because it skips costly pre-configuration and doesn't need any new network entities. Less money, less admin pain. The optimistic and proactive or concurrent IP-address test variants keep those same perks ✨.
CBIDs let you do public-key authentication without a PKI 🎀. They're a more secure alternative to home-address tests, so they work best when you pair them with concurrent reachability verification 🫶. The catch is that CBID-based authentication may need nodes to be programmed with a mapping between human-readable identifiers and their CBIDs 🙈.
Pre-configuration is another way to dodge home-address tests 🧚. No computationally expensive public-key algorithms, yay! But you need pair-wise credentials, which means ongoing admin maintenance 💀.
Where suitable infrastructure exists, end nodes can delegate authentication and encryption tasks to trusted network entities, and those entities vouch for the end nodes 🦋. Delegation could bring back the use of certificates for mobility support, which is kind of iconic 👀. But it adds a dependency on the delegatees, adds provisioning costs for new network entities, and is likely to be limited to communities of authorized nodes 🍓.
4.1. Cross-Layer Interactions
okay so the performance of Route Optimization, as evaluated in this document, should be put into perspective of all the handoff stuff happening in other parts of the network stack 🌈. That includes link-layer attachment procedures, link-layer security stuff like negotiation, authentication, and key agreement, and IPv6 router discovery, address configuration, and movement detection 🧠. A complete network attachment in a typical IEEE 802.11 commercial deployment needs over twenty link- and IP-layer messages. Twenty!! 😭
Current protocol stacks also have some other issues on top of the long attachment delays. There are denial-of-service vulnerabilities, it's hard to trust a set of access nodes spread out across physically insecure locations, and sometimes you just can't get enough info to make a handoff decision [2]. Not it 🙅♀️.
A bunch of proposals have been floated to improve handoff performance on different parts of the stack, mostly focused on handoff performance itself 🎀. These include link-layer parameter tuning [49] and network-access authentication [18][2][32], plus IPv6 router discovery [11][12], address configuration [23], and movement detection [19][20]. The honest truth is that it's uncertain how far you can get by optimizing each part on its own 🤔. An integrated approach may eventually become necessary [4][53] 💜.
4.2. Experimentation and Measurements
The number and variety of mobility-related activities in a typical network stack often make theoretical analyses insufficient, so you need extra, extensive experimentation or simulation 🧪. Here's a non-exhaustive list of areas where practical experience will likely give valuable insight ✨.
- Coming up with a set of standard scenarios to use as a reference for comparable measurements and experimentation 📋. Ideally, these scenarios should come from real-world environments and include all the features a commercial deployment would likely need, like link-layer access control, for instance 🔐.
- Measuring the performance impacts existing enhancement proposals have on the different parts of the stack 📈.
- Comparing different implementations that are based on the same specification 👯. For example, it would be valuable to know how much implementations differ in their use of the parallelism that RFC 3775 allows in home and correspondent registrations 🙌.
- Measuring the impact network conditions like packet loss can have on existing and new optimizations 🌧️.
- Collecting statistical data on how mobile nodes behave in different networks 📊. Several Route Optimization techniques act differently depending on the degree of mobility, so this matters a lot 🏃♀️.
- Measuring the performance Route Optimization schemes show under different application scenarios, like applications with symmetric vs. asymmetric traffic patterns 🎮.
4.3. Future Research
Research that goes beyond the techniques in this document might look at the following items 🔭.
- Local mobility support or local route-repair mechanisms that don't need expensive configuration 🛠️. This includes infrastructure-based Route Optimization like [48].
- Care-of-address verification mechanisms that are based on Secure Neighbor Discovery 🕵️♀️.
- Bringing optimizations developed for Mobile IPv6 over to other mobility protocols, like the Host Identity Protocol, the Stream Control Transmission Protocol, the Datagram Congestion Control Protocol, or link-layer mobility solutions 🦋.
- Extending the developed mobility techniques to full multi-addressing, including multi-homing 🌸.
- Further strategies based on "asymmetric cost wars" [3], such as Credit-Based Authorization 💸.
- Integrated techniques that take both link- and IP-layer mobility tasks into account 💖.
5. Security Considerations 🔒
Standard Route Optimization lets mobile nodes redirect IP packets at a remote peer from one IP address to another IP address. This ability brings in new security issues, which are explained and discussed in depth in [46]. The alternative Route Optimization techniques described in this document may bring in new security threats that go beyond those identified in [46]. Where such new threats exist, they are discussed and analyzed along with the description of the respective technique in Section 3. This is serious business, bestie 🚨.
6. Conclusions 🎀
Mobile IPv6 Route Optimization cuts down packet-propagation latencies so it can support interactive and real-time applications in mobile environments ⚡. Unfortunately, the end-to-end protocol's high handoff latencies get in the way of exactly these applications 😩. That's why a huge amount of effort has recently gone into Route Optimization improvements 🫶. Some proposed techniques work on an end-to-end basis, while others need new or extended infrastructure in the network 🏗️. Some need pre-configuration, and others are zero-configurable ✨.
This document compared and evaluated the different strategies based on a selected set of enhancement proposals 📝. The big thing that stands out is that every proposal makes a trade-off between effectiveness, on one hand -- whether that's reduced handoff latency, increased security, or lower signaling overhead -- and pre-configuration costs or required network upgrades, on the other 🎭. An optimization's investment requirements, in turn, relate to how suitable it is for widespread deployment 💅.
However, the real-life performance of end-to-end mobility doesn't only depend on Route Optimization enhancements. It ultimately depends on all parts of the protocol stack [2] 🧩. Related optimization efforts are actually gaining momentum, and a comprehensive approach to Route Optimization must incorporate the most suitable solutions among them [4] 🌈. Whichever proposals eventually reach a maturity level good enough for standardization, any effort should be spent getting them there within the foreseeable future ⏳. Route Optimization needs support from both peers and depends on a solid base of installed implementations in correspondent nodes 🤝. So this should be included in emerging IPv6 stacks early on 🚀. IPv6 deployment is still far from widespread, but the sooner efficient Route Optimization is available, the more likely it is to end up ubiquitously supported 💜.
7. Acknowledgments 🫶
This document was thoroughly reviewed, in alphabetical order, by Samita Chakrabarti, Francis Dupont, Thierry Ernst, Gerardo Giaretta, James Kempf, Rajeev Koodli, Gabriel Montenegro, Vidya Narayanan, and Fan Zhao. The authors want to thank these folks for their valuable comments and suggestions 💖.
8. References 📚
8.1. Normative References
- [1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. 🌟
8.2. Informative References 📚✨
okay bestie, this is the reading list 🙈 these are the "go deeper" sources the doc leans on, from roaming papers to Mobile IPv6 drafts and a bunch of RFCs. Full details, every single one 💅
[2] Alimian, A. and B. Aboba, "Analysis of Roaming Techniques", IEEE Contribution 802.11-04/0377r1, March 2004.
[3] Arkko, J. and P. Nikander, "Weak Authentication: How to Authenticate Unknown Principals without Trusted Parties", Proceedings of Security Protocols Workshop 2002, Cambridge, UK, April 2002.
[4] Arkko, J., Eronen, P., Nikander, P., and V. Torvinen, "Secure and Efficient Network Access", Proceedings of the DIMACS Workshop on Mobile and Wireless Security, November 2004.
[5] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route Optimization for Mobile IPv6", Work in Progress, August 2006.
[6] Arkko, J. and C. Vogt, "Credit-Based Authorization for Binding Lifetime Extension", Work in Progress, May 2004.
[7] Bahl, P., Adya, A., Padhye, J., and A. Walman, "Reconsidering Wireless Systems With Multiple Radios", ACM SIGCOMM Computer Communication Review, ACM Press, Vol. 34, No. 5, October 2004.
[8] Bradner, S., Mankin, A., and J. Schiller, "A Framework for Purpose-Built Keys (PBK)", Work in Progress, June 2003.
[9] Castellucia, C., Montenegro, G., Laganier, J., and C. Neumann, "Hindering Eavesdropping via IPv6 Opportunistic Encryption", Proceedings of the European Symposium on Research in Computer Security, Lecture Notes in Computer Science, Springer-Verlag, September 2004.
[10] Chandra, R., Bahl, P., and P. Bahl, "MultiNet: Connecting to Multiple IEEE 802.11 Networks Using a Single Wireless Card", Proceedings of the IEEE INFOCOM, Vol. 2, August 2004.
[11] Daley, G., Pentland, B., and R. Nelson, "Effects of Fast Routers Advertisement on Mobile IPv6 Handovers", Proceedings of the IEEE International Symposium on Computers and Communication, Vol. 1, June 2003.
[12] Daley, G., Pentland, B., and R. Nelson, "Movement Detection Optimizations in Mobile IPv6", Proceedings of the IEEE International Conference on Networks, September 2003.
[13] Daley, G., "Location Privacy and Mobile IPv6", Work in Progress, January 2004.
[14] Dupont, F., "A Note about 3rd Party Bombing in Mobile IPv6", Work in Progress, July 2006.
[15] Dupont, F. and J. Combes, "Using IPsec between Mobile and Correspondent IPv6 Nodes", Work in Progress, August 2004.
[16] Dupont, F. and J. Combes, "Care-of Address Test for MIPv6 using a State Cookie", Work in Progress, July 2006.
[17] Haddad, W., Nordmark, E., Dupont, F., Bagnulo, M., and B. Patil, "Privacy for Mobile and Multi-homed Nodes: MoMiPriv Problem Statement", Work in Progress, June 2006.
[18] "IEEE Standard for Local and Metropolitan Area Networks: Port-Based Network Access Control", IEEE Standard 802.1X, December 2004.
[19] Choi, J. and E. Nordmark, "DNA with Unmodified Routers: Prefix List Based Approach", Work in Progress, January 2006.
[20] Narayanan, S., Ed., "Detecting Network Attachment in IPv6 Networks (DNAv6)", Work in Progress, October 2006.
[21] Moskowitz, R., Nikander, P., Jokela, Ed., P., and T. Henderson, "Host Identity Protocol", Work in Progress, June 2006.
[22] Henderson, T., Ed., "End-Host Mobility and Multihoming with the Host Identity Protocol", Work in Progress, June 2006.
[23] Moore, N., "Optimistic Duplicate Address Detection (DAD) for IPv6", RFC 4429, April 2006.
[24] Koodli, R., "IP Address Location Privacy and Mobile IPv6: Problem Statement", Work in Progress, October 2006.
[25] Perkins, C., "Securing Mobile IPv6 Route Optimization Using a Static Shared Key", RFC 4449, June 2006.
[26] Ng, C., Thubert, P., Watari, M., and F. Zhao, "Network Mobility Route Optimization Problem Statement", Work in Progress, September 2006.
[27] Ng, C., Zhao, F., Watari, M., and P. Thubert, "Network Mobility Route Optimization Solution Space Analysis", Work in Progress, September 2006.
[28] Arbaugh, W. and B. Aboba, "Handoff Extension to RADIUS", Work in Progress, October 2003.
[29] "Kame-Shisa", Mobile IPv6 for FreeBSD.
[30] Koodli, R., Devarapalli, V., Flinck, H., and C. Perkins, "Solutions for IP Address Location Privacy in the Presence of IP Mobility", Work in Progress, February 2005.
[31] Nuorvala, V., Petander, H., and A. Tuominen, "Mobile IPv6 for Linux (MIPL)".
[32] Mishra, A., Shin, M., Petroni Jr., N., Clancy, C., and W. Arbaugh, "Proactive Key Distribution Using Neighbor Graphs", IEEE Wireless Communications, Vol. 11, No. 1, February 2004.
[33] Montenegro, G. and Claude. Castelluccia, "Crypto-Based Identifiers (CBIDs): Concepts and Applications", ACM Transactions on Information and System Security Vol.7, No. 1, February 2004.
[34] Nikander, P., "Denial-of-Service, Address Ownership, and Early Authentication in the IPv6 World", Revised papers from the International Workshop on Security Protocols, Springer-Verlag, April 2002.
[35] O'Shea, G. and M. Roe, "Child-proof Authentication for MIPv6", ACM SIGCOMM Computer Communication Review, April 2001.
[36] Perera, E., Sivaraman, V., and A. Seneviratne, "Survey on Network Mobility Support", ACM SIGCOMM Computer Communication Review, Vol. 8, No. 2, ACM Press, April 2004.
[37] Bao, F., Deng, R., Qiu, Y., and J. Zhou, "Certificate-basedBinding Update Protocol (CBU)", Work in Progress, March 2005.
[38] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000.
[39] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site-Multihoming Architectures", RFC 3582, August 2003.
[40] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents", RFC 3776, June 2004.
[41] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005.
[42] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[43] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.
[44] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005.
[45] Huston, G., "Architectural Approaches to Multi-homing for IPv6", RFC 4177, September 2005.
[46] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. Nordmark, "Mobile IP Version 6 Route Optimization Security Design Background", RFC 4225, December 2005.
[47] Roe, M., Aura, T., O'Shea, G., and J. Arkko, "Authentication of Mobile IPv6 Binding Updates and Acknowledgments", Work in Progress, February 2002.
[48] Vadali, R., Li, J., Wu, Y., and G. Cao, "Agent-Based Route Optimization for Mobile IP", Proceedings of the IEEE Vehicular Technology Conference, October 2001.
[49] Velayos, H. and G. Karlsson, "Techniques to Reduce IEEE 802.11b MAC Layer Handoff Time", Laboratory for Communication Networks, KTH, Royal Institute of Technology, Stockholm, Sweden, TRITA-IMIT-LCN R 03:02, April 2003.
[50] Vogt, C., "Credit-Based Authorization for Concurrent IP-Address Tests", Proceedings of the IST Mobile and Wireless Communications Summit, June 2005.
[51] Vogt, C., Bless, R., Doll, M., and T. Kuefner, "Early Binding Updates for Mobile IPv6", Proceedings of the IEEE Wireless Communications and Networking Conference, IEEE, Vol. 3, March 2005.
[52] Vogt, C. and M. Doll, "Efficient End-to-End Mobility Support in IPv6", Proceedings of the IEEE Wireless Communications and Networking Conference, April 2006.
[53] Vogt, C., "A Comprehensive Delay Analysis for Reactive and Proactive Handoffs with Mobile IPv6 Route Optimization", Institute of Telematics, Universitaet Karlsruhe (TH), Karlsruhe, Germany, TM-2006-1, January 2006.
[54] Zhao, F., Wu, F., and S. Jung, "Extensions to Return Routability Test in MIP6", Work in Progress, February 2005.
[55] Calderon, M., Bernardos, C., Bagnulo, M., Soto, I., and A. de la Oliva, "Design and Experimental Evaluation of a Route Optimisation Solution for NEMO", IEEE Journal on Selected Areas in Communications, Vol. 24, No. 9, September 2006.
Authors' Addresses 🎀
the people who wrote it, and how to reach them 💌
Christian Vogt
Institute of Telematics
Universitaet Karlsruhe (TH)
P.O. Box 6980
76128 Karlsruhe
Germany
EMail: chvogt@tm.uka.de
Jari Arkko
Ericsson Research NomadicLab
FI-02420 Jorvas
Finland
EMail: jari.arkko@ericsson.comFull Copyright Statement ⚖️
the legal bit, word for word, because it matters 🫶
Copyright (C) The IETF Trust (2007).
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, THE IETF TRUST 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 🔐
who owns what, and where to ask 🦋
The IETF takes no position regarding 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 the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line 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 that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
Acknowledgement 💜
big thank-you energy 🌈
Funding for the RFC Editor function is currently provided by the Internet Society.
📦 where this page comes from
- ietf: rfc4651 2007-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms