Problem Statement about IPv6 Support for Multiple Routers and Multiple Interfaces
draft-gont-v6ops-multi-ipv6-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Fernando Gont , Guillermo Gont | ||
| Last updated | 2024-11-27 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-gont-v6ops-multi-ipv6-00
IPv6 Operations Working Group (v6ops) F. Gont
Internet-Draft G. Gont
Intended status: Informational SI6 Networks
Expires: 31 May 2025 27 November 2024
Problem Statement about IPv6 Support for Multiple Routers and Multiple
Interfaces
draft-gont-v6ops-multi-ipv6-00
Abstract
This document discusses current limitations in IPv6 Stateless Address
Auto-cofiguration (SLAAC) that prevent support for common multi-
router and multi-interface scenarios. It provides discussion on the
challenges that these scenarios represent, and why a solution in this
space is warranted. Finally, it specifies a number of common
scenarios that any solution in this space should be able to address.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 31 May 2025.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
Gont & Gont Expires 31 May 2025 [Page 1]
Internet-Draft Problem Statement about Multi-Router and November 2024
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Multi-Router Scenario . . . . . . . . . . . . . . . . . . 3
3.2. Multi-Interface Scenario . . . . . . . . . . . . . . . . 5
3.3. Conflicting Information . . . . . . . . . . . . . . . . . 6
4. Prior Work . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
IPv6 Stateless Address Autoconfiguration (SLAAC) [RFC4862] is based
on the assumption that SLAAC routers advertise configuration
information on a local network, and SLAAC hosts will aggregate this
information and use it they see fits. Simple network scenarios where
there is a single local router, or where there are multiple routers
but all such routers advertise the same information and provide the
same service, SLAAC works just fine. However, other more complex
(yet very common) scenarios are currently unsupported (or may only be
supported by means of non-standard behaviors). These scenarios
include:
* A host that attaches to a local-area network (LAN) that employs
two different routers, one for each upstream Internet Service
Provider (ISP).
* A multihomed host connects to two (or more) different networks via
two (or more) network interfaces.
Gont & Gont Expires 31 May 2025 [Page 2]
Internet-Draft Problem Statement about Multi-Router and November 2024
* A host attaches to a local-area network, and receives conflicting
information from two or more SLAAC routers.
In the first two scenarios, a SLAAC host will end up receiving
information from two routers that are managed by different entities
(ISPs) and, for all practical purposes, each piece of configuration
information advertised by each router is only of use when employed in
conjunction with the rest of the information advertised by such
router, and via the router that advertised it. In other words,
mixing configuration information from the advertising routers will
usually lead to interoperability problems.
The third scenario could be considered a corner-case of the first two
scenarios: two or more routers send conflicting information, such as
the same SLAAC configuration information with different lifetimes
(e.g., one SLAAC router advertises the information with a lifetime of
zero, and another advertises the same information with non-zero
lifetime). In this scenario, a single router advertising
configuration information with a lifetime of zero may simply cause
hosts to remove that information altogether.
Section 2 defines the terminology employed throughout this document.
Section 3 elaborate on the scenarios described earlier in this
section, which not only serve to define the problem statement, but
also as test cases for any solution to it. Section 5 discusses
future work may be needed to address the problem at hand.
2. Terminology
Multi-router scenario:
A network scenario where two or more routers are attached to the
same link.
Multi-interface scenario:
A network scenario where a host employs two or more network
interfaces (without considering the "loopback" interface). Some
bibliography refer to these hosts as being "multihomed".
3. Scenarios
3.1. Multi-Router Scenario
Consider a network scenario where a user attaches two Customer
Premises Equipment (CPE) routers to a local network ("Network_C" in
our example) for improved network resilience, The scenario could be
defined/described as follows:
Gont & Gont Expires 31 May 2025 [Page 3]
Internet-Draft Problem Statement about Multi-Router and November 2024
* Two SLAAC routers (Router_A and Router_B) from different ISPs
(ISP_A and ISP_B, respectively) are attached to Network C
* Router A advertises prefix PREFIX_A for address configuration (by
means of a Prefix Information Option (PIO) [RFC4861]), and also
enforces ingress filtering [RFC2827].
* Router A also advertises one Recursive DNS server (RDNNSS_A) (by
means of Recursive DNS Server option [RFC8106]), and implements
ACLs such that it only processes requests from ISP_A customers.
* Router B advertises prefix PREFIX_B for address configuration (by
means of a Prefix Information Option (PIO) [RFC4861]), and also
enforces ingress filtering [RFC2827].
* Router B also advertises one Recursive DNS server (RDNSS_B) (by
means of Recursive DNS Server option [RFC8106]), and implements
ACLs such that it only processes requests from ISP_B customers.
* Host C attaches to Network C, and thus configures:
- Addresses in both prefixes (PREFIX_A and PREFIX_B).
- Two default routers (Router_A and Router_B).
- Two recursive DNS servers: RDNSS_A and RDNSS_B.
In this scenario, Host C may only send traffic from PREFIX_A via
ROUTER_A or from PREFIX_B via ROUTER_B: otherwise, packets will be
dropped as a result of ingress filtering [RFC2827]. Similarly, Host
C may only send DNS queries from PREFIX_A to RDNSS_A, or from
PREFIX_B to RDNSS_B: sending traffic from PREFIX_A to RDNSS_B or from
PREFIX_B to RDNSS_A will result in the ACLs enforced by the
respective ISPs to drop the DNS queries.
Additionally, it should be noted that it is quite common for DNS
responses to depend on the source address of the query. For example,
if ISP_A had a cache for the site www.example.com, it is quite likely
that a query for www.example.com will map to addresses that are
topologically close to ISP_A (or even within ISP_A), for improved
service. However, if Host C where to send DNS queries to RDNSS_A,
but then issue connections from PREFIX_B, it would most likely enjoy
suboptimal service (if not blocked).
Gont & Gont Expires 31 May 2025 [Page 4]
Internet-Draft Problem Statement about Multi-Router and November 2024
It should be evident that each piece of information being advertised
via SLAAC is only usable when employed in conjunction with the rest
of the information advertised by the same router. However, SLAAC
does not require this behavior: according to the current
specifications, hosts are free to use any piece of configuration they
learn via SLAAC as they see fit.
3.2. Multi-Interface Scenario
This scenario is similar to the one described in Section 3.1 with the
only difference in that a host communicated with the two routers over
different network interfaces.
Consider a network scenario where a user connects to two different
ISPs (ISP_A and ISP_B), via two different network interfaced (e.g.,
one Ethernet interface and a wireless Wi-Fi interface). The scenario
could be defined/described as follows:
* A SLAAC router (Router_A) from ISP_A is attached to Network_A.
* A SLAAC router (Router_B) from ISP_B is attached to Network_B.
* Router A advertises prefix PREFIX_A for address configuration (by
means of a Prefix Information Options (PIO) [RFC4861]), and also
enforces ingress filtering [RFC2827].
* Router A also advertises one Recursive DNS server (RDNNSS_A) (by
means of Recursive DNS Server option [RFC8106]), and implements
ACLs such that it only processes requests from ISP_A customers.
* Router B advertises prefix PREFIX_B for address configuration (by
means of a Prefix Information Options (PIO) [RFC4861]), and also
enforces ingress filtering [RFC2827].
* Router B also advertises one Recursive DNS server (RDNSS_B) (by
means of Recursive DNS Server option [RFC8106]), and implements
ACLs such that it only processes requests from ISP_B customers.
* Host C attaches to Network_A with one network interface, and to
Network_B with another network interface, and configures:
- Addresses in both prefixes (PREFIX_A and PREFIX_B).
- Two default routers (Router_A and Router_B).
- Two recursive DNS servers: RDNSS_A and RDNSS_B.
Gont & Gont Expires 31 May 2025 [Page 5]
Internet-Draft Problem Statement about Multi-Router and November 2024
In this scenario, Host C may only send traffic from PREFIX_A via
ROUTER_A or from PREFIX_B via ROUTER_B: otherwise, packets will be
dropped as a result of ingress filtering [RFC2827]. Similarly, Host
C may only send DNS queries from PREFIX_A to RDNSS_A, or from
PREFIX_B to RDNSS_B: sending traffic from PREFIX_A to RDNSS_B or from
PREFIX_B to RDNSS_A will resul in the ACLs enforced by the respective
ISPs to drop the DNS queries.
Additionally, it should be noted that it is quite common for DNS
responses to depend on the source address of the query. For example,
if ISP_A had a cache for the site www.example.com, it is quite likely
that a query for www.example.com will map to addresses that are
topologically close to ISP_A (or even within ISP_A), for improved
service. However, if Host C where to send DNS queries to RDNSS_A,
but then issue conenctions from PREFIX_B, it would most likely enjoy
suboptimal service (if not blocked).
It should be evident that each piece of information being advertised
via SLAAC is only usable when employed in conjuction with the rest of
the information advertised by the same router. However, SLAAC does
not require this behavior: acording to the current specifications,
hosts are free to use any piece of configuration they learn via SLAAC
as they see fit.
NOTE:
A host implementing the Weak End System (ES) model (see
Section 3.3.4.2 from [RFC1122]) could indeed send e.g. packets
from PREFIX_A to ROUTER_B.
3.3. Conflicting Information
Consider the case where two routers attach to the same network, and
advertise the same configuration information. That is,
* Two SLAAC routers (Router_A and Router_B) are attached to
Network_C
* Router A advertises prefix PREFIX_A for address configuration (by
means of a Prefix Information Option (PIO) [RFC4861]).
* Router A also advertises one Recursive DNS server (RDNNSS_A) (by
means of Recursive DNS Server option [RFC8106]).
* Router B advertises prefix PREFIX_A for address configuration (by
means of a Prefix Information Option (PIO) [RFC4861]).
* Router B also advertises one Recursive DNS server (RDNSS_A) (by
means of Recursive DNS Server option [RFC8106]).
Gont & Gont Expires 31 May 2025 [Page 6]
Internet-Draft Problem Statement about Multi-Router and November 2024
* Host C attaches to Network_C, and thus configures:
- Addresses in PREFIX_A.
- Two default routers (Router_A and Router_B).
- One recursive DNS servers: RDNSS_A.
Consider the case where e.g. Router_B is unable to refresh its
network configuration information from its upstream, and thus
advertises the same configuration as before, but with a lifetime of
0. That is, it advertises:
* A PIO conveying PREFIX_A with both a Preferred Lifetime and a
Valid Lifetime of 0.
* A RDNSS conveying RDNSS_A with a Lifetime of 0.
Presumably, this means that according to Router_B, this information
should no longer be used:
* Hosts should remove any configured addresses for such prefixes.
As a result, they would also abort any ongoing TCP connections.
* Hosts should also remove the corresponding RDNSS server from their
list of RDNSS servers.
This would also happen if Router_A was still announcing the same
configuration information with non-zero lifetimes.
It is clear that a more resilient behavior would be to maintain
different timers for each SLAAC advertising router. Thus, if a SLAAC
router advertised some configuration information with a lifetime of
0, this would simply mean that such configuration information would
be disassociated with that particular router. Only when
configuration information is no longer associated with any router
would the information be removed from the host altogether.
4. Prior Work
[RFC8028] has analyzed the challenge represented by having multiple
default routers when addresses from multiple prefixes are employed.
However, there are at least two gaps in the specification:
* Extrapolating RFC 8028 to other network configuration information
(such as Route Information Options (RIOs) [RFC4191] and RDNSS
[RFC8106]).
Gont & Gont Expires 31 May 2025 [Page 7]
Internet-Draft Problem Statement about Multi-Router and November 2024
* Considering some corner cases that must be properly handled when
implementing the recommendations from [RFC8028], such as how to
aggregate configuration information when the same information is
advertised by multiple routers, with different timers/lifetime
values (as discussed in Section 3.3).
5. Future Work
This document describes a number of common network scenarios that are
currently unsupported by IPv6. These scenarios have become more and
more common, as a result of:
* Increased number of home-office users, requiring the use of
multiple upstream ISP for improved resiliency
* Increased number of mobile users, which may not only connect via
the mobile operator but also via a Wi-Fi connection when
available.
As a result, this document concludes that protocol improvements that
accommodate these deployment scenarios are warranted.
[draft-gont-6man-rfc8028-update-00] is an ongoing effort to improve
IPv6 Support for Multiple Routers and Multiple Interfaces.
6. IANA Considerations
This document has no actions for IANA.
7. Security Considerations
This document does not introduce any new attack vectors.
8. Acknowledgments
The authors would like to thank (in alphabetical order) Brian
Carpenter for providing valuable comments on earlier versions of this
document.
Fernando would also like to thank Brian Carpenter who, over the
years, has answered many questions and provided valuable comments
that has benefited his protocol-related work.
9. References
9.1. Normative References
Gont & Gont Expires 31 May 2025 [Page 8]
Internet-Draft Problem Statement about Multi-Router and November 2024
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122,
DOI 10.17487/RFC1122, October 1989,
<https://www.rfc-editor.org/info/rfc1122>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and
More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191,
November 2005, <https://www.rfc-editor.org/info/rfc4191>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007,
<https://www.rfc-editor.org/info/rfc4861>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862,
DOI 10.17487/RFC4862, September 2007,
<https://www.rfc-editor.org/info/rfc4862>.
[RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by
Hosts in a Multi-Prefix Network", RFC 8028,
DOI 10.17487/RFC8028, November 2016,
<https://www.rfc-editor.org/info/rfc8028>.
[RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli,
"IPv6 Router Advertisement Options for DNS Configuration",
RFC 8106, DOI 10.17487/RFC8106, March 2017,
<https://www.rfc-editor.org/info/rfc8106>.
9.2. Informative References
[draft-gont-6man-rfc8028-update-00]
Gont, F., "Support for Multi-Router and Multi-Prefix IPv6
Networks", IETF draft, November 2024,
<https://www.ietf.org/archive/id/draft-gont-6man-rfc8028-
update-00.txt>.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
May 2000, <https://www.rfc-editor.org/info/rfc2827>.
Gont & Gont Expires 31 May 2025 [Page 9]
Internet-Draft Problem Statement about Multi-Router and November 2024
Authors' Addresses
Fernando Gont
SI6 Networks
Segurola y Habana 4310, 7mo Piso
Villa Devoto
Ciudad Autonoma de Buenos Aires
Argentina
Email: fgont@si6networks.com
URI: https://www.si6networks.com
Guillermo Gont
SI6 Networks
Segurola y Habana 4310, 7mo Piso
Villa Devoto
Ciudad Autonoma de Buenos Aires
Argentina
Email: ggont@si6networks.com
URI: https://www.si6networks.com
Gont & Gont Expires 31 May 2025 [Page 10]