Internet DRAFT - draft-troan-v6ops-extending-network-reqs
draft-troan-v6ops-extending-network-reqs
v6ops O. Troan
Internet-Draft Cisco Systems Inc.
Intended status: Informational 5 October 2023
Expires: 7 April 2024
Extending the Network - Host Requirements
draft-troan-v6ops-extending-network-reqs-00
Abstract
This memo describes the behaviour of a node that when connecting to a
network, offers connectivity via itself to other nodes (or entities
needing addresses) connected to it. The focus is on IPv6
connectivity, but the same principles could be applied to IPv4.
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 7 April 2024.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
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.
Troan Expires 7 April 2024 [Page 1]
Internet-Draft Extending the Network - Host Requirement October 2023
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Upstream link capabilities . . . . . . . . . . . . . . . 3
1.2. Considerations . . . . . . . . . . . . . . . . . . . . . 4
2. Mechanisms for network extensions . . . . . . . . . . . . . . 5
2.1. DHCPv6 Prefix Delegation . . . . . . . . . . . . . . . . 5
2.2. Ethernet Bridging . . . . . . . . . . . . . . . . . . . . 5
2.3. ND Proxy RFC4389 . . . . . . . . . . . . . . . . . . . . 5
2.4. Address sharing / stealing . . . . . . . . . . . . . . . 6
3. Methods of address assignment . . . . . . . . . . . . . . . . 6
3.1. SLAAC . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. DHCPv6 address assignment . . . . . . . . . . . . . . . . 6
3.3. Prefixless Address Assignment (PLAA) . . . . . . . . . . 6
3.4. DHCPv6 prefix delegation . . . . . . . . . . . . . . . . 7
3.5. Manual configuration . . . . . . . . . . . . . . . . . . 7
4. Topics for further considerations . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Normative References . . . . . . . . . . . . . . . . . . 8
6.2. Informative References . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
A node may have downstream links or host virtual machines or for
other reasons extend the upstream network. This memo describes the
requirements for such a node. The capabilities of the upstream
network determines what mechanism the Extending Node (EN) can use.
The EN may use one or more of the following mechanisms:
* Homenet Control Protocol (HNCP) [RFC7788]
* DHCPv6 Prefix Delegation (PD) [RFC8415]
* Ethernet Bridging
* ND Proxy [RFC4389]
* Address sharing / stealing
* NAPT66
* Multilink Subnet routing
The upstream link, that is the network link that the EN is connected
to upstream may or may not support protocols helping network
extensions. The EN may to some extent be able to detect the
Troan Expires 7 April 2024 [Page 2]
Internet-Draft Extending the Network - Host Requirement October 2023
capabilities of the upstream link. The EN acquires addresses on the
upstream link as described in [RFC7084]. The upstream link is either
numbered via SLAAC, via DHCPv6 address assignment or it's
"unnumbered". The EN should follow the requirements in RFC7084,
specifically requirements W-1 to W-5.
There is a level of recursion here. The mechanisms used on the
upstream network to extend the network can be used by another EN
below it and so on. Many of the mechanisms described here do not
handle loops well, so caution must be exercised. While the IPv6
address space is large, it is not infinite. Assigning a /64 to each
node is not feasible if the network is extended to enough levels or
if the initial network block is not large enough. These
considerations will determine if SLAAC is suitable for all the
downstream links.
There are two essential problems with extending the network.
Addressing and routing. There are multiple approaches depending on
the use cases and the limitations of the upstream network and
implementations.
1.1. Upstream link capabilities
* HNCP supported
* DHCPv6 PD supported
- Multiple prefixes supported
- Only a single prefix supported
- Only /64 prefixes supported
* Ethernet bridging supported
* SLAAC: /64 prefix assignment supported. No address limits.
* SLAAC: /64 prefix assignment supported. Address limits.
* DHCPv6: /64 prefix with individual addresses assigned via DHCPv6.
- Single address
- Multiple addresses
Troan Expires 7 April 2024 [Page 3]
Internet-Draft Extending the Network - Host Requirement October 2023
A /64 prefix may be advertised on the upstream link for stateless
address autoconfiguration (SLAAC), but it may still limit the number
of addresses a node may use. Similarly the network may use 802.1x
authentication limiting MAC addresses a host can use, or control the
addresses used by the node using DHCPv6 address assignment.
The network may or may not support DHCPv6 prefix assignment. If it
does, it may support multiple prefixes, or it may support only a
single prefix. It may support prefixes of any length, or it may
support only /64 prefixes. If the network supports HNCP, it may
restrict access to participate in the HNCP network.
The only mechanism that is guaranteed to work is one that is self-
similar. That means that the upstream network cannot distinguish
traffic from a downstream node from the traffic coming from the
directly attached node itself. The only mechanism that is self-
similar is NAPT66.
The EN must therefore go through a set of heuristics to determine
which method works for a given network.
1.2. Considerations
The EN must take address stability into consideration. While a
single address is "simple" to renumber. Renumber a network with a
large number of addresses is not. Global addresses are ephemeral.
And while IPv6 addresses and prefixes come with a lifetime, there is
no guarantee as it has been seen in operational networks that
networks keeps this promise. The EN must do it's best to support
renumbering of the downstream network. Both "announced" via correct
use of address/prefix lifetimes and "unannounced" by detecting that
the upstream network has renumbered. In addition the EN should
support the use of ULA addresses on the downstream network. And
connect that to the upstream network using one of NPTv6, NAT66 or
NAPT66 depending on the circumstances.
The EN is essentially a router. It has a duality upstream, acting as
a host to acquire addresses on the upstream interface. It acts as a
router and forwards packets between interfaces. In addition to
forwarding packets it must support acting as a router as specified in
[RFC4861]. It should also be able to act as a DHCPv6 server for
addresses and prefixes. For the purpose of source address selection,
it must follow the weak host model. The upstream interface may be
assigned only a link-local address and it that case the source
address selection algorithm must pick a source address from another
interface.
Troan Expires 7 April 2024 [Page 4]
Internet-Draft Extending the Network - Host Requirement October 2023
The EN doesn't necessarily know a priori how much address space it
needs. It also depends on which addressing model that is used. A
single /64 is enough to number an infinitely large downstream
network. But if each host or container is supposed to be numbered
with an individual /64 that will not scale well in many networks.
2. Mechanisms for network extensions
2.1. DHCPv6 Prefix Delegation
When used within an administrative domain DHCPv6 Prefix Delegation is
better named DHCPv6 Prefix Assignment. DHCPv6 PD allows the client
to request a prefix of any length. To more effectively use address
space, the EN should expect a "flat" PD deployment and not a
hierarchical one. Meaning the EN should request a prefix (a /64) for
each of it's downstream links. The upstream network decides to what
extent it wants to adhere to the prefix hint given by the client. It
may assign a /64 for each of the IA_PDs in the client's request or it
may assign a single /64 or an even longer prefix to the EN. Which
downstream addressing methods are available to the EN is determined
by the size of the prefix. E.g. if the EN is assingned a single /64
prefix, but has two downstream links, it has to use one of the DHCPv6
based addressing methods.
2.2. Ethernet Bridging
Bridging the upstream Ethernet segment the downstream Ethernet
segment makes all nodes on the downstream segment appear as if they
are on the upstream segment. It will look like all nodes are on the
same IPv6 link. That assumes the downstream datalinks are Ethernet
of course. We learnt back in the 80s that building huge Ethernet
collision domains wasn't always a good idea. Protocols like ND and
mDNS are very chatty and it exposes all downstream nodes to a lot of
chattiness. While a standard Ethhernet uses an MTU of 1500, many
networks use jumbo frames. The EN must be able to handle jumbo
frames.
Using bridging would also do nothing to alleivate the sizes required
for the upstream network ND caches, or any limits upstream devices
has in the terms of number of addresses they support.
2.3. ND Proxy [RFC4389]
This is when an address from the upstream prefix is used on a
downstream link. The EN must defend this address and respond to ND
address resolution requests for the address.
Troan Expires 7 April 2024 [Page 5]
Internet-Draft Extending the Network - Host Requirement October 2023
2.4. Address sharing / stealing
If only a single address is available on the upstream link, the EN
may number the downstream network using ULA addresses and connect to
the upstream network using NAPT66.
If there is a requirement of absoulte address stability in the
downstream network NAT66 or NPTv6 is used. With the downstream
network being numbered from the ULA address space.
3. Methods of address assignment
Depending on the size of the acquired prefix as well as user
preference / configuration, the EN may use one of the following
methods to assign addresses to downstream nodes.
These same mechanisms must be supported to acquire addresses on the
upstream link. These are described in [RFC7084].
3.1. SLAAC
A separate /64 prefix is assigned to each downstream link. The EN
advertises the /64 in a PIO option in the RA, with the A-flag on.
3.2. DHCPv6 address assignment
A separate IPv6 prefix of any length (larger than /128) is assigned
to each link. The EN acts as a DHCPv6 IA_NA server and assigns
addresses from the prefix to downstream nodes on that particular
link. The EN also assigns an addresses to itself from the prefix on
the downstream interface. The EN advertises the prefix in an RA with
the A-flag off, and the RA M-flag on.
3.3. Prefixless Address Assignment (PLAA)
The EN is assigned a block of addresses (an IPv6 prefix). The EN
assigns addresses to downstream nodes without assigning a prefix to
the downstream links. The EN acts as a DHCPv6 IA_NA server and
assigns addresses from the block of addresses to downstream nodes.
As addresses are assigned individually, the same address block
(prefix) is used to number nodes on all downstream links. The EN
installs a route in it's forwarding table for each address assigned.
The EN can also assign an addresses to itself from the block on a
virtual interface.
The EN advertises itself as a default router in an RA. The M-flag is
on, and the RA is sent without any PIO option.
Troan Expires 7 April 2024 [Page 6]
Internet-Draft Extending the Network - Host Requirement October 2023
3.4. DHCPv6 prefix delegation
DHCPv6 prefix delegation (or more correctly prefix assignment when it
is used within the same administrative domain) assigns a prefix to
the attached node, not an address to be used on the interface
attached to the link. The EN will install a route for the address
(or prefix) assigned to the downstream node, with the nodes link-
local address as next-hop. The downstream node needs to assign the
address or create an address from the prefix on a virtual interface.
The EN will not do ND (address resolution) on the downstream link for
the assigned address or prefix.
The downstream link can be unnumbered as in the above case. The EN
advertises itself as a default router in an RA. The M-flag is on,
and the RA is sent without any PIO option.
A downstream node should request a prefix if it is capable to do so.
It should also request an address using the IA_NA option if it is
capable to do so.
DHCPv6 prefix delegation can be seen as a superset of DHCPv6 address
assignment. As it can also assign individual addresses as well as
address prefixes.
3.5. Manual configuration
In many cases the network extensions are containers or virtual
machines running directly on the EN. In these cases as well as to
number it's own interfaces it can assign addresses to those directly.
Using whatever host specific tools exist for this. Unless the
numbered entities need to be onlink to each other, prefixless address
assignment should work well for this.
4. Topics for further considerations
Support for arbitrary topology downstream. Each node participates in
a routing protocol (if trusted) and advertises it's own address or
prefix in the downstream network. Each node acts as a DHCPv6 relay.
Sending all DHCPv6 requests to the "root" EN.
To extend the network a node should try in preference order: 1) HNCP
2) DHCPv6 PD 3) Ethernet Bridging
5. Security Considerations
TBD
6. References
Troan Expires 7 April 2024 [Page 7]
Internet-Draft Extending the Network - Host Requirement October 2023
6.1. Normative References
[RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery
Proxies (ND Proxy)", RFC 4389, DOI 10.17487/RFC4389, April
2006, <https://www.rfc-editor.org/info/rfc4389>.
[RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic
Requirements for IPv6 Customer Edge Routers", RFC 7084,
DOI 10.17487/RFC7084, November 2013,
<https://www.rfc-editor.org/info/rfc7084>.
6.2. Informative References
[RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking
Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April
2016, <https://www.rfc-editor.org/info/rfc7788>.
[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
Richardson, M., Jiang, S., Lemon, T., and T. Winters,
"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
RFC 8415, DOI 10.17487/RFC8415, November 2018,
<https://www.rfc-editor.org/info/rfc8415>.
[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>.
Author's Address
Ole Troan
Cisco Systems Inc.
Email: otroan@cisco.com
Troan Expires 7 April 2024 [Page 8]
