Internet DRAFT - draft-smith-ietf-routers-vs-hosts
draft-smith-ietf-routers-vs-hosts
Internet Engineering Task Force M.R. Smith
Internet-Draft 23 August 2022
Intended status: Informational
Expires: 24 February 2023
Routers Verses Hosts; Devices Verses Functions
draft-smith-ietf-routers-vs-hosts-04
Abstract
This memo discusses the differences between routers verses hosts, as
devices verses functions.
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 24 February 2023.
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 24 February 2023 [Page 1]
Internet-Draft Routers Verses Hosts; Devices Verses Fun August 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 . . . . . . . . . . . . . . . . 4
2.1.2. Only Hosts Hold IPv6 Addresses . . . . . . . . . . . 5
2.1.3. Host Function Goal . . . . . . . . . . . . . . . . . 5
2.1.4. Demarcation Point . . . . . . . . . . . . . . . . . . 6
2.1.5. The Physical Postal System . . . . . . . . . . . . . 6
2.1.6. Dumb Network, Smart Hosts . . . . . . . . . . . . . . 8
2.1.7. Hop by Hop "Network" Processing . . . . . . . . . . . 8
2.1.8. An Example - The Routing Header . . . . . . . . . . . 9
2.1.9. A Counter Example - The Hop By Hop Options Header . . 9
2.1.10. Theory Verses Practice - Routers and Hosts As Physical
Devices . . . . . . . . . . . . . . . . . . . . . . . 10
2.1.10.1. Router Devices . . . . . . . . . . . . . . . . . 10
2.1.10.2. Host Devices . . . . . . . . . . . . . . . . . . 11
2.1.10.3. Fast Path verses Slow Path . . . . . . . . . . . 11
2.2. Contrary Examples . . . . . . . . . . . . . . . . . . . . 11
2.2.1. BGP Route Servers and Route Reflectors . . . . . . . 11
2.2.2. Commodity PCs as Routers . . . . . . . . . . . . . . 12
2.3. Routers holding IPv6 Addresses . . . . . . . . . . . . . 12
2.4. Forwarding verses Non-Forwarding Interfaces . . . . . . . 12
3. Network Address Translators (NATs) . . . . . . . . . . . . . 13
4. IPv6 Tunnels . . . . . . . . . . . . . . . . . . . . . . . . 15
5. HBH Function Encoding . . . . . . . . . . . . . . . . . . . . 16
6. Additional HBH Information . . . . . . . . . . . . . . . . . 16
7. Host Requested . . . . . . . . . . . . . . . . . . . . . . . 16
8. Network Imposed . . . . . . . . . . . . . . . . . . . . . . . 16
9. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
10. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . 16
11. Security Considerations . . . . . . . . . . . . . . . . . . . 16
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
13. Change Log [RFC Editor please remove] . . . . . . . . . . . . 16
14. Informative References . . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction
This memo discusses the differences between routers verses hosts, as
devices verses functions.
Smith Expires 24 February 2023 [Page 2]
Internet-Draft Routers Verses Hosts; Devices Verses Fun August 2022
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:
* If a router as a device is purchased from a router vendor, and is
operated as a BGP route reflector or route server that is not and
is never in any packet forwarding paths, is it still a router?
* If a host as a device, such as a PC class server, has multiple
network cards installed, runs virtual machine hosting software,
and has a virtual machine that is running routing software, that
participates in a network's routing protocols, and forwards
packets between the set or a sub-set of the device's network
interfaces, is the device a host, a router, or both? (Or
neither?)
* Is a Network Address Translator (NAT) device a host? A router?
NATs forward packets, a function performed by routers. NATs also
perform indepth packet payload processing such as transport and
application protocol processing, a function performed by hosts.
Yet NATs are not running the applications that are the final
destinations of the packet payloads. A NAT device might fully
perform the functions of a router, however are they also a full
host?
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.
Smith Expires 24 February 2023 [Page 3]
Internet-Draft Routers Verses Hosts; Devices Verses Fun August 2022
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.
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
Smith Expires 24 February 2023 [Page 4]
Internet-Draft Routers Verses Hosts; Devices Verses Fun August 2022
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.
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.
Smith Expires 24 February 2023 [Page 5]
Internet-Draft Routers Verses Hosts; Devices Verses Fun August 2022
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.
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.
Smith Expires 24 February 2023 [Page 6]
Internet-Draft Routers Verses Hosts; Devices Verses Fun August 2022
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.
Smith Expires 24 February 2023 [Page 7]
Internet-Draft Routers Verses Hosts; Devices Verses Fun August 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. 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.
Smith Expires 24 February 2023 [Page 8]
Internet-Draft Routers Verses Hosts; Devices Verses Fun August 2022
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.
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 24 February 2023 [Page 9]
Internet-Draft Routers Verses Hosts; Devices Verses Fun August 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 24 February 2023 [Page 10]
Internet-Draft Routers Verses Hosts; Devices Verses Fun August 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, and is not and never intended to be
in a packet forwarding path, is it still a "router"?
Smith Expires 24 February 2023 [Page 11]
Internet-Draft Routers Verses Hosts; Devices Verses Fun August 2022
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".
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 can be more discrete than whether
the device as a whole is nominated as a "router" or a "host".
Smith Expires 24 February 2023 [Page 12]
Internet-Draft Routers Verses Hosts; Devices Verses Fun August 2022
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.
3. Network Address Translators (NATs)
(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,
Smith Expires 24 February 2023 [Page 13]
Internet-Draft Routers Verses Hosts; Devices Verses Fun August 2022
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
Smith Expires 24 February 2023 [Page 14]
Internet-Draft Routers Verses Hosts; Devices Verses Fun August 2022
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
4. IPv6 Tunnels
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.
Smith Expires 24 February 2023 [Page 15]
Internet-Draft Routers Verses Hosts; Devices Verses Fun August 2022
5. HBH Function Encoding
6. Additional HBH Information
7. Host Requested
8. Network Imposed
9. Method
10. Analysis
11. Security Considerations
12. Acknowledgements
Review and comments were provided by YOUR NAME HERE!
This memo was prepared using the xml2rfc tool.
13. 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
draft-smith-ietf-routers-vs-hosts-02, 2022-0x-xx
* miscellaneous tweaks
* NATs text
* Tunnels text
draft-smith-ietf-routers-vs-hosts-03, 2022-08-23
* prompting questions
draft-smith-ietf-routers-vs-hosts-04, 2022-08-23
* BGP RR fixes
Smith Expires 24 February 2023 [Page 16]
Internet-Draft Routers Verses Hosts; Devices Verses Fun August 2022
* ACL/packet filtering text removed (needs to go somewher else
eventually)
* More text around hop-by-hop network processing
* More postal system text about lead and gold
14. Informative References
[RFC1075] Waitzman, D., Partridge, C., and S E. 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>.
[RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers",
RFC 1812, DOI 10.17487/RFC1812, June 1995,
<https://www.rfc-editor.org/info/rfc1812>.
[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>.
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473,
December 1998, <https://www.rfc-editor.org/info/rfc2473>.
[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 24 February 2023 [Page 17]
