RFC 3582

Goals for IPv6 Site-Multihoming Architectures

📅 published August 2003, from ietf

Goals for IPv6 Site-Multihoming Architectures 🎀

Okay bestie, this is RFC 3582 💅 It was written in August 2003 by J. Abley (ISC), B. Black (Layer8 Networks), and V. Gill (AOL Time Warner). It's Category: Informational, so it's giving info, not an Internet standard 📚 The title block doesn't list anything it obsoletes or updates, so no drama there 🙅‍♀️

Status of This Memo ✨

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

Copyright (C) The Internet Society (2003). All Rights Reserved.

Abstract 🦋

Okay so this doc lays out a set of goals for proposed new IPv6 site-multihoming architectures 🫶 It's recognised (it's giving honesty 💀) that this set of goals is ambitious, and that some goals may conflict with others. The solution or solutions adopted may only be able to satisfy some of the goals presented here 🥺

1. Introduction 🌸

Site-multihoming, which just means connecting to more than one IP service provider, is an essential part of service for lots of sites that make up the Internet 🌐

Current IPv4 site-multihoming practices got added on top of the CIDR architecture [1]. That architecture assumes routing table entries can be aggregated based on a hierarchy of customers and service providers 🌳

But it looks like that hierarchy is getting replaced by a dense mesh of interconnections [6]. On top of that, the number of multihomed sites has exploded 🚀 For redundancy and load-sharing, multihomed address blocks get pushed into the global table even when a provider aggregate already covers them. That makes the global routing table bigger and more turbulent, and it stresses the inter-provider routing system 😭

If the Internet and site-multihoming keep growing like this, the stress is going to get seriously worse 💀 The site-multihoming architecture for IPv6 should allow the routing system to scale more pleasantly 🧚

2. Terminology 💜

A "site" is an entity that autonomously operates a network using IP. In particular, it decides the addressing plan and routing policy for that network 🎀 This definition is meant to be equivalent to "enterprise" as defined in [2].

A "transit provider" runs a site that directly provides connectivity to the Internet for one or more external sites. That connectivity goes beyond the transit provider's own site, and the transit provider's site is directly connected to the sites it provides transit for 🚦

A "multihomed" site is one with more than one transit provider. "Site-multihoming" is the practice of arranging a site to be multihomed 🦄

The term "re-homing" means a site moving between two states of connectedness, because the connectivity between the site and its transit providers' sites changed 🔁

3. Multihoming Goals 👑

3.1. Capabilities of IPv4 Multihoming ✨

These are the capabilities of current IPv4 multihoming practices that an IPv6 multihoming architecture should support 💅

3.1.1. Redundancy 🛡️

By multihoming, a site should be able to insulate itself from certain failure modes within one or more transit providers, along with failures in the network providing interconnection among those transit providers 🙌

Stuff below the IP layer can make connectivity look diverse when it isn't really, because it shares single points of failure 🙈 For example, two separate DS3 circuits from different suppliers, connecting a site to independent transit providers, might share a single conduit from the street into a building. So one incident in the street could knock out both circuits at once. That's what's known as "backhoe-fade" 😭 Those two circuits are said to "share fate" 💀

The multihoming architecture should accommodate continuity of connectivity during the following failures, in the general case and even with shared fate in the mix:

  • Physical failure, such as a fiber cut, or router failure,
  • Logical link failure, such as a misbehaving router interface,
  • Routing protocol failure, such as a BGP peer reset,
  • Transit provider failure, such as a backbone-wide IGP failure, and
  • Exchange failure, such as a BGP reset on an inter-provider peering.

3.1.2. Load Sharing ⚖️

By multihoming, a site should be able to distribute both inbound and outbound traffic between multiple transit providers. This is about using multiple transit providers at the same time, not just using one provider for one stretch of time and another provider for a different stretch 🔥

3.1.3. Performance 🚀

By multihoming, a site should be able to protect itself from performance difficulties directly between the site's transit providers 🛸

Say site E gets transit from transit providers T1 and T2, and there's long-term congestion between T1 and T2. The multihoming architecture should allow E to make sure that, in normal operation, none of its traffic goes over the congested T1-T2 interconnection. The process for doing that should be a manual one 🛠️

A multihomed site should also be able to distribute inbound traffic from particular multiple transit providers, based on the particular address range within their site that's sourcing or sinking the traffic 🎯

3.1.4. Policy 📋

A customer might multihome for a bunch of policy reasons that are beyond technical scope, like cost, acceptable use conditions, etc. 💸 For example, customer C is homed to ISP A but wants to shift a certain class or application, like NNTP, over to ISP B as a matter of policy. A new IPv6 multihoming proposal should support site-multihoming for external policy reasons 🙌

3.1.5. Simplicity 🧸

Any proposed multihoming solution has to be deployed in real networks with real customers, so simplicity is paramount 👑 The current multihoming solution is quite straightforward to deploy and maintain.

A new IPv6 multihoming solution should not be substantially more complex to deploy and operate, either for multihomed sites or for the rest of the Internet, than current IPv4 multihoming practices 🫶

3.1.6. Transport-Layer Survivability 🦋

Multihoming solutions should provide re-homing transparency for transport-layer sessions. In other words, data exchanged between devices on the multihomed site and devices elsewhere on the Internet may carry on with no more interruption than the brief packet loss during the re-homing event 🌊

New transport-layer sessions should be able to be created following a re-homing event ✨

Transport-layer sessions include ones using transport-layer protocols like TCP, UDP, and SCTP over IP. Applications that communicate over raw IP and other network-layer protocols may also enjoy re-homing transparency 🧚

3.1.7. Impact on DNS 🌐

Multi-homing solutions either should be compatible with the observed dynamics of the current DNS system, or the solutions should demonstrate that the modified name resolution system required to support them is readily deployable 💅

3.1.8. Packet Filtering 🚧

Multihoming solutions should not preclude filtering packets with forged or otherwise inappropriate source IP addresses at the administrative boundary of the multihomed site, or at the administrative boundaries of any site in the Internet 🙅‍♀️

3.2. Additional Requirements 🌈

3.2.1. Scalability 📈

Current IPV4 multihoming practices contribute to the big growth we're seeing in the state held in the global inter-provider routing system 😭 That's a concern for two reasons: the hardware requirements it imposes, and the impact on the stability of the routing system. This issue is discussed in great detail in [6] 📚

A new IPv6 multihoming architecture should scale to accommodate orders of magnitude more multihomed sites without imposing unreasonable requirements on the routing system 🚀

3.2.2. Impact on Routers 🖥️

The solutions may require changes to IPv6 router implementations. These changes should be either minor, or in the form of logically separate functions added to existing functions 🔧

Those changes should not prevent normal single-homed operation. Routers that implement these changes should be able to interoperate fully with hosts and routers that don't implement them 🤝

3.2.3. Impact on Hosts 💻

The solution should not destroy IPv6 connectivity for a legacy host implementing RFC 3513 [3], RFC 2460 [4], RFC 3493 [5], and other basic IPv6 specifications that were current in April 2003. In other words, if a host can work in a single-homed site, it should still be able to work in a multihomed site, even if it can't benefit from site-multihoming 🥹

It would be compatible with this goal for such a host to lose connectivity if a site lost connectivity to one transit provider, even though other transit provider connections were still operational 😬

If the solution requires changes to the host stack, these changes should be either minor, or in the form of logically separate functions added to existing functions 🧩

If the solution requires changes to the socket API and/or the transport layer, it should be possible to keep the original socket API and transport protocols running in parallel, even if they can't benefit from multihoming 🫶

The multihoming solution may allow host or application changes if that would enhance transport-layer survivability ✨

3.2.4. Interaction between Hosts and the Routing System 🔗

The solution may involve interaction between a site's hosts and its routing system. That interaction should be simple, scalable, and securable 🔐

3.2.5. Operations and Management 🛠️

It should be possible for the staff who run a site to monitor and configure the site's multihoming system 👩‍💻

3.2.6. Cooperation between Transit Providers 🤝

A multihoming strategy may require cooperation between a site and its transit providers. It should not require cooperation directly between the transit providers, at least not cooperation that's specifically about the multihomed site 🙅

Any inter-site cooperation that might be needed to make the multihoming solution work should be examined and assessed from the point of view of operational practicality 🧐

3.2.7. Multiple Solutions 🧩

There may be more than one approach to multihoming, as long as all the approaches are orthogonal. That means each approach covers a distinct segment or category within the site multihoming problem 💜 Multiple solutions do add more management overhead, though, so the adopted solutions should attempt to cover as many multihoming scenarios and goals as possible 🌟

4. Security Considerations 🔐

⚠️ This part is serious, so pay attention!

A multihomed site should not be more vulnerable to security breaches than a traditionally IPv4-multihomed site 🚨

Any changes to routing practices made to accommodate multihomed sites should not cause non-multihomed sites to become more vulnerable to security breaches 😱

5. Intellectual Property Statement 💅

Okay so the IETF is not picking a side on IP stuff here. It doesn't say whether any rights people claim over this tech are valid or how far they reach, and it doesn't say whether licenses are even available. It also hasn't gone hunting for any rights at all, so yeah, no promises. 🙈 If you want the IETF's rules on rights for standards-track and standards-related documents, those live in BCP-11. Any claims of rights that people have filed for publication, any licensing assurances, or the results of anyone trying to get a general license or permission for using proprietary rights from this spec can all be requested from the IETF Secretariat. 📬

The IETF also wants you to speak up. If you know about any copyrights, patents, patent applications, or other proprietary rights that might cover technology you'd need to implement this standard, tell them! 🫶 Send that info to the IETF Executive Director.

6. Normative References 📚

These are the sources this document depends on, so they're part of the spec, not extra reading. ✨

  • [1] Fuller, V., Li, T., Yu, J. and K. Varadhan, "Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy", RFC 1519, September 1993.
  • [2] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
  • [3] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.
  • [4] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
  • [5] Gilligan, R., Thomson, S., Bound, J., McCann, J. and W. Stevens, "Basic Socket Interface Extensions for IPv6", RFC 3493, February 2003.
  • [6] Huston, G., "Commentary on Inter-Domain Routing in the Internet", RFC 3221, December 2001.

7. Authors' Addresses 💌

Here are the authors, bestie! 🌸 Say hi to them.

Joe Abley
Internet Software Consortium
950 Charter Street
Redwood City, CA  94063
USA

Phone: +1 650 423 1317
EMail: jabley@isc.org


Benjamin Black
Layer8 Networks

EMail: ben@layer8.net


Vijay Gill
AOL Time Warner

EMail: vijaygill9@aol.com

Copyright (C) The Internet Society (2003). All Rights Reserved. 🎀

Okay, so the rules for sharing this one are pretty generous. You can copy it and give it to other people, and you can make derivative works that comment on it, explain it, or help people implement it. You can publish and distribute all of that too, in whole or in part, with no real restrictions, as long as the copyright notice and this paragraph stay on every copy and derivative work. 🦋

The catch is that this document itself can't be modified in any way. That includes removing the copyright notice or the references to the Internet Society or other Internet organizations. The exceptions are when you need it for developing Internet standards, in which case you have to follow the copyright procedures in the Internet Standards process, or when you're translating it into a language other than English. 🌈

The permissions above are perpetual, and the Internet Society or its successors or assignees won't revoke them. 💜

Also, this document and the info in it is provided "AS IS", and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Basically, they're not promising it's perfect, so be careful out there. 💀

Acknowledgement 🧚

Funding for the RFC Editor function is currently provided by the Internet Society. Thank you, Internet Society! 🌈✨

📦 where this page comes from