RFC 4177

RFC 4177 is Architectural Approaches to Multi-homing for IPv6 💖 by G. Huston from APNIC, in the Network Working Group, filed as Informational in September 2005 🎀. It doesn't obsolete or update anything, since the header doesn't list any. This is part 1 of 10 🧚

Status of this Memo ✨

This memo is just for information 📚 It is not an Internet standard of any kind, and it can be shared with anyone 🦋

Copyright Notice 🔥

Copyright (C) The Internet Society (2005).

Abstract 🌸

Okay so this memo digs into the architecture side of multi-homing for IPv6 🫶 The goal is to make a taxonomy, which is a fancy way of saying a sorting system, so people can tell the different multi-homing proposals apart 💅 It also tries to spot the stuff they all have in common, and gives us a framework to explore what the architectural extensions could mean further down the road ✨

Table of Contents 🎀

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
3.  The Multi-Homing Space . . . . . . . . . . . . . . . . . . . .  5
4.  Functional Goals and Considerations  . . . . . . . . . . . . .  7
5.  Approaches to Multi-Homing . . . . . . . . . . . . . . . . . .  7
    5.1.  Multi-Homing: Routing  . . . . . . . . . . . . . . . . .  8
    5.2.  Multi-Homing: Mobility . . . . . . . . . . . . . . . . .  9
    5.3.  Multi-homing: Identity Considerations  . . . . . . . . . 12
    5.4.  Multi-homing: Identity Protocol Element  . . . . . . . . 14
    5.5.  Multi-homing: Modified Protocol Element  . . . . . . . . 15
    5.6.  Modified Site-Exit and Host Behaviors  . . . . . . . . . 16
6.  Approaches to Endpoint Identity  . . . . . . . . . . . . . . . 17
    6.1.  Endpoint Identity Structure  . . . . . . . . . . . . . . 18
    6.2.  Persistent, Opportunistic, and Ephemeral Identities  . . 20
    6.3.  Common Issues for Multi-Homing Approaches  . . . . . . . 23
          6.3.1.  Triggering Locator Switches  . . . . . . . . . . 23
          6.3.2.  Locator Selection  . . . . . . . . . . . . . . . 26
          6.3.3.  Layering Identity  . . . . . . . . . . . . . . . 27
          6.3.4.  Session Startup and Maintenance  . . . . . . . . 29
          6.3.5.  Dynamic Capability Negotiation . . . . . . . . . 31
          6.3.6.  Identity Uniqueness and Stability  . . . . . . . 31
7.  Functional Decomposition of Multi-Homing Approaches  . . . . . 32
    7.1.  Establishing Session State . . . . . . . . . . . . . . . 32
    7.2.  Re-homing Triggers . . . . . . . . . . . . . . . . . . . 33
    7.3.  Re-homing Locator Pair Selection . . . . . . . . . . . . 33
    7.4.  Locator Change . . . . . . . . . . . . . . . . . . . . . 34
    7.5.  Removal of Session State . . . . . . . . . . . . . . . . 34
8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 34
9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34
10. Informative References . . . . . . . . . . . . . . . . . . . . 34

1. Introduction 🧚

The whole point here is to slot different technical proposals for multi-homing in IPv6 into one architectural taxonomy 🗂️ That lets us classify and compare them in a structured way, which is honestly so satisfying 😭 We also want to find the shared stuff across all these proposals, and build a framework for working out the further implications of the architectural extensions meant to support multi-homing 🌈 The scope is limited to the IPv6 protocol suite architecture, but IPv4 approaches get mentioned when they're needed 🍓

2. Terminology 📖

Here's the vocab you need to know before we go any further 🫶

Care-of Address (CoA): A unicast routeable address linked to a mobile node while it's visiting a foreign link ✈️ The subnet prefix of this address is a foreign subnet prefix. A mobile node can have several care-of addresses at once, like with different subnet prefixes, and the one it registers with its home agent for a given home address is called its "primary" care-of address 💜

Correspondent Node (CN): A peer node that a mobile node is talking to 💬 The correspondent node can be mobile or stationary, so it's giving flexibility 🦋

Endpoint: The term for the identity of a network host 🎀 It's normally assumed to be a constant or long-lived association, so it's basically the forever bestie of the network world 👑

Endpoint Identity Protocol Stack Element (EIP): An added element in a protocol stack model that explicitly manages the association of locators to endpoints 🧩 It's the manager of who's connected to who, and honestly iconic 💅

Home Address (HoA): A unicast routeable address assigned to a mobile node and used as its permanent address 🏠 This address sits within the mobile node's home link. Standard IP routing will deliver packets sent to a mobile node's home address to its home link 📬 Mobile nodes can have multiple home addresses, for example when there are multiple home prefixes on the home link ✨

Lower Layer Protocol (LLP): The lower-level protocol in the protocol stack model, relative to the protocol layer being considered 🪜 In the Internet architecture, the LLP of the transport protocol is the Internet Protocol, and the LLP of the application protocol is the transport protocol 🌊

Locator: The term "locator" is used as the location token for a network host 📍 It's a network-level address that can go in the destination field of IP packets, so it's basically the address label for where the packet is headed 💌

Mobile Node: A node that can change its point of attachment from one link to another, and still be reachable through its home address 🚶‍♀️ Main character energy, no cap 👑

Multi-Homed Site: A site with more than one transit provider 🌐 "Site multi-homing" is the practice of setting up a site to be multi-homed, so the site can use any of its transit providers for connectivity services 🔥

Re-homing: The transition of a site between two states of connectedness, caused by a change in the connectivity between the site and its transit providers 🔄 Lowkey dramatic, but it's the whole thing 😭

Site: An entity that autonomously operates a network using IP 🏰

Site-Exit Router: A boundary router of the site that provides the site's interface to one or more transit providers 🚪 It's the door out of the site, and it's so important 🫶

Transit Provider: A provider that operates a site that directly provides connectivity to the Internet for one or more external sites 🌍 The connectivity extends beyond the transit provider's own site, and a transit provider's site is directly connected to the sites it provides transit for 🧚 It's the big sister who carries everyone's traffic 💜

Upper Layer Protocol (ULP): The upper-level protocol in the protocol stack model, relative to the protocol layer being considered 🪜 In the Internet architecture, the ULP of the Internet Protocol is the transport protocol, and the ULP of the transport protocol is the application protocol 🌈 Okay that's the vocab down, so we can get into the good stuff next 🍓💅

3. The Multi-Homing Space ✨

okay so first, let's look at the basic setup 👀 Figure 1 is the picture we're working with:

                       +------+
                       |remote|
                       | host |
                       |  R   |
                       +------+
                          |
                + - - - - - - - - - - - +
                | Internet Connectivity |
                + - - - - - - - - - - - +
                     /            \
               +---------+    +---------+
               | ISP A   |    |  ISP B  |
               +---------+    +---------+
                   | Path A        | Path B
     + - - - - - - - - - - - - - - - - - - - - +
     | multi-      |               |           |
       homed   +------+         +------+
     | site    | site-|         | site-|       |
               | exit |         | exit |
     |         |router|         |router|       |
               |  A   |         |  B   |
     |         +------+         +------+       |
                  |                |
     |         local site connectivity         |
                       |
     |           +-----------+                 |
                 |multi-homed|
     |           |   host    |                 |
                 +-----------+
     + - - - - - - - - - - - - - - - - - - - - +

Figure 1: The Multi-Homed Domain

the whole point of multi-homing is to give local hosts enough support to swap IP packets with remote hosts, and that swapping should keep working even when connectivity keeps changing 🦋 session resilience is the big one: if a local multi-homed-aware host starts an app session with the remote host over "Path A" and that path dies, the session should get moved over to "Path B" without the app ever needing to re-establish anything 😭 the app shouldn't have to know anything about which forwarding paths the network picked underneath. sessions should survive changes in network-level reachability, period 💅

then there's sustained site visibility, which is about making sure session setup keeps working 🌸 this means outside attempts to start talking to hosts inside the site will succeed as long as there's at least one viable path between the external host and the multi-homed site. it also means that when local hosts try to reach remote hosts, they should look at the current connectivity state when picking locators and setting up their initial locator sets. very considerate, very aware 🧚

there's also the possibility of spreading total traffic across several network paths according to some predetermined policy objective 🍓 that could be for traffic engineering, for supporting particular quality-of-service requirements, or for localized load balancing across multiple viable links. so many options, fr fr ✨

this simple multi-homing scenario also includes "site-exit" routers, which is where the local site plugs into its upstream Internet transit providers 🎀 how the external routing system talks to the site-exit routers, how the site-exit routers talk to the local multi-homed host, and how local connectivity forwarding interacts with the local host and the site-exit routers are not defined ahead of time in this scenario. those interactions are part of the framework for how the various multi-homing components work together 🫶

the big defining trait of this simple site multi-homing scenario is that the address space used by, and advertised as reachable by, ISP A is different from the address space used by ISP B 👑

this simple scenario is meant to illustrate the basic multi-homing environment 💜 there are lots of variations, like extra external transit providers for the local site; complicated site requirements and constraints, where the site can't connect uniformly to every external transit provider; sequential instead of simultaneous external transit reachability; communication with remote multi-homed hosts; multiway communications; using host addresses in a referential context (third-party referrals); and imposing policy constraints on path selection. still, the basic simple site multi-homing scenario is enough to show the major architectural parts of multi-homing support, so this is the reference model we're using for the rest of the analysis 🌈

4. Functional Goals and Considerations ⭐

okay the goals part is where we line up what a multi-homing approach is supposed to handle 🔥 RFC 3582 [RFC3582] lays out a bunch of goals, and they include:

• redundancy
• load sharing
• traffic engineering
• policy constraints
• simplicity of approach
• transport-layer survivability
• DNS compatibility
• packet filtering capability
• scaleability
• legacy compatibility

for the full scoop on each one, go read [RFC3582] 📖

also, [thinks] has more considerations for IPv6 multi-homing 🧠 same deal, go to that doc for the detailed list. the general topic areas covered there are:

• interaction with routing systems,
• aspects of a split between endpoint-identifier and forwarding locator,
• changes to packets on the wire, and
• the interaction between names, endpoints, and the DNS.

when you're judging different approaches, you also want to think about:

• the role of helpers and agents in the approach,
• modifications to host behaviours,
• the required trust model to support the interactions, and
• the nature of potential vulnerabilities in the approach.

5. Approaches to Multi-Homing 🦄

so there seem to be five generic kinds of architectural approaches to this problem 💖 they are:

• Routing: Use the IPv4 multi-homing approach
• Mobility: Use the IPv6 Mobility approach
• New Protocol Element: Insert a new element in the protocol stack that manages a persistent identity for the session
• Modify a Protocol Element: Modify the transport or IP protocol stack element in the host in order to support dynamic changes to the forwarding locator
• Modified Site-Exit Router/Local Host interaction: Modify the site-exit router and local forwarding system to allow various behaviours including source-based forwarding, site-exit hand-offs, and address rewriting by site-exit routers

we'll go through each of these in detail in the sections coming up 🎀

5.1. Multi-Homing: Routing 🛣️

okay so the IPv4 way of doing multi-homing is to keep the IPv4 address working as both an endpoint identifier and a forwarding locator, all at once 🤯 for that to work here, the transit ISPs have to announce the local site's address prefix as its own separate routing entry in the inter-domain routing system. this approach could be used in IPv6 too, and just like with IPv4, no changes to the IPv6 architecture are needed for it 💅

the local site's address prefix can be a more specific prefix taken from the address space of one of the transit providers, or it can come from some third-party provider that isn't directly connected to the local site 🌸 or the address space can be its own distinct block, directly assigned by a Regional Internet Registry as Provider Independent space. either way, every host inside the local site gets a unique address from the site's address prefix ✨

every transit provider for the site accepts a prefix advertisement from the multi-homed site and advertises that prefix globally in the inter-domain routing table 🌍 when connectivity between the local site and one transit provider drops, normal routing protocol behaviour takes care of withdrawing the advertisement for that particular path from the routing system. remote domains that had picked that path as the best one will pick another candidate path as their best path instead 🔄 when the path comes back, it gets re-advertised in the inter-domain routing system, and remote domains do a fresh best-path selection based on that re-advertised reachability info 💜 neither the local host nor the remote host needs multiple addresses or has to do any kind of address selection 🙌 the path used for forward and reverse flows is decided by the routing system.

this approach meets basically all the goals for multi-homing approaches, with one big exception: scaleability 😭 every site that multi-homes this way adds one more entry to the global inter-domain routing table. with the constraints of current routing and forwarding tech, it isn't clearly evident that this can scale to a population of multi-homed sites on the order of, for example, 10**7 such sites 💀 that would mean adding a similar number of unique prefixes to the inter-domain routing environment, which would pile more storage and computation onto inter-domain routing elements across the network. that amount of extra load isn't supportable with the current capabilities of the IPv4 global Internet, and it isn't clear right now that the routing capabilities of the whole network could be expanded to handle it cost-effectively, within the bounds of the current inter-domain routing protocol architecture 🙈

there's one more goal that's at risk with this approach, too: transport-layer survivability 🥺 dynamic changes in the network make the routing system converge to a new stable distributed forwarding state. that convergence can make the network produce unstable transient forwarding paths, and it can take an indeterminate amount of time to finish 😵 which in turn can trigger upper-layer protocol timeouts and possibly session resets 💔

5.2. Multi-Homing: Mobility 🦋

okay so keeping a conversation alive while you move around and keeping it alive when a link dies are literally the same trick, bestie 💅. Both need you to swap the locators in use mid-conversation while the endpoint identifier the Upper Layer Protocol (ULP) sees stays exactly the same ✨. And guess what? MIPv6 [RFC3775] already has the support for keeping established communications alive through movement, so it's giving "wait, what if we borrowed it for session survivability in multi-homed setups?" 🧚

Okay, here's the MIPv6 vibe 🌸. The mobile node (MN) has a preferred IP address called the Home Address (HoA), which is its stable identifier. That identifier gets dynamically mapped to a valid locator, the Care-of Address (CoA), which matches wherever it's currently plugged into the topology. When the MN is at the Home Network, the HoA does double duty as both locator and identifier. When it's away, the HoA is only the identifier and the CoA is the locator. A relaying agent called the Home Agent, sitting in the Home Network, forwards packets addressed to the HoA over to the current CoA. After every move, the MN must tell its Home Agent the new CoA, and optionally tell the entities it's talking to, the Correspondent Nodes (CNs). The HoA-to-CoA mapping travels in Binding Update (BU) messages 💖.

Now for the security bit 🔐. When the BU goes between the MN and the Home Agent, we can assume a pre-established Security Association is around to protect the binding info. But when the BU goes between the MN and a CN, nope, we can't assume that, so a different mechanism has to protect the binding info in that message. That mechanism is the Return Routeability procedure, and the design background lives in [rosec].

The goal is to let the CN verify that the MN claiming an HoA is currently at a CoA is actually allowed to make that claim, which basically means the HoA was assigned to the MN and the MN really is at the CoA. To check, the CN sends two different secrets: one to the claimed HoA and one to the claimed CoA. If the MN gets both secrets, that means the Home Agent in the Home Network has a trust relationship with the MN, it forwarded the secret sent to the HoA, and the MN is receiving packets sent to the CoA. By putting authorisation info derived from both secrets inside the BU message, the MN can prove to the CN that the claimed HoA-CoA binding is valid 🎀.

The binding the CN creates using authorisation from Return Routeability only lasts 7 minutes, to stop time-shifted attacks [rosec] 🙈. Here's the attack: an attacker on the path between the CN and the MN forges the Return Routeability exchange. Then the CN sends all HoA-bound traffic to the attacker's chosen CoA. The attacker can wander off the path, but the damage sticks around until the binding gets deleted, so the effect is shifted in time. Capping the binding lifetime at the CN means the damage is limited to 7 minutes, since after that a fresh Return Routeability procedure is needed to extend it. Also, fair warning 💀: Return Routeability is still vulnerable to "man-in-the-middle" attacks, because an attacker on the path can forge the periodic Return Routeability exchange.

So the possible multi-homing move would be using BU messages to tell the other side ahead of time about alternative addresses that could be used if the path behind the current address goes down ⭐.

In this scenario, the multi-homed host plays the MN role and the outside host plays the CN role. When a communication starts between them, the address used to start it becomes the HoA. It keeps using that address as long as nothing goes wrong. If an outage hits and the HoA becomes unreachable, one of the multi-homed node's alternative addresses gets used as a CoA. The multi-homed node then sends a BU to the external host saying the new CoA is to be used for the HoA, so the conversation can carry on over the alternative address 🦋. But that BU has to be validated with authorisation from Return Routeability, which means the binding lifetime is capped at a fixed period of no more than 7 minutes. Result: after that interval, the HoA-to-new-CoA binding expires and the HoA gets used again for the communication. Because the HoA is unreachable thanks to the outage, the communication gets interrupted 😭. Also, you can't just grab fresh authorisation by running Return Routeability again, since that needs talking through the HoA, which is no longer reachable. So honestly, a mechanism based on MIPv6 BU messages for conveying alternative addresses will only keep communications alive for 7 minutes 💔.

The bit of MIPv6 that seems problematic for multi-homing is Return Routeability. In MIPv6, identity validity gets periodically tested by return routeability of the identity address. Using that one distinguished locator as the identity token like this can't support return reachability in the multi-homing context if the path tied to the identity locator fails for an extended time 🥀.

5.3. Multi-homing: Identity Considerations 🦋

Okay so the whole goal of multi-homing in the IPv6 world is to get something comparable to what multi-homed IPv4 sites already have, using routing to do the work, without piling extra load onto the IPv6 routing system 💅. IPv6 is meant to be a scalable framework that keeps working for a long time, which means the scaling properties have to stay tractable within projections of how big deployments get and what the underlying tech can handle. Between networks, the basic move in both IPv4 and IPv6 is to line up address deployment with network topology, so addresses can aggregate into a structured hierarchy of the routing space 🌸.

Given that topology-based setup with provider-aggregateable addressing, a local site connected to several providers gets addresses delegated from each provider's address block. In Figure 1, the local multi-homed host will conceivably be addressed in two ways: one using transit provider A's address prefix and the other using transit provider B's address prefix 🎀.

Now picture remote host R wanting to start talking to that local host. R would normally ask the DNS for an address, and in this case the DNS hands back two of them, one from the A prefix and one from the B prefix. R picks one and sends a packet to it, which steers the packet along a path through A or B depending on which address got picked ✨. Here's the sneaky part: if the path between the local site and the transit provider fails, the prefix that the transit provider announces to the inter-domain routing system is still the provider's prefix. R sees zero change in routing, yet packets to the local host now fail to be delivered 😭. That's the multi-homing problem in a nutshell: "If the remote host is aware of multi-homing, how could it switch over to using the equivalent address for the local multi-homed host that transits the other provider?" 🤔

Next up, if the local multi-homed host wants to start a session with remote host R, it has to send a packet to R with a valid source and destination address. The destination is obviously R's, but what source address should the local host use? This choice has two big implications 👑. First, R will, by default, use that source address as the destination in its response, so the source choice is what directs the reverse path from R back to the local host. Second, ISPs A and B may be doing some form of reverse unicast address filtering on the source addresses of packets passed to them, to stop source address spoofing. So if the multi-homed address picks a source from prefix A but the local routing to R picks the best path via ISP B, ISP B's ingress filters will discard the packet 🙈.

Within this addressing structure, there's no form of routing-based repair for certain network failures. If the link between the local site and ISP A fails, ISP A doesn't change the route advertisements it makes to its external routing peers. Even though the site is still reachable via ISP B, packets aimed at the site using ISP A's prefix get discarded by ISP A, because the destination is unreachable 💀. So if the local host wants to keep a session alive across events like this, it needs to communicate to remote host R that it's possible to switch to a destination address for the multi-homed host that's based on ISP B's address prefix. And if the local host wants to initiate a session at that exact moment, it may need to use an initial source locator that reflects the fact that the only viable destination address is the one based on ISP B's prefix. It could be that the local host isn't aware of this return routeability constraint, or that it can't pass the info straight to R. In that case, R needs to discover this information or be handed it some other way 🧚.

In an aggregated routing environment, multiple transit paths to a host imply multiple address prefixes for that host, where each possible transit path is identified by an address for the host. So paths coming into the local multi-homed site via transit provider ISP A must use a forwarding-level destination IP address drawn from ISP A's advertised address prefix set that maps to the multi-homed host 💜. Likewise, packets coming in via ISP B's transit must use a destination address drawn from ISP B's address prefix set. That means path selection (ISP A versus ISP B transit for incoming packets) is really an outcome of the process of selecting an address for the destination host 🌈.

Here's the architectural catch. In the conventional IP protocol architecture, it's assumed that the transport-layer endpoint identity is the same identity the internet forwarding layer uses, which is the IP address 🍓.

If you want multiple forwarding paths for a single transport session, and you want path selection decoupled from transport session initiation and maintenance, then architecturally you'd need changes to the protocol architecture. Those changes would decouple identifying the endpoint from identifying its location and the associated path selection for that endpoint ✨. This is a fundamental change in the semantics of an IP address, given the role the endpoint address plays within the end-to-end architectural model [e2e]. The payoff: a transport session could use an invariant endpoint identity value to initiate and maintain itself, while the forwarding layer dynamically changes paths and associated endpoint locator identities without affecting the session at all 🦋. Decoupling identities and locators like this would not add any incremental load to the inter-domain routing system 👑.

Some generic approaches to this separation of endpoint identity and locator value are described in the following sections 💖.

---

5.4. Multi-homing: Identity Protocol Element 🧚

One approach to this objective is to add a brand-new element into the model of the protocol stack 🌸.

The presentation to the upper-level protocol stack element (ULP) would be endpoint identifiers, which uniquely identify both the local stack and the remote stack. That gives the ULP stable identifiers for the entire lifetime of the ULP session 💜.

The presentation to the lower-level protocol stack element (LLP) would be in the form of a locator. That means the protocol stack element would need to maintain a mapping of endpoint identifier values to locator values 🔥. In a multi-homing context, one of the essential characteristics of this mapping is that it has to be dynamic, meaning environmental triggers should be able to set off a change in mappings. That change then corresponds to a change in the paths (forward and/or reverse) the endpoints use to traverse the network 🛤️. So the ULP session is defined by a peering of endpoint identifiers that stay constant throughout the session's lifetime, while the locators can change to keep end-to-end reachability for the session intact 🎀.

The operation of the new protocol stack element (termed here the "endpoint identity protocol stack element", or EIP) establishes a synchronised state with its remote counterpart ✨. This lets the stack elements exchange a set of locators that may be used within the context of the session. When the local binding between the current endpoint identity value and a locator changes, the source locator value in the forwarding-level packet header changes with it 🦋. When the remote EIP receives a packet carrying the new locator, it recognises that locator as part of an existing session. Then, upon some trigger condition, it updates its session view of the mapping from the remote endpoint identity to the corresponding locator, and uses that locator as the destination locator in subsequent packets passed to the LLP 💅.

From the perspective of the IP protocol architecture, there are two possible places to insert the EIP into the protocol stack 🫶.

The first possible location is at the upper level of the transport protocol. In this setup, the application program interface (API) of the application-level protocols interfaces to the EIP element and uses endpoint identifiers to refer to the remote entity. The EIP then passes locators to the API of the transport layer 🌈.

The second approach is to insert the EIP between the transport and internet protocol stack elements. The transport layer then functions using endpoint identifiers and maintains a transport session with those identifiers. The IP or internetwork layer functions using locators, and the mapping from endpoint identifier to locator is handled inside the EIP stack element 👑.

5.5. Multi-homing: Modified Protocol Element

okay so instead of adding a whole new protocol stack element (bestie, that's a LOT of work 😭), you could just modify an existing one to do the EIP's job 🔧✨ the modification could live in the transport protocol stack element or in the internet protocol stack element. either way, the goal is the same: support multiple locators within single-endpoint-to-single-endpoint communication 🦋

at the transport layer, this could look like binding a set of locators to one session and then sharing that locator set with the remote transport entity 💜 the local transport entity could then switch the mapping to a different locator, for either the local endpoint or the remote endpoint, and the ULP session stays intact 🫶

at the IP level, it could be supported by a form of dynamic rewriting of the packet header as the protocol element processes it 🧚 incoming packets that carry source and destination locators get mapped to packets with the equivalent endpoint identifiers in both fields, and the reverse mapping happens for outgoing packets handed down from the transport layer. direct packet header rewriting mechanisms are potential candidates here 🌸 other candidates are packet header transformations using encapsulation, where the original endpoint identifier header is kept in the packet and an outer locator header gets wrapped around it as it passes through the internet protocol stack element 🎀

now the tea ☕ all of these scenarios share some issues. what state is kept? which part of the protocol stack keeps it? how is state maintained as locator bindings get added and removed? and is only one piece of code aware of the endpoint/locator split, or do multiple protocol elements need modifying? 🙈 for example, if the functionality lives at the internetworking (IP) layer, there's no context of an active transport session. so removing identity/locator state for terminated sessions needs some extra mechanism to trigger it from the transport layer up to the internetworking layer. the drama is real 😭💅

5.6. Modified Site-Exit and Host Behaviors

ok so all the approaches above assume the hosts know they're in a multi-homed environment and use modified protocol behaviour to make multi-homing work 💅 this next one is different. it splits the job across a bunch of network elements, and those elements might rewrite packet headers from a persistent endpoint identity value to a locator value at a remote point 🌈

one possible setup uses site-exit routers to do some form of packet header manipulation as packets leave the local multi-homed site heading for a particular transit provider 🚪✨ the local site routing system picks the best path to a destination host based on the remote host's locator value. the local host writes its endpoint identity as the source address of the packet. when the packet reaches a site-exit router, that router rewrites the source field to a corresponding locator. this locator picks out a reverse path through the same transit ISP, for when the remote host uses it as a destination locator 🦋 to keep the session intact, a matching reverse transformation must be done on incoming packets: the destination locator has to be mapped back to the host's endpoint identifier. there are a number of considerations about whether that's best done at the site-exit router when the packet comes into the site, or by the local host itself 🤔

packet header rewriting by remote network elements comes with a LOT of security considerations 😱 any packet rewriting mechanism has to provide proper protection against the attacks described in [threats], especially redirection attacks. this part is not optional bestie 🚨

another option for header rewriting at the site-exit point is for the host to do the endpoint-to-locator mapping itself, using one of the approaches outlined above. the catch here is that unicast reverse-path filtering is seriously deployed across the Internet as a counter-measure to source address spoofing 🛡️ using the example in Figure 1: if a host picks a locator from the ISP B address prefix and local routing sends that packet to site-exit router A, then the packet passed to ISP A would get discarded by those filters 💀 people have proposed various ways to change how the site forwarding environment behaves, and they all end up in the same place: packets using a source locator from the ISP B address prefix get passed to site-exit router B 🫶 these include forms of source address routing and site-exit router hand-over mechanisms. they also include augmenting the routing information between site-exit routers and local multi-homed hosts, so the host's choice of locator for the remote host matches the current local routing state the site uses to reach that remote host 🧚

6. Approaches to Endpoint Identity ✨

okay now we're talking about how the two parties actually learn each other's endpoint identity and the matching locators 🔑 both the identity protocol element approach and the modified protocol element approach need some form of information exchange so both sides know the other party's endpoint identity and its mapping to locators. there are a few ways to set that exchange up 💖

first up is what this document calls a "conventional" approach 🎀 the protocol data unit (PDU) passed down from the ULP gets wrapped with extra data elements that specifically relate to the EIP's function. that compound data element is then passed to the LLP as its PDU. when a PDU arrives from an LLP, the receiver pulls out the fields that belong to the EIP function and passes the rest of the PDU up to the ULP. the EIP works "in-band", talking to its remote peer through extra info wrapped around the ULP PDU 🌸 it's basically like generic tunnelling, where the outer encapsulation carries location address information, and the next-level packet header carries the identity information that's exposed and used at the location endpoints 🦋

another approach is to let the EIP talk over a separate communications channel 💜 the EIP generates dedicated messages aimed at its peer EIP, and passes those PDUs to the LLP independently of the PDUs it gets from the ULP. this lets an EIP exchange information and sync state with the remote EIP semi-independently of the ULP protocol exchange 🧚 one part of the EIP's job is transforming the ULP PDU to include locator information, so there's a related requirement: the EIP peering state has to stay synchronised with the exchange of ULP PDUs, so the remote EIP can correctly recognise the locator-to-endpoint mapping for each active session 🔥

one more potential approach is to let a third party hold the endpoint-to-locator mappings 🌈 this model already exists for name-to-IP address mappings done by the Domain Name System (DNS), where the mapping is obtained by asking a third party, namely a DNS resolver 👑 a similar third-party mapping between endpoints and a locator set could be supported through the DNS or a similar third-party referential mechanism. instead of each party swapping endpoint-to-locator mappings directly, this approach would get the mapping from a lookup for a DNS Endpoint-to-Locator set map contained as DNS Resource Records, for example ✨ iykyk, it's giving "ask the DNS, don't gossip"

6.1. Endpoint Identity Structure ✨

Okay so, last section we kept throwing around the term "endpoint identity" 💅 but we never stopped to ask what this thing could actually look like. Let's fix that, bestie 🎀 There are a bunch of big considerations about the structure and form of this identity that should be listed out in an architectural overview of this space.

One possible form is to borrow identity tokens straight from the underlying protocol's "address space" 🦋 An endpoint identity is basically a special-case instance of an IPv6 protocol address. This has a lot of perks, since the whole IP protocol suite and its apps already handle IP addresses all day 🫶 The big difference in a domain that separates endpoint identity from locator is that the identity parts of the protocol would operate on those addresses that play the identity role. The endpoint identity/locator mapping function would then map an endpoint "address" to a set of potential locator "addresses", and it would also do a reverse mapping from a locator "address" back to the distinguished endpoint identifier "address". The IP address space is hierarchically structured, so a suitably efficient mapping can happen in both directions 🌸 The underlying semantics of addresses in public networking already include the necessary considerations for global uniqueness of endpoint identity token values, which is iconic.

Could we take it further? Yes, and this is where it gets spicy 🔥 We could let the endpoint identifier also be a valid locator. That would imply a "distinguished" or "home" locator, and other locators could be dynamically mapped to this initial locator peering as required. The catch is that the endpoint identifier is now based on one of the transit provider's address prefixes, so changing transit provider would necessarily mean changing the endpoint identifier values within the multi-homed site. Not iconic 💀

Another option for address-formatted identifiers is to use distinguished identity address values that are not part of the global unicast locator space. That way, applications and protocol elements can tell identity values apart from locators based on the address prefix value ✨

It's also possible to let the endpoint identity and locator spaces overlap, and to tell the two realms apart by the context of usage instead of a prefix comparison. But reusing the locator token space for identity tokens has the potential to create an anomalous situation where a particular locator value is used as an identity value by a different endpoint 🙈 It isn't clear that the identity and locator contexts can be clearly disambiguated in every case, and that's a major drawback of this particular approach.

So if identity values are drawn from the protocol's address space, the basic choice seems to be either drawing them from a different part of that address space, or using a distinguished or home address as both a locator and an identity. The second option, using a locator as the basis of an endpoint identity, paired with a provider-aggregated address distribution architecture, leads to a multi-homed site using a provider-based address prefix as a common identity prefix. Just like locator addresses in a single-homed network, a change of provider connectivity implies a consequent renumbering of identity across the multi-homed site 😭 If avoiding that forced renumbering is a goal, there would be a preference for drawing identity tokens from a pool that is not aligned with network topology. This may point to a preference from this sector for identity token values that are not drawn from the locator address space 🧚

It's also feasible to use the fully qualified domain name (FQDN) as an endpoint identity, doing a similar mapping as described above with the FQDN as the lookup "key" 🎀 The implication is that there's no default "address" associated with the endpoint identifier, since the FQDN can be used in the context of session establishment, and a DNS query can establish a set of initial locators. Of course, there may not necessarily be a unique endpoint associated with an FQDN. In those cases, if there were multiple locator addresses associated with the FQDN via DNS RRs, shifting between locators may imply directing the packet to a different endpoint that has no knowledge of the active session on the original endpoint 💀 Yikes.

The syntactic properties of these two different identity realms have obvious considerations for how these identities may be used within PDUs 📝

Option three is a new structured identity space that is neither generated through the reuse of IPv6 address values nor drawn from the FQDN 🦋 Since the address space would need to be structured so it can be used as a lookup key to obtain the corresponding locator set, the obvious question is what additional or altered characteristics would make this endpoint identity space distinct from both of the above approaches? 🤔

The last one: instead of structured tokens that double as lookup keys for mapping endpoint identities to locator sets, you could use an unstructured token space, where individual token values are drawn opportunistically for use within a multi-homed session context 🌈 If unstructured tokens are used in a limited context, the semantics of the endpoint identity are subtly changed. The endpoint identity is no longer a persistent alias or reference to the identity of the endpoint. It's a means to let the identity protocol element confirm that two locators are part of the same mapped locator set for a remote endpoint. In this context, the unstructured opportunistic endpoint identifier values are used to determine locator equivalence rather than in some form of lookup function 💜

6.2. Persistent, Opportunistic, and Ephemeral Identities ✨

okay so the stuff in the last section? it's literally showing us the big difference in how people can split identity from location 🎀

first up is the persistent identity 💖. The idea is that the same identity value gets used everywhere this kind of identity is needed, whether that's for concurrent sessions or sequential ones. It's meant to stay the same over time and even when the underlying connectivity changes. It can also be totally separate from network topology, so the identity stays the same no matter what connectivity or locator addressing the site and host are using at the moment. Since the identity is persistent, you can use it as a reference to the endpoint stack, which is so iconic 😭. This is what makes multi-party referrals work: if A and B are talking, B can pass A's identity along to a third party C, and C can then use that identity to be the one who starts talking to A 🫶.

If you want to start a session with a persistent identifier, the identity acts as a lookup key to find the set of locators that belong to that endpoint. The lookup should be deterministic, reliable, robust, efficient, and trustable (the whole vibe is "it just works, every time" 💅). This means identities have to be uniquely assigned, and experience with identity systems really points toward a structured identity token space with an internal hierarchy of token components. These identity properties have a lot in common with unicast addresses and domain names 🧚. It also means persistent structured identities depend on well-ordered distribution and management mechanisms to keep their integrity and usefulness intact. Those mechanisms usually come with a big pile of administrative overhead 💀.

Now the other side: an unstructured identity space, where specific values are picked opportunistically from the space. In this case, the uniqueness of any one identity value isn't guaranteed 🙈. That changes how the identity works as a lookup key for finding locators, since the unstructured nature affects lookup efficiency, and the authenticity of the lookup gets weaker because uniqueness can't be assured. A more conservative way to use unstructured identities is to limit their scope, like with per-session identity keys. The identity is then only meaningful to the parties communicating, and only for the length of that session 🦋. So the identity becomes a session-level binding point that lets multiple locators be tied to one session, but it can't be used as a reference to an endpoint outside of that session. Opportunistic identities with a clearly limited scope don't need any well-ordered token distribution or management mechanisms, which is a huge plus 🌸.

There's also an ephemeral form. Here, the session identity is a piece of shared state between the endpoints, and it gets set up without swapping any particular token values that act as identity keys 🌈. It could be a defined set of locators, or a session key derived from some shared attributes of the session. With this form, there's no identifier being used or referenced to start a session at all. The ephemeral identity's job is pretty small: it just lets each end reliably figure out that a set of locators is semantically equivalent, within the membership of one particular session ⭐.

The last two forms are all about keeping management overhead low, and their mechanisms only reach as far as session integrity 🍓. That means if you want identity functions in other places or at other layers of the protocol stack, like inside referrals, inside an application's data payload, or as a key to start a communication session with a remote endpoint, you'd need some other identity function to handle it 🎀. Because these per-session identities are so limited, multi-homing approaches built on them have to use the existing mechanisms for starting a session. The session-based identity and the locator switching agility that goes with it end up being a negotiated session capability 🤝.

On the flip side, if you use a persistent identity as the session initiation key, the identity becomes part of the established session state. That means locator agility can just be an attribute of the session itself, instead of something that has to be negotiated later 👑. In a heterogeneous environment where this identity capability isn't deployed everywhere, the application should be able to fall back to a conventional session startup if a session can't be set up with a split identity/locator binding. It does that by mapping the identity to a specific locator value and starting the session with that value 🔥. The reason the application might want to know about this difference is that if it wants to use self-referential mechanisms inside the application payload, it only makes sense to use an identity-based self-reference when the remote party understands what that referential tag means 🙌.

In terms of functionality and semantics, opportunistic identities are a superset of ephemeral identities, even though the way they're implemented is really different 💜. Persistent identities support a superset of what opportunistic identities can do, and once again, the implementations will look different too ✨.

When it comes to multi-homing, using ephemeral identities for locator equivalence seems like a viable approach. It lets hosts use multiple locators in a negotiated way during communication between a pair of hosts, in most multi-homing situations 🦋. That said, ephemeral identities don't really offer much more than that. They can't be used in referential contexts, they can't be used to start communications, they give limited support for some forms of mobility, and they put some limits on which multi-homed scenarios can be supported 😬. Ephemeral identities are created inside an established communication state. So for multi-homing, the two endpoints need to have already found a viable pair of locators through existing mechanisms before they generate an ephemeral identity binding. That also implies there's some kind of static "home" for the endpoints, found through a conventional referential lookup 🏠.

A persistent identity space that supports dynamic translation between an equivalent set of locators and one or more equivalent identity values has the potential to be way more flexible for applications 🌟. Depending on how the mapping between identities and locators gets managed, this could stretch past multi-homing into things like nomadism, mobility, and service-specific functions 🚀. But there are still open questions. Nobody has fully figured out what secure mapping mechanisms would be needed for identity-to-locator mapping in the more general case, and it's also an open question how that mapping function would relate to viable endpoint-to-endpoint connectivity 🤔. It's a common thing across identity realms that the most critical part is how an identity gets resolved into some other attribute space 💅.

It seems reasonable to say that, within certain constraints, multi-homing doesn't automatically need the overhead of a fully separate persistent identity space and its identity resolution functionality. If the job of the multi-homing space is just to use a token for efficiently detecting locator equivalence, so sessions can survive changes (surviveability!), then ephemeral identities look like an adequate mechanism 🫶.

---

6.3. Common Issues for Multi-Homing Approaches 🌸

okay so the overview above covers a super wide range of possible approaches to multi-homing 🌈, and every single approach has its own set of things to think about when it comes to whether it's a good fit 🤓.

There is, however, a group of considerations that show up across all of the approaches 💖. We'll dig into those in more detail in this section ✨.

6.3.1. Triggering Locator Switches ✨

Okay so no matter how a packet gets generated, if a local multi-homed host is sending to a remote host, that packet has to carry a source locator when it goes into the transit network 🌸. The multi-homed host has a bunch of self-referential locators that are basically equivalent aliases in almost every way. The only real difference is that the locator choice can hint at which path the remote end uses to send stuff back to us 👀. So the big question is: how does the local host pick the "best" source locator? 🤔 The goal is to pick one that's a currently viable path from the remote host back to the multi-homed host. But local routing info doesn't include that reverse path info 😭. The host also doesn't necessarily know the extra policy rules on the remote side, which might make the remote host prefer one locator over another. And unicast reverse-path forwarding filters mean the selected source locator should get the packet to a site-exit router connected to the matching ISP transit provider, and then that router passes it on to the ISP 💅.

If the local multi-homed host is talking to a remote multi-homed host, the local host might get some say in choosing the destination locator 💁. The things to weigh here are local routing state (so the chosen destination locator is a viable path to the remote endpoint) and policy constraints that might decide which path counts as "best" 🎯. Source address selection might also need to be considered alongside destination locator selection 🧚.

Another big deal is figuring out when a locator is no longer considered viable, and what that does to the transport session state 💀.

• Transport Layer Triggers: A change from a currently-used path to another path could be triggered by indications of packet loss along the current path, through transport-level signalling or transport session timeouts, assuming there's an internal signalling mechanism between the transport stack element and the locator pool management stack element 🫶.
• ICMP Triggers: Path failure within the network may send back an ICMP Destination Unreachable packet to the sender. Rather than sending this signal to the transport level as an indicator of session failure, the IP layer should redirect the notification identity module as a trigger for a locator switch 🙈.
• Routing Triggers: If there are no local transport triggers, the site-exit router could communicate failure of the outbound forwarding path, as long as the remote host is multi-homed with an associated locator set. Conventional routing can't detect a failure in the inbound forwarding path, so routing triggers have some limitations when it comes to changing locator bindings 📉.
• Heartbeat Triggers: Another option is a session heartbeat protocol, where failure of the heartbeat would cause the session to seek a new locator binding that would reestablish the heartbeat 💓.
• Link Layer Triggers: Where supported, link layer triggers could act as a direct and immediate signal of link availability, where a "Link Down" indication says a particular link is unavailable [iab-link]. The catch is that a link level indication isn't a network broadcast event, and only the link's immediately-connected devices receive the link transition signal 🔌. This might be relevant for the degenerate case of a multi-homed site made of a single host. But in the case of a multi-host site, the site-exit router would need to use the link indication to generate one of the above indications so the host gets triggered for a locator change. That part is just conventional router detection of link status.

The sensitivity of the locator switch trigger matters a lot here 🎯. A super fine-grained sensitivity can generate false triggers from short-term transient path congestion, while coarse-grained triggers can impose an undue performance penalty on the session because it takes a long time to detect a path failure 🐢. The objectives for trigger sensitivity can be very different depending on the transport session being used. There's no doubt that any session needs a trigger to re-home if its path to the locator fails, but for some transports, moving and triggering transport-related changes may be far less desirable than reducing the trigger's sensitivity and waiting to see whether the triggering stimulus reaches a threshold level 🧘.

This is only partly solved by models with an internal signalling mechanism between the transport stack element and the locator pool management stack element. That's because of non-failure triggers coming from other stacks, and because of transport issues like the use of resource reservation 🎀. For example, picture a session with reservations established by RSVP or NSIS, when a routing change has just caused adaptive updates to the reservation state in a number of elements along its path. The transport protocol using that path is likely to see some delays or timeouts, and its reaction to those may be a trigger for a locator change, which is likely to mean another reservation update. That chaining of reservation updates may be a high overhead 😩. So individual transport protocols may have to tune any feedback they give as a locator change trigger, so they don't respond to certain forms of transient routing change delays (not knowing their cause) with a locator change 🫠. It's also worth noting that different transport protocols have rather different behaviors and hooks for management 🧩.

---

6.3.2. Locator Selection 💭

Picking a locator for the remote end is obviously constrained by the current state of the network topology, and the primary objective is to choose a viable locator that allows the packet to reach the intended destination point 🗺️. Selecting a source locator can be seen as signalling a preferred locator to the remote end for the local end to use. But where there are two or more viable locators that could be used, a particular pick may be influenced by some additional considerations ✨.

Choosing one locator from a viable locator set means choosing one particular network path in preference to other viable paths 🛣️. So with host-based locator selection, path selection and, by inference, traffic engineering functions aren't limited to network-based path manipulation through adjusting forwarding state in network elements 🌀. That creates an interaction between the locator selection process and traffic engineering functions. The use of an address selection policy table, as described in RFC 3484 [RFC3484], is relevant to the selection process 📋.

The element that does the locator selection, whether it's a protocol element within the host or a selection made at a site-exit router, also determines traffic policy 👑. So choosing between remote packet locator rewriting and host based locator selection shifts the policy capability from one element to the other 🔄.

If hosts make this policy determination, a more fine-grained outcome may be achievable, especially if the anticipated traffic characteristics of the application can be signalled to the locator selection process 🎯. Hosts may also need additional information if they're going to make locator address selection decisions based on some form of metric of relative load currently being imposed on select components of several end-to-end network paths 📊. These considerations raise the broader issue of whether traffic engineering is a network function entirely independent of host function, or an outcome of host interaction with the network 🤔.

In the latter case, there's also the question of whether the host is to interact with the network and, if so, how that interaction is to be signalled to hosts 💌.

6.3.3. Layering Identity ✨

okay so this is where it gets spicy 🌶️ because every layer of the protocol stack has its own different info and context, and that totally changes how identity/locator bindings get set up, kept alive, and expired 🫶

the questions are like: how much state gets stored, and which element is holding it? what level of context is it at (dynamic or fixed, per session or per host)? then there's state maintenance, which is about how stale or leftover state gets spotted and removed 🧹 and honestly the big one is does only ONE piece of code need to know about this binding, or do you have to change a bunch of transport protocols to make it work? and if you do have to change them, are the changes the same for every transport protocol, or does each one need its own special treatment? 🤔

the approaches being looked at include putting this functionality in the IP layer, in the end-to-end transport protocol layer, or as a shim sitting between the IP and transport protocol layers. three options, bestie, pick your fighter 🥊

placing identity at the transport protocol layer means the identity can be super tightly linked to a transport session 💖 session startup can kick off the initial identity/locator binding, transport protocol timeouts can be used as triggers for locator switches, and session termination can trigger expiration of the local identity/locator binding state. if you're using per-session opportunistic identity token values, the identity info can just live inside the overall session state 🎀 and with persistent identity token values, the implementation can choose per-session state, OR it can pool that info across multiple sessions to the same remote endpoint so it doesn't keep doing dynamic discovery of remote identity bindings over and over 🧚 that's a whole vibe of efficiency ✨

the catch 🙈 is that every transport protocol might need its own separate identity implementation. that's a huge constraint for UDP, because UDP has no inherent notion of session state at all. literally no session state 💀

the alternative is a distinct protocol element sitting between the transport and internet layers. the upside is that it gives a consistent mapping between identities and locators for ALL kinds of transport protocols 🌈 but this element isn't explicitly aware of sessions. so it would either have to discover the right identity/locator mapping for every identity-addressed packet passed down from the transport protocol, whether or not that mapping exists and whether or not it's part of a session context, or it would need an extra signalling mechanism to figure out when a mapping should be discovered and applied 😭 at this level there's also no explicit knowledge of when identity/locator mapping state is no longer needed, because nobody explicitly signals when all flows to and from a particular destination have stopped and the resources used to support that state can be released. and this element wouldn't be aware of transport-level timeouts either, so you'd have to add extra functionality to the transport protocol to trigger a locator switch at the identity protocol level. supporting per-session opportunistic identity structure is even harder here, since the transport protocol layer is what stores and manipulates per-session state. so when you build an identity element at this layer, it seems necessary to make sure enough information gets passed between the transport protocol, internet protocol, and identity protocol elements, so the identity element isn't forced into making possibly inaccurate assumptions about the current state of active sessions or end-to-end network paths 🧐

you can also embed the identity function within the internet protocol layer. as mentioned in the previous section, per-session information isn't readily available to the identity module, so per-session opportunistic identity values would be tricky to support this way 🙃 it's also hard to figure out when identity/locator state should be set up and released. you'd also need to signal transport-level timeouts to the identity module as a locator switch trigger. in this case, some attention needs to go toward synchronising locator switches and IP packet fragmentation 🧩 and IPSec needs to be considered too, so that you don't change the address field in the IP packet header in a way that triggers a condition at the remote end where the packet can't be recognised in the correct context 🚫

---

6.3.4. Session Startup and Maintenance 🧚

next up is the difference between the initial session startup mode of operation and maintaining the session state 💅

in a split endpoint identifier/locator environment, there needs to be at least one initial locator associated with an endpoint identifier so the two hosts can set up an initial connection 🫶 this locator could be loaded into the DNS in the conventional way. or, if the endpoint identifier is a distinguished address value, the initial communication could use the endpoint identifier in the role of a locator, meaning it gets used as a conventional address 🎀

the initial steps for establishing a session are pretty similar. if the session is based on an FQDN, the FQDN gets mapped to an endpoint identity value, and that endpoint identity value can then be mapped to a locator set ✨ the locators in that set are the candidate locators for setting up an initial synchronised state between the two hosts. once that state is established, the initial locator set can be updated with the current set of useable locators 🔄 this update could happen as part of the initial synchronisation actions, or it could be put off until it's actually needed. lowkey both are valid 👑

this leads to the idea of a "distinguished" locator that acts as the endpoint identifier, plus a pool of alternative locators associated with this "home" locator 🏠 that association can be statically defined using referential pointers in a third-party referral structure (like the DNS), or it can be added dynamically to the session through the actions of the EIP, or it can be both 🦋

now, if you're using opportunistic identities, where the identity isn't a fixed, discoverable value but one that's generated in the context of a session, then extra actions have to happen at session startup 🙈 there's still a need for defined locators to establish the session in the first place, but then an additional step is needed to generate session keys and exchange these values, so that multiple locators can be treated as the same identity within the session 🔐 this might look like a capability exchange plus an additional handshake and a token value exchange within the transport protocol, if you're doing an in-band approach. or it could be a separate protocol exchange at the level of the identity protocol element, done out-of-band from the transport session 💜

some approaches go a step further and separate initial session establishment from establishing the additional shared state inside the session that lets multiple locators be bound to a common endpoint identity 🌸 that extra stuff doesn't strictly have to happen at session startup. but it seems like it needs to happen before any loss of end-to-end connectivity on the selected initial locator, so any delay in that additional state exchange does raise the risk of the session getting disrupted by connectivity changes 😬

this brings up another question: is the identity/locator split a capability negotiation done per session or per remote end? or does the upper-level application using a distinguished identity value to identify the remote end just trigger the identity/locator mapping functionality further down the stack at the transport level, with no further capability negotiation inside the session? 🤷‍♀️

during startup there's also the consideration that the passive end of the connection may need to verify the proposed new address that's in the source address of incoming packets before using it as a destination address for outgoing packets 🕵️‍♀️ the sender's choice of source address doesn't automatically reflect a valid path from the receiver back to the source, which is a big deal 🚨 using the offered address seems like a low-overhead way to respond to connection attempts, but if that response fails, the receiver may need to discover the full locator set of the remote end through some locator discovery mechanism, so it can figure out whether there's a viable locator with a forwarding path that actually reaches the remote end 🗺️

the other option is that the passive end uses the initially offered locator and, if that works, leaves it to the identity modules in each stack to exchange information and establish the current complete locator set for each end 💫 this approach means the active end needs to cycle through all of its associated locators as source addresses until it gets a response or runs out of locators. and if the other end is multi-homed too (so it has multiple locators), the active end may need to cycle through all possible destination locators for each source locator 🔁 yes, this can take longer to confirm that no path exists to the remote end, but it has the potential to improve how the initial exchange holds up against denial-of-service attacks that could force the remote end into a high volume of spurious locator lookups 🛡️ that's a tradeoff worth knowing about, no cap 💖

6.3.5. Dynamic Capability Negotiation ✨

okay so the common thread across all these approaches is that they all change the end-to-end interaction 💅. BOTH ends have to know that identity and locator are split apart 🔥. ngl that makes this pretty sweeping, because the changes don't stop at the hosts and routers inside the multi-homed site. they reach into the IPv6 protocol itself 😭. so it's prudent to look at mechanisms that let the endpoints discover each other's capabilities, and only turn on this split identity/locator thing once it's established that both ends can support it 🫶.

it's also a corollary (fancy word, I know 🙈) that you don't have to lock in just one functionality this way. if the endpoint identity/locator mapping scheme comes out of a negotiation between the endpoints, they could negotiate to use one of a number of possible approaches 🦋. there's some interaction between the approach used and the form of endpoint identity, so take care that any acceptable outcome of the endpoint identity capability negotiation still lets the upper-level application keep operating 🎀.

6.3.6. Identity Uniqueness and Stability 🌸

when you think about long-lived identities, it's reasonable to assume that the identity assignment isn't necessarily permanent and unchangeable 🙈. in structured identity spaces, the identity value reflects a distribution hierarchy 🧚. there are a bunch of circumstances where changing the identity value is appropriate. for example, if an endpoint device gets moved across administrative realms of that hierarchy, its identity value will likely be reassigned to reflect the new realm 💜. it's also reasonable to assume that an endpoint may have more than one identity at any point in time. RFC 3014 [RFC3041] provides a rationale for using multiple identities like this 🔥.

if an endpoint's identity can change over time, and an endpoint can be identified by more than one identity at a single point in time, then some further characteristics of endpoint identifiers should be defined 👑. these cover how constant an endpoint identity stays within an application, and whether a transport session relies on a single endpoint identity value. if it does, we need to know whether that identity can change within the transport session, and under what conditions the old identity can keep being used after the change 💀. if the endpoint identity is a long-lived reference to a remote endpoint, and multiple identities can exist for one unique endpoint, then the question comes up of whether applications can compare identities for equivalence. it's also a question of whether applications need to recognise when different identities refer to the same endpoint 🫶. these identities might get used inside applications on a single host, or they might be identified within applications on different hosts 🌈.

---

7. Functional Decomposition of Multi-Homing Approaches 🧩

the following sections give us a framework for characterising multi-homing approaches 💅. the trick is breaking down the functions tied to session establishment, maintenance, and completion in a multi-homed environment into smaller pieces 🎀.

7.1. Establishing Session State 🦋

what form of token gets passed to the transport layer from the upper-level protocol element, to identify the local protocol stack? 🤔

what form of token gets passed to the transport layer from the upper-level protocol element, to identify the remote session target? 🎯

what form of token does the upper-level protocol element use as a self-identification mechanism inside the application payload? 💖

does the identity protocol element need to map the upper-level protocol's local and remote identity tokens into an identity token that identifies the session? if so, is that translation done before or after the initial session packet exchange handshake? ⏰

how does the session initiator establish that the remote end of the session can support the multi-homing capabilities in its protocol stack? if the remote end can't, does the multi-homing capable protocol element report a session establishment failure to the upper-level protocol, or does it silently fall back to a non-multi-homed protocol operation? 🙃

how do the endpoints discover the locator set available for each other endpoint (locator discovery)? 🔍

what mechanisms are used at each end to perform locator selection, for the local selection of source and destination locators? 🧭

what form of mechanism makes sure that the selected site exit path matches the selected packet source locator? 🛤️

7.2. Re-homing Triggers 🚨

what are the common denominator goals of re-homing triggers? what objectives should triggers conservatively meet across all types of sessions? 🌟

are there transport session-specific triggers? if so, which state changes within the network path should be triggers for all transport sessions, and which state changes are triggers only for selected transport sessions? 🍓

what triggers are used to identify that switching locators is desirable? 💅

are the triggers based on the end-to-end transport session, on notification of state changes within the network path from the network, or on both? 📡

what triggers can indicate the direction of the failed path, so the appropriate locator repair function gets triggered? 🛠️

7.3. Re-homing Locator Pair Selection 💜

what parameters determine the selection of a locator to use to reference the local endpoint? 🏠

if the remote endpoint is multi-homed, what parameters determine the selection of a locator to use to reference the remote endpoint? 🌐

must a change of an egress site-exit router be accompanied by a change in source and/or destination locators? 🤷‍♀️

how can new locators be added to the locator pool of an existing session? ➕

7.4. Locator Change 🔄

what are the preconditions that are necessary for a locator change? 📋

how can both ends confirm the locator change? 🤝

what interactions are necessary to synchronise the locator change with transport session behaviour? ⏱️

7.5. Removal of Session State 🧹

how is identity/locator binding state removal synchronised with session closure? 🔐

what binding information is cached for possible future use? 🗃️

8. Security Considerations 🔐

there are a significant number of security considerations that come from distinguishing endpoint identity and locator identity inside the protocol suite. this is serious business, bestie 😭

this document won't enumerate these considerations in detail. instead, it references a distinct document that describes the security considerations of this domain [threats] 📚.

9. Acknowledgements 🫶

the author thanks the following reviewers for their help: Brian Carpenter, Kurtis Lundqvist, Erik Nordmark, Iljitsch van Beijnum, Marcelo Bagnulo, John Loughney, Thierry Ernst, Joe Touch, Michael Patton, Ted Hardie, and Allison Mankin 💖👑.

10. Informative References 📖

[RFC3041]  Narten, T. and R. Draves, "Privacy Extensions for
           Stateless Address Autoconfiguration in IPv6", RFC 3041,
           January 2001.

[RFC3484]  Draves, R., "Default Address Selection for Internet
           Protocol version 6 (IPv6)", RFC 3484, February 2003.

[RFC3582]  Abley, J., Black, B., and V. Gill, "Goals for IPv6
           Site-Multihoming Architectures", RFC 3582, August 2003.

[RFC3775]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
           in IPv6", RFC 3775, June 2004.

[iab-link] Aboba, B., Ed., "Architectural Implications of Link Layer
           Indications", Work in Progress, January 2005.

[e2e]      Saltzer, J., Reed, D., and D. Clark, "End-to-End Arguments
           in System Design", ACM TOCS Vol 2, Number 4, pp 277-288,
           November 1984, <http://web.mit.edu/Saltzer/www/
           publications/endtoend/endtoend.txt>.

[rosec]    Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E.
           Nordmark, "Mobile IP version 6 Route Optimization Security
           Design Background", Work in Progress, October 2004.

[thinks]   Lear, E., "Things MULTI6 Developers should think about",
           Work in Progress, January 2005.

[threats]  Nordmark, E. and T. Li, "Threats relating to IPv6
           multi-homing solutions", Work in Progress, January 2005.

Author's Address 🖊️

Geoff Huston
APNIC

EMail: gih@apnic.net

Full Copyright Statement ⚖️

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 doesn't take any position on the validity or scope of any Intellectual Property Rights or other rights that might be claimed to apply to the implementation or use of the technology in this document. it also doesn't say whether any license under those rights might or might not be available, and it hasn't made any independent effort to find such rights. info on the procedures for rights in RFC documents is in BCP 78 and BCP 79 📜.

copies of IPR disclosures made to the IETF Secretariat, plus 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 to use such proprietary rights, 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 🌷✨