| Internet-Draft | Routers Verses Hosts; Devices Verses Fun | August 2022 |
| Smith | Expires 24 February 2023 | [Page] |
This memo discusses the differences between routers verses hosts, as devices verses functions.¶
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 24 February 2023.¶
Copyright (c) 2022 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.¶
This memo discusses the differences between routers verses hosts, as devices verses functions.¶
While using IPv6 terminology, functions and node roles, it is really a more general discussion about entities that originate protocol data units, receive protocol data units, and forward protocol data units between them. In other words, it is using IPv6 as an example of a more general network protocol model, that can also be applied to other layer 2 and layer 3 protocols, such as IPv4 and Ethernet.¶
The sorts of questions that have prompted this memo are:¶
[RFC8200] defines an IPv6 node, and two types of IPv6 nodes:¶
Although "node" is described as a device, and most people will think of a "device" as a physical, well, device, "host" and "router" are really functional definitions, indicating the goal and type of processing that is to be performed on the IPv6 packet by the node.¶
Stephen Deering, one of the co-designers of IPv6 [RFC8200], has described routers in functional terms in other RFCs. For example, in [RFC1075], a "router" is described as:¶
Or, in [RFC1256] (the likely origin of IPv6 Router Advertisements), a router is defined as:¶
The definition of the word "device" doesn't actually require a device to be physical [DICTIONARY REF, VW DEFEAT DEVICE].¶
In this memo we will consider routers and hosts as functions before considering routers and hosts as physical devices.¶
As per the [RFC8200] definition, the goal of the routing function is to forward an IPv6 packet towards an IPv6 node that explicitly holds the packet's destination address. This forwarding function is limited to the fixed portion of the IPv6 header, so that it can be performed as simply, and therefore as fast as possible. Simpler operations on a packet can better facilitate faster and cheaper implementations, both in software and in fixed or limited function hardware.¶
The simplicity of forwarding based on just the IPv6 fixed header, and the ignorance of the packet's payload, allows the network to be upper layer transport protocol, and application protocol and payload agnostic. Deploying new transport layer protocols and applications should be as simple as implementing and deploying them only on the IPv6 nodes that send and receive those packets to and from the network - the hosts. The network itself should not need any changes or upgrades to support new transport protocols and application protocols.¶
This network agnosticity to new transport layer protocols and new application protocols is also known as network transparency [TRANSPARENCY RFCs].¶
Limiting forwarding to the IPv6 fixed header allows the packet's payload and many of its Extension Headers to be encrypted, excepting the encryption function Extension Header or headers themselves. While on the network, outside of the sending and receiving hosts, the encrypted Extension Headers and payload look like a bunch of random bits. For the Extension Headers after the encrypton header, and the packet payload - meaning the majority of the contents of the packet, encryption is enforcing the network transparency that should already exist without it.¶
If the goal of the routing function is to forward packets "not explicitly addressed to itself", and a host is "any node that is not a router", then it means that all IPv6 nodes that hold IPv6 addresses are hosts.¶
Or rather, IPv6 addresses are only assigned to hosts. IPv6 addresses are always host addresses.¶
This also means only hosts originate packets, and only hosts receive packets. Routers only forward packets.¶
Remember, these host and router definitions are functional, not router or host physical "device" definitions, and also remember that a "device" isn't actually required to be a physical thing.¶
Routers and hosts as physical devices are discussed later.¶
The goal of the host function is to process the IPv6 packet in depth, beyond the IPv6 fixed header, when the packet arrives at the host holding the destination address specified in the packet.¶
The type of processing to be performed is specified by the IPv6 packet's fixed header next header field, optional Extension Headers, and then subsequent transport layer header (an Extension Header too, as it falls within the Extension Header number space), transport layer protocol options, and application payload information.¶
If a number of the packet's Extension Headers and its payload has been encrypted, then the receiving host holding the destination address needs to have the encryption key required to decrypt them.¶
Host processing of packets could be more generally thought of as packet payload processing. The packet has a fixed header who's main purpose is to have the packet delivered to its destination - the host holding the packet's destination address. Processing of the packet's payload beyond fixed header then occurs at that destination.¶
There is a clear demarcation point between when a packet is being processed for the purpose of routing or forwarding, and when the packet is then processed in more depth for host processing. That demarcation point is specifically identified by the packet's destination address, and the pivot from the packet being routed or forwarded to the packet being host processed occurs when the packet has been forwarded to an IPv6 host that holds the packet's destination address.¶
Conceptually, while the packet is being forwarded by the network towards the packet's destination address, the packet can be imagined to be travelling horizontally across the network. When the packet arrives at the host holding the packet's destination address, the packet can be imagined to pivot 90 degrees to travelling in vertical direction, for deeper packet and therefore host processing, as it travels up the host's protocol stack for further local network, transport and application layer processing.¶
The contiguous span of interconnected IPv6 nodes, where forwarding occurs (meaning the nodes are IPv6 routers), could be described as the "forwarding domain" of a packet, with the forwarding domain bounded by the hosts identified by the forwarded packets' source and destination addresses.¶
The communications model the Internet Protocols follows is very close to that of the physical postal mail and package distribution systems.¶
The postal system doesn't care about or inspect what is inside of the envelopes or packages (a synonym of packets) that are submitted to it to be delivered. The only goal is to to deliver the envelope, package or packet from the source address to the destination address on the outside of the container.¶
The postal system is transparent to the contents of the envelope, package or packets it is asked to deliver. Whether a envelope carries a large value financial check (cheque), or a package is carrying 1 kilogram of gold is not visible to the postal system. Delivery occurs regardless, usually dependent on weight. 1 kilogram of lead or gold will by default cost the same to transport, despite their financial value being significantly different. (Better quality, meaning more reliable delivery of the package containing gold could be purchased, as could insurance against its loss. This would also act as a signal to the postal system that this package contains something of more significant value, increasing the risk of non-delivery due to theft occuring within the postal system.)¶
Once the envelope, package or packet arrives at the specified destination address, it is then open and its contents (payload) are "processed" by the receiver identified by the destination address.¶
Payload encryption isn't commonly used (or used at all?) to ensure that envelopes and packages contents are protected "mid-flight", preserving payload transparency. However, this transparency is instead enforced by very strong laws with harsh pentalities against unauthorised opening of envelopes and packets (e.g. in Australia, the penalty is 2 to 5 years in jail [REF]). (Postcards are an interesting case - clearly the payload is visible to the postal system, since they're not enclosed in an enverlope. However, that's known and expected by the sender. Postcards could have their payload text encrypted by the sender.)¶
[IEN5] "SPECIFICATION OF INTERNET TRANSMISSION CONTROL PROGRAM - TCP - (Version 2)" clearly links the Internet Protocol architecture to the postal system by saying that "The TCP acts in many ways like a postal service since it provides a way for processes to exchange letters with each other.", and by using the term "letter" to describe messages between processes that are using TCP. Note that this was before the Internet Protocol was split off from TCP in [IENxx] (which became known as TCP/IP), so the term "TCP" is implicitly applying to IP.¶
The Internet communications model is not new, it is really just an electronic version of the 2500 year old postal system [REF]. Postal envelopes, packages and packets are analogs of Internet Protocol packets. What processing should happen where in the Internet and, in packet forwarding in general, can be strongly guided by the history and evolution of the physical postal system.¶
The term "Dumb network, smart hosts" [Huitema] has been used to summarise the fundamental model of the Internet protocols. Hosts do smart (and complex) packet processing, the network does dumb (and therefore fast) packet processing (i.e., forwarding).¶
One of the very significant advantages of this model is that it has allowed the Internet to better scale. Since the paths across the Internet (between the smart hosts at the edge) are dumb, more paths across the Internet can be more easily added.¶
By intentionally pushing complexity to the many smart hosts at the edge, the model facilitates horizontal scaling by distributing application load across multiple destination hosts if the application architecture can support it. New capacity can be added without having to replace existing capacity.¶
Multipath transport layer protocols [MPTCP] that distribute application traffic across multiple dumb paths via sets of source and destination IP addresses have also been facilitated. They can increase application traffic throughput as well as availability, because they can survive either host's n-1 attachments to the network failing.¶
Finally, incremental upgrades of features available to users is provided by the model, by limiting upgrades to the only the involved hosts. Upgrades to the Internet are not required to support new applications or new transport layer protocols. [INTERNET TRANSPARENCY]¶
This "dumb network, smart hosts" model also describes the physical postal system model. The benefits are the same. The contents of an envelope, package or (physical) packet can change, as they have in the past 2500 years, as can the processing at the destination, yet the postal distribution network does not have to be changed, as long as the delivery addresses remain consistent.¶
The dumber the network, and the smarter the ends (hosts, postal destinations), the better off their end-users are.¶
While a packet travels from its original source host towards its final destination host, it may need more than just simple IPv6 routing or forwarding. More in depth packet processing may need to occur at certain points on the path beyond the fixed IPv6 header used for forwarding. This is known as "Hop-by-Hop" packet processing.¶
By the [RFC8200] definitions, and the previous discussion, processing of packets beyond the fixed header part is host processing.¶
So when a packet travels across a network, and at certain points along the way, the packet is host processed, rather than just simply fast forwarded. These way points should be identified and encoded in the packet's destination address field as the packet follows its path from its original source towards and to its final destination.¶
Along that path, the packet's current destination address moves the packet out its current forwarding domain for more complex host processing. Once the more complex host processing has occurred, the packet is sent back into a new instance of a forwarding domain for delivery to the new next hop, now identified by the packet's newly replaced destination address.¶
This hop by hop processing path across the network from the original packet source host to the final packet destination consists of a set of separate forwarding domains, delimited by intermediate hosts. The path could be described as a set of hops between a series of hosts.¶
Per [RFC8200], "The Routing header is used by an IPv6 source to list one or more intermediate nodes to be visited on the way to a packet's destination."¶
The intermediate nodes are identified by a list of IPv6 destination addresses. Consequently, going by the [RFC8200] router and host definitions, a Routing Header is listing a set of hosts to visit on a path towards the final host, also identified by an IPv6 destination address.¶
The Hop-by-Hop Options Header "is used to carry optional information that may be examined and processed by every node along a packet's delivery path. The Hop-by-Hop Options header is identified by a Next Header value of 0 in the IPv6 header ..."¶
The information to be processed at each hop, encoded in the Hop-by-Hop Options Header, is beyond the fixed header of the packet, and the processing involved is beyond the purpose of forwarding and delivering the packet to the packet's destination address.¶
This is host or packet payload processing beyond the fixed IPv6 header. Yet it is not normally occurring at an IPv6 node, or rather host, that holds the packet's destination address.¶
[RFC2460] required all routers to look for the Hop-by-Hop options header, and to process it if present. [RFC8200] loosened this requirement because high performance IPv6 forwarding implementations were purely forwarding on a packet's destination address. Router implementations weren't looking past the IPv6 fixed header.¶
It is common for many, if not all people in networking to imagine a "router" or a "host" as a physical device, with physical attributes that are typical of the function being performed by and that suit the common use of the device.¶
A typical "router" device will normally have multiple physical network interfaces to attach to links that it will route or forward packets between. With exception to most small router devices intended to be used in residential networks, a typical router device will have physical options to be mounted in an electronic equipment 19 inch rack. It will have status and other LEDs, and perhaps a small LCD display, to show information relevant to being a router device. It may have other interfaces or ports allowing a screen and keyboard to be attached, however permanent attachment of a screen and keyboard is not intended. It is not an end-user oriented device.¶
Not only will this router device forward packets, it will also accept packets destined to IPv6 addresses assigned to its interfaces, or emit packets using those interface addresses as source addresses. These packets will contain various upper layer protocol payloads, most carried in transport and application layer protocols, such as ICMPv6, OSPFv3, Multiprotocol BGP, SNMP, SSH and HTTPS. These packets will be carrying information for the purpose of the operation of the forwarding function (ICMPv6, OSPFv3, MP-BGP), monitoring (SNMP), and device management (TELNET, SSH, HTTPS).¶
Going by the [RFC8200] host and router definitions, this router device is performing both router and host functions. It is router forwarding packets not addressed to itself, and host processing packets that are addressed to itself (or sent from itself). The physical form of being a router device is hiding the combination of IPv6 router and host functions it is performing concurrently.¶
(In theory a device could be designed to just forward packets, and not perform any host packet processing functions. It would have to acquire forwarding function information via some mechanism that doesn't involve host processing of packets. Has such a device ever existed, either in IPv4 or IPv6? It wouldn't need any IPv6 (or IPv4) addresses, because it doesn't host process any packets; it only forwards them. It would never be the original source or final destination of any IPv6 (or IPv4) packets at all. The moment it has an IPv4 or IPv6 address, it is performing host packet processing. If it has ever existed, perhaps it loaded its forwarding information from 8 inch floppy disk?)¶
It would be typical for people to imagine a host device as some form of computer that can be directly interacted with by humans, and runs applications that are directly used by humans. These imagined host devices would probably resemble a desktop or laptop personal computer, or perhaps a mini or mainframe computer with end-user terminals attached.¶
It would also be typical to imagine that these host devices have a single point of attachment to the network. However, it is possible that a host device has multiple network interfaces, attaching it multiple times to the same network, or possibly to different networks. The motivation for a host to be network attached multiply is either performance, redundancy or both. These types of hosts are known as "multi-homed" in IETF documents.¶
The routing or forwarding function is "fast path", because processing while a packet is being forwarded is simple, based on the fixed IPv6 header.¶
If packets, while travelling across the network, need to be processed in more depth than is required for forwarding, at certain way points, then as discussed, the processing that is occurring on the packet is host processing. Since this is not fast path processing, then it is cleary "slow path" processing.¶
When a router as a device, from a router vendor, is used as a BGP route server or route reflector, and is not and never intended to be in a packet forwarding path, is it still a "router"?¶
As a device, it looks like one, and was primarily designed to forward packets. However, when used as a non-packet forwarding BGP route server or route reflector it is only processing packets that are from or to IPv6 addresses that are held by the device, containing upper layer protocols like BGP, OSPF, SNMP and SSH.¶
Functionally, going by [RFC8200] definitions, this router device is purely an IPv6 host. It never "forwards IPv6 packets not explicitly addressed to itself".¶
Commodity personal computers (PCs) can be used as a router. With appropriate operating software and configuration, a PC can "forward[s] IPv6 packets not explicitly addressed to itself". These packets will be forwarded between different physical or logical interfaces residing within the PC.¶
Of course a PC doesn't resemble a traditional router as a device. A PC is acting as a router because of software and configuration.¶
A PC acting as a router can be more discreet than a whole of device role. Some interfaces can be "forwarding interfaces", meaning they accept packets "not explicitly addressed to itself" and attempt to forward them.¶
Other interfaces in the PC may not accept packets "not explicitly addressed to itself", and drop them. The interface will only accept packets for which host processing is to occur.¶
If a packet source or destination address identifies a "router", it is really identifying the host function, or control plane, that resides within the router as a device.¶
Whether or not a device is a router can be more discrete than whether the device as a whole is nominated as a "router" or a "host".¶
In these cases, whether or not to forward a received packet is property or attribute of an IPv6 enabled interface; if the interface accepts a packet that does not have a Destination Address that matches that assigned to the interface, then the device would likely act as a router for that packet, by then submitting the packet to the device's route table, for eventual egress interface selection and then transmission. This receiving interace is known as a "forwarding interface".¶
Another interface on the same device might drop packets that have a Destination Address that doesn't match the interface's address. This type of interface could be described as a "host interface".¶
Although in the context of IPv4, [RFC1812] discusses some of the pitfalls of a host having both forwarding and non-forwarding interfaces in section 2.2.8.1, Embedded Routers.¶
(Most of this section is really applying more to IPv4 NATs and NAPT, rather than stateless IPv6 Network Prefix Translation (NPT). I'll have to work out how to resolve that against using IPv6's host and router defintions as the model being used as the context for this memo. Having to resolve that goes to why IPv6 shouldn't and doesn't have NAPT, and that even though NPT is stateless, it is still performing host processing of packets.)¶
A lot has been written about middleboxes such as Network Address Translators. [MBOX/NAT REFS]¶
In the context of this memo and discussion, how and where do NATs [NPT] map to the [RFC8200] host and router functions?¶
When a packet travels from the network that is "inside" or "behind" the NAT, towards a destination in the network that is "outside", or "beyond", or in "front" of the NAT, the NAT forwards the packet towards "a node that forwards IPv6 packets not explicitly addressed to itself". Taking that [RFC8200] definition literally, a NAT is a router.¶
However, in this direction of "forwarding", a NAT device usually does much more processing on the packet than just "router" forwarding, even though it is not the owner of the packet's destination address. The transport layer and application layer protocol payload of the packet most likely will be inspected to create or update state within the NAT. The packet will be modified, in the least by having its source address updated to the or one of the IP addresses on the outside interface of the NAT. Other modifications will likely occur, such as transport layer protocol ports, changes to IP addresses that are embedded within the applicaton payload if the application protocol is understood by the NAT, and transport layer protocol checksums. Other transport layer specific modifications may be made, such as modification of TCP sequence numbers.¶
In a likely response packet, the destination address of that packet is the original packet's source address, and is now an address assigned to the outside interface of the NAT device. The outside network is forwarding the packet to its apparent final destination, a host identified by the packet's destination IP address.¶
Unlike a true host however, the packet is then modified, generally reversing the equivalent changes that were made on the original packet's that left the NAT. This includes changing the packet's destination address to the IP address that was the original packet's original source address. The packet then enters the inside network to be forwarded to the orignal packet's origin host.¶
So clearly more than routing of the packet is occuring at the NAT. The packet's payload is being processed, which is therefore host processing.¶
The trouble is that while the NAT is performing host processing on the packet, it doesn't have the full context or state that the true original packet's host has, and may not even have the same application protocol implementation version that the original packet's host has. The NAT is trying to act on behalf of the inside network's host, however it doesn't necessarily have all of the information, context and application protocol implementation to do so.¶
So to go back to the original question. A NAT is doing more than forwarding packets. Quite a lot of its processing is host processing. However, it is not a full host because it can't be; it isn't the true final destination of a response packet, nor does it have the information, context and possibly the application protocol implementation to do so.¶
A NAT is more than a router, but less than a true host. It doesn't properly fit within [RFC8200]'s and the general model's definitions of hosts and routers.¶
OLD TEXT BELOW¶
(Most of this section is really applying more to IPv4 NATs and NAPT, rather than stateless IPv6 Network Prefix Translation (NPT). I'll have to work out how to resolve that against using IPv6's host and router defintions as the model for this memo. Having to resolve that goes to why IPv6 shouldn't and doesn't have NAPT, and that even though NPT is stateless, it is still performing host processing of packets.)¶
A lot has been written about middleboxes such as Network Address Translators. [MBOX REFS]¶
In the context of this memo and discussion, how do NATs [NPT] map to the [RFC8200] host and router functions?¶
NATs forward packets "not explicitly addressed to itself" received on their inside interface, so they are performing the [RFC8200] routing function.¶
One of the functions that a NAT performs when forwarding packets from the inside to outside interface is to overwrite the source address of the packet, to an address held by the outside interface. After this overwriting, and to the network attached to the outside interface, the packet appears to have been originated by NAT.¶
OLD TEXT ABOVE¶
Although IPv6 tunnels [RFC2473] appears to be a network function, the tunnel end-points are actually hosts according to the [RFC8200] node, and therefor function, definitions. This is because the tunnel end-points are either packet originators or packet final destinations, and therefore hold and use IPv6 addresses to populate the outer IPv6 tunnel packet source and destination addresses.¶
Remember, only hosts hold IPv6 addresses. It is common to implement tunnels using routers as devices, however it is the host functions within the router as a device that are creating and sending, and then receiving and processing, the outer tunnel IPv6 packets.¶
As tunnel end-points are hosts, then the tunneling function is an application, with the application's purpose being to create a virtual layer 2 link to carry the "tunneled" IPv6 packets between the hosts.¶
Review and comments were provided by YOUR NAME HERE!¶
This memo was prepared using the xml2rfc tool.¶
draft-smith-ietf-routers-vs-hosts-00, initial version, 2022-05-03¶
draft-smith-ietf-routers-vs-hosts-01, 2022-05-04¶
draft-smith-ietf-routers-vs-hosts-02, 2022-0x-xx¶
draft-smith-ietf-routers-vs-hosts-03, 2022-08-23¶
draft-smith-ietf-routers-vs-hosts-04, 2022-08-23¶