Support for Multi-Router and Multi-Prefix IPv6 Networks
draft-gont-6man-rfc8028-update-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) | |
|---|---|---|---|
| Author | Fernando 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-6man-rfc8028-update-00
IPv6 Maintenance (6man) Working Group F. Gont
Internet-Draft SI6 Networks
Updates: 4861, 4862, 8028, 8504 (if approved) 27 November 2024
Intended status: Standards Track
Expires: 31 May 2025
Support for Multi-Router and Multi-Prefix IPv6 Networks
draft-gont-6man-rfc8028-update-00
Abstract
This document specifies IPv6 host behavior to improve their support
for general and common multi-router and multi-prefix scenarios. It
formally updates RFC 4861, RFC 4862, and RFC 8028 such that such
scenarios are properly supported. This document also formally
updates RFC 8504, thus requiring support for multi-router and multi-
prefix scenarios in all IPv6 nodes.
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 Expires 31 May 2025 [Page 1]
Internet-Draft Improving Support for Multi-Router and M 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. Improving Support for Multi-Router and Multi-Prefix
Networks . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Host Support for Multi-Router and Multi-Prefix IPv6
Networks . . . . . . . . . . . . . . . . . . . . . . . . 3
3.2. Node Requirements . . . . . . . . . . . . . . . . . . . . 4
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . 4
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 4
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4
7.1. Normative References . . . . . . . . . . . . . . . . . . 4
7.2. Informative References . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
IPv6 Stateless Address Autoconfiguration (SLAAC) is based on the
assumption that SLAAC routers will advertise configuration
information on a local network, and SLAAC hosts will agregate this
information and use it as they see fits. In simple network scenarios
where there is a single local router, or where there are multiple
routers but all routers advertise the same information (or where all
advertised information is equivalent), SLAAC works just fine.
However, more complex (yet very common) scenarios are currently not
supported.
For example, in scenarios where a local network attaches to two
different upstream Internet Service Providers (ISP):
* A host may source packets from the IPv6 prefix of one ISP and
incorrectly send them via the second ISP, with the corresponding
traffic being dropped as a result of ingress-filtering [RFC2827].
Gont Expires 31 May 2025 [Page 2]
Internet-Draft Improving Support for Multi-Router and M November 2024
* A host may resolve DNS names using the recursive DNS server
advertised by one ISP, but then use the second ISP for sending
traffic to the corresponding IPv6 addresses, thus resulting in
suboptimal service or packet drops.
These scenarios, along with other common scenarios, are discussed in
detail in [draft-gont-v6ops-multi-ipv6-00]. This document pursues
the necessary standards-track work to improve the support for such
scenarios.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Improving Support for Multi-Router and Multi-Prefix Networks
3.1. Host Support for Multi-Router and Multi-Prefix IPv6 Networks
SLAAC hosts SHOULD record which router (as identified by its IPv6
link-local address and the associated zone index) advertised each
piece of SLAAC network configuration information.
For each piece of SLAAC network configuration, SLAAC hosts SHOULD
maintain separate state for each SLAAC router that advertised each
piecen of information.
This means that, for example, if two SLAAC routers advertise the
same IPv6 prefix via PIOs, a host will maintain a (Prefix,
remaining valid lifetime, remaining preferred lifetime) for each
router.
If a piece of configuration information, as associated with a
specific SLAAC router, becomes invalid SLAAC hosts SHOULD
disassociate the information with the corresponding router. SLAAC
hosts SHOULD NOT entirely discard the configuration information from
the system unless it has become dissassociated (ie. invalid) for all
routers that had advertised it.
Routing inforamation conveyed in SLAAC RIOs or Redirect messages
SHOULD be associated with the router that advertised it,and SHOULD
only be employed for IPv6 packets sourced from addresses in that
router's prefix set.
Gont Expires 31 May 2025 [Page 3]
Internet-Draft Improving Support for Multi-Router and M November 2024
Server-type information such as RDNSS SHOULD be associated with the
router that advertised it,and SHOULD only be employed for IPv6
packets sourced from addresses in that router's prefix set.
3.2. Node Requirements
This document formally updates [RFC8504] as follows:
Support for Multi-Router and Multi-Prefix Networks
Nodes MUST Implement the recommendations specified in [this
document].
4. IANA Considerations
This document has no actions for IANA.
5. Security Considerations
This document does not introduce any new attack vectors to the ones
associated with IPv8 Neighbor Discovery [RFC4861] and IPv6 Stateless
Address Autoconfiguration (SLAAC).
If attacks based on forged RA packets are a concern, technologies
such as RA-Guard [RFC6105] [RFC7113] should be deployed.
6. 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.
7. References
7.1. Normative References
[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>.
Gont Expires 31 May 2025 [Page 4]
Internet-Draft Improving Support for Multi-Router and M November 2024
[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>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8504] Chown, T., Loughney, J., and T. Winters, "IPv6 Node
Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504,
January 2019, <https://www.rfc-editor.org/info/rfc8504>.
7.2. Informative References
[draft-gont-v6ops-multi-ipv6-00]
Gont, F. and G. Gont, "Problem Statement about IPv6
Support for Multiple Routers and Multiple Interfaces",
IETF draft, November 2024,
<https://www.ietf.org/archive/id/draft-gont-v6ops-multi-
ipv6-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>.
[RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J.
Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105,
DOI 10.17487/RFC6105, February 2011,
<https://www.rfc-editor.org/info/rfc6105>.
[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
"Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,
<https://www.rfc-editor.org/info/rfc6724>.
Gont Expires 31 May 2025 [Page 5]
Internet-Draft Improving Support for Multi-Router and M November 2024
[RFC7113] Gont, F., "Implementation Advice for IPv6 Router
Advertisement Guard (RA-Guard)", RFC 7113,
DOI 10.17487/RFC7113, February 2014,
<https://www.rfc-editor.org/info/rfc7113>.
Author's Address
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
Gont Expires 31 May 2025 [Page 6]