Internet Engineering Task Force M.R. Smith
Internet-Draft 5 May 2022
Intended status: Informational
Expires: 6 November 2022
Routers Verses Hosts; Devices Verses Functions
draft-smith-ietf-routers-vs-hosts-01
Abstract
This memo discusses the differences between routers verses hosts, as
devices verses functions. It then discusses Internet Protocol
architectural considerations and consequences based on these
differences and definitions.
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 6 November 2022.
Copyright Notice
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.
Smith Expires 6 November 2022 [Page 1]
Internet-Draft Routers Verses Hosts; Devices Verses Fun May 2022
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Routers verses Hosts . . . . . . . . . . . . . . . . . . . . 3
2.1. Router verses Host Functions . . . . . . . . . . . . . . 3
2.1.1. Routing Function Goal . . . . . . . . . . . . . . . . 3
2.1.2. Only Hosts Hold IPv6 Addresses . . . . . . . . . . . 4
2.1.3. Host Function Goal . . . . . . . . . . . . . . . . . 4
2.1.4. Demarcation Point . . . . . . . . . . . . . . . . . . 5
2.1.5. The Physical Postal System . . . . . . . . . . . . . 5
2.1.6. Dumb Network, Smart Hosts . . . . . . . . . . . . . . 7
2.1.7. Hop by Hop "Network" Processing . . . . . . . . . . . 7
2.1.8. An Example - The Routing Header . . . . . . . . . . . 8
2.1.9. A Counter Example - The Hop By Hop Options Header . . 8
2.1.10. Theory Verses Practice - Routers and Hosts As Physical
Devices . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.10.1. Router Devices . . . . . . . . . . . . . . . . . 9
2.1.10.2. Host Devices . . . . . . . . . . . . . . . . . . 10
2.1.10.3. Fast Path verses Slow Path . . . . . . . . . . . 10
2.2. Contrary Examples . . . . . . . . . . . . . . . . . . . . 10
2.2.1. BGP Route Servers and Route Reflectors . . . . . . . 10
2.2.2. Commodity PCs as Routers . . . . . . . . . . . . . . 11
2.3. Routers holding IPv6 Addresses . . . . . . . . . . . . . 11
2.4. Forwarding verses Non-Forwarding Interfaces . . . . . . . 11
3. HBH Function Encoding . . . . . . . . . . . . . . . . . . . . 11
4. Additional HBH Information . . . . . . . . . . . . . . . . . 12
5. Host Requested . . . . . . . . . . . . . . . . . . . . . . . 12
6. Network Imposed . . . . . . . . . . . . . . . . . . . . . . . 12
7. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . 12
9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
11. Change Log [RFC Editor please remove] . . . . . . . . . . . . 12
12. Informative References . . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction
This memo discusses the differences between routers verses hosts, as
devices verses functions. It then discusses Internet Protocol
architectural considerations and consequences based on these
differences and definitions.
Smith Expires 6 November 2022 [Page 2]
Internet-Draft Routers Verses Hosts; Devices Verses Fun May 2022
2. Routers verses Hosts
2.1. Router verses Host Functions
[RFC8200] defines an IPv6 node, and two types of IPv6 nodes:
node - "a device that implements IPv6."
router - "a node that forwards IPv6 packets not explicitly
addressed to itself."
host - "any node that is not a router."
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:
The process or processes that perform the routing and forwarding
functions are called "routers" in this memo.
Or, in [RFC1256] (the likely origin of IPv6 Router Advertisements), a
router is defined as:
a system that forwards IP datagrams
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.
2.1.1. Routing Function Goal
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.
Smith Expires 6 November 2022 [Page 3]
Internet-Draft Routers Verses Hosts; Devices Verses Fun May 2022
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.
2.1.2. Only Hosts Hold IPv6 Addresses
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.
2.1.3. Host Function Goal
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.
Smith Expires 6 November 2022 [Page 4]
Internet-Draft Routers Verses Hosts; Devices Verses Fun May 2022
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.
2.1.4. Demarcation Point
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.
2.1.5. The Physical Postal System
The communications model the Internet Protocols follows is very close
to that of the physical postal mail and package distribution systems.
Smith Expires 6 November 2022 [Page 5]
Internet-Draft Routers Verses Hosts; Devices Verses Fun May 2022
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. Lead or
gold costs the same to transport.
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 to ensure that envelopes and
packages are opened "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.
Smith Expires 6 November 2022 [Page 6]
Internet-Draft Routers Verses Hosts; Devices Verses Fun May 2022
2.1.6. Dumb Network, Smart Hosts
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.
2.1.7. Hop by Hop "Network" Processing
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. Processing may need to occur at certain
points on the path beyond the fixed IPv6 header used for forwarding.
Smith Expires 6 November 2022 [Page 7]
Internet-Draft Routers Verses Hosts; Devices Verses Fun May 2022
By the [RFC8200] definitions, and the previous discussion, more than
simple and fast forwarding processing of packets is host processing.
(In fact, packet filtering/ACLs while forwarding, beyond the fixed
IPv6 header, is also host processing, because it involves more than
simple and fast forwarding based on the fixed IPv6 header.)
So when a packet travels across a network, and at certain way points,
is host processed, rather than just simply fast forwarded, those 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
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.
2.1.8. An Example - The Routing Header
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.
2.1.9. A Counter Example - The Hop By Hop Options Header
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.
Smith Expires 6 November 2022 [Page 8]
Internet-Draft Routers Verses Hosts; Devices Verses Fun May 2022
[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.
2.1.10. Theory Verses Practice - Routers and Hosts As Physical Devices
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.
2.1.10.1. Router Devices
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)
Smith Expires 6 November 2022 [Page 9]
Internet-Draft Routers Verses Hosts; Devices Verses Fun May 2022
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?)
2.1.10.2. Host Devices
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.
2.1.10.3. Fast Path verses Slow Path
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.
2.2. Contrary Examples
2.2.1. BGP Route Servers and Route Reflectors
When a router as a device, from a router vendor, is used as a BGP
route server or route reflector, is it still a "router"?
As a device, it looks like one, and was primarily designed to forward
packets. However, when used as a 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.
Smith Expires 6 November 2022 [Page 10]
Internet-Draft Routers Verses Hosts; Devices Verses Fun May 2022
Functionally, going by [RFC8200] definitions, this router device is
purely an IPv6 host. It never "forwards IPv6 packets not explicitly
addressed to itself".
2.2.2. Commodity PCs as Routers
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.
2.3. Routers holding IPv6 Addresses
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.
2.4. Forwarding verses Non-Forwarding Interfaces
Whether or not a device is a router is more discrete than whether the
device as a whole is nominated as a "router" or a "host".
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 will act as a router for that packet, by
then submitting the packet to the device's route table. The 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".
3. HBH Function Encoding
Smith Expires 6 November 2022 [Page 11]
Internet-Draft Routers Verses Hosts; Devices Verses Fun May 2022
4. Additional HBH Information
5. Host Requested
6. Network Imposed
7. Method
8. Analysis
9. Security Considerations
10. Acknowledgements
Review and comments were provided by YOUR NAME HERE!
This memo was prepared using the xml2rfc tool.
11. Change Log [RFC Editor please remove]
draft-smith-ietf-routers-vs-hosts-00, initial version, 2022-05-03
draft-smith-ietf-routers-vs-hosts-01, 2022-05-04
* miscellaneous tweaks
* postal system clarifications
* mostly merge IPv6 addresses are host addresses sections
12. Informative References
[RFC1075] Waitzman, D., Partridge, C., and S. Deering, "Distance
Vector Multicast Routing Protocol", RFC 1075,
DOI 10.17487/RFC1075, November 1988,
<https://www.rfc-editor.org/info/rfc1075>.
[RFC1256] Deering, S., Ed., "ICMP Router Discovery Messages",
RFC 1256, DOI 10.17487/RFC1256, September 1991,
<https://www.rfc-editor.org/info/rfc1256>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <https://www.rfc-editor.org/info/rfc2460>.
Smith Expires 6 November 2022 [Page 12]
Internet-Draft Routers Verses Hosts; Devices Verses Fun May 2022
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
Author's Address
Mark Smith
PO BOX 521
HEIDELBERG VIC 3084
Australia
Email: markzzzsmith@gmail.com
Smith Expires 6 November 2022 [Page 13]