Subject: [v6ops] Routers are hosts too! (Re: I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt)

From: Mark Smith <[email-masked]>
Date: Thu, 7 Jan 2016 08:24:12 +1100

I think people might be getting a bit caught in the trap of thinking the
separation between hosts and routers is a much stronger than it is.

Routers are universally hosts too. The distinction between a router and a
host is that a router will also accept packets not sent to addresses
assigned to the devices interfaces. It will then see what to do with them
according to the route table, sending the packet where ever the  route
table says or dropping them. That is all that makes it a router.

Routers are hosts too if there is anything at all above the IP layer that
locally receives or locally originates packets using the router's IP
addresses. So SNMP agents, ssh/telnet daemons and even BGP, OSPF and DHCPv6
processes are host processes.

People say there isn't much or any experience with hosts using addresses
assigned via DHCPv6-PD. I don't agree, because every residential IPv6 CPE
supporting DHCPv6 that is acquiring addresses via DHCPv6-PD, DNS settings,
getting time via NTP or providing a web administrative interface is a host
too.

Take one of these CPE, disable the LAN interface, attach a screen, keyboard
and mouse, and run a spreadsheet or web browser on it and you have the type
of host being discussed.

The only way for a router not to be a host would be if it specially didn't
listen for packets addressed to its own addresses, so that all it ever did
was forward non-local packets. You have no monitoring of it, no routing
protocols, and would have to configure it via a serial cable.

Mark.

---

From: Joe Touch <[email-masked]>
Date: Wed, 6 Jan 2016 13:46:27 -0800

+1 (and then some)

AFAICT:

	- a host is an Internet device that sources or sinks packets

	- a router is an Internet device that *also* relays packets

It may be possible to implement a router that never acts as a host, but
that requires it never participate actively in routing protocols, IP
signalling, etc.

Joe

On 1/6/2016 1:24 PM, Mark Smith wrote:
> Routers are universally hosts too. The distinction between a router and
> a host is that a router will also accept packets not sent to addresses
> assigned to the devices interfaces. It will then see what to do with
> them according to the route table, sending the packet where ever the 
> route table says or dropping them. That is all that makes it a router.

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Thu, 7 Jan 2016 11:57:56 +0000

Mark, +1 indeed on the statement that routers are hosts (i.e. They reply to ICMP & SNMP and even generate ICMP with their own global addresses -- else RFC 7014 --LLA-only -- should have been obvious)

Now, I respectfully disagree on the fact we have experience with host doing DHCP-PD: for sure about Linux (and even it is user space) but what about Windows? Or iOS (lowercase :-) )? Or ???

-éric

From: v6ops <[email-masked]<mailto:[email-masked]>> on behalf of Mark Smith <[email-masked]<mailto:[email-masked]>>
Date: mercredi 6 janvier 2016 22:24
To: Fred L Templin <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]> WG" <[email-masked]<mailto:[email-masked]>>
Subject: [v6ops] Routers are hosts too! (Re: I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt)

I think people might be getting a bit caught in the trap of thinking the separation between hosts and routers is a much stronger than it is.

Routers are universally hosts too. The distinction between a router and a host is that a router will also accept packets not sent to addresses assigned to the devices interfaces. It will then see what to do with them according to the route table, sending the packet where ever the  route table says or dropping them. That is all that makes it a router.

Routers are hosts too if there is anything at all above the IP layer that locally receives or locally originates packets using the router's IP addresses. So SNMP agents, ssh/telnet daemons and even BGP, OSPF and DHCPv6 processes are host processes.

People say there isn't much or any experience with hosts using addresses assigned via DHCPv6-PD. I don't agree, because every residential IPv6 CPE supporting DHCPv6 that is acquiring addresses via DHCPv6-PD, DNS settings, getting time via NTP or providing a web administrative interface is a host too.

Take one of these CPE, disable the LAN interface, attach a screen, keyboard and mouse, and run a spreadsheet or web browser on it and you have the type of host being discussed.

The only way for a router not to be a host would be if it specially didn't listen for packets addressed to its own addresses, so that all it ever did was forward non-local packets. You have no monitoring of it, no routing protocols, and would have to configure it via a serial cable.

Mark.

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 7 Jan 2016 13:39:47 +0100

> that requires it never participate actively in routing protocols, IP

Yes.  And:

         - a router doesn't use the information received in an RA, a
           host does.

         - a router doesn't join the all-hosts multicast address.

         - a router doesn't use SLAAC to configure an address for self,
           a Host does.

         - a router does implement longest-matching algorithms, a Host
           doesn't.

Implementations are obviously less clear cut.  But we can talk theory.

Alex

> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Gert Doering <[email-masked]>
Date: Thu, 7 Jan 2016 13:42:37 +0100

Hi,

>          - a router does implement longest-matching algorithms, a Host

Of course hosts do.  Why would any implementor not do that?

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

---

From: Jared Mauch <[email-masked]>
Date: Thu, 7 Jan 2016 07:44:54 -0500

> On Jan 7, 2016, at 7:42 AM, Gert Doering <[email-masked]> wrote:
> 
> Hi,
> 

Agreed.  I’ve seen junior sysadmin types get caught up with this at times if a host is multi homed.

- Jared

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 7 Jan 2016 13:47:02 +0100

> route table says or dropping them. That is all that makes it a router.

I agree with you about the trap.  It may be a trap of the theory, which 
is good to keep aside as principles, although practice is more nuanced.

YEs, mainly a router forwards packets not addressed to self, whereas a 
Host doesn't .

Also, a router with a single real interface and at least one virtual 
interface forwards packets too; and too, according to the same 
forwarding mechanisms (route table, longest-prefix match, etc.).

The only Host which is not a Router is a Host that has one single real 
interface and no virtual interfaces.  I think the loopback interface is 
mandatory (or at least its loopback address is mandatory) and hence 
maybe true Hosts dont really exist.

> Routers are hosts too if there is anything at all above the IP layer
> that locally receives or locally originates packets using the router's
> IP addresses. So SNMP agents, ssh/telnet daemons and even BGP, OSPF and
> DHCPv6 processes are host processes.

Right.

> assigned via DHCPv6-PD. I don't agree, because every residential IPv6
> CPE supporting DHCPv6 that is acquiring addresses via DHCPv6-PD, DNS
> settings, getting time via NTP or providing a web administrative
> interface is a host too.
>
> Take one of these CPE, disable the LAN interface, attach a screen,
> keyboard and mouse, and run a spreadsheet or web browser on it and you
> have the type of host being discussed.

No -  that is a desktop PC, inheriting from the VT100 terminal.  It's 
not a Host.  A Host is more like the 1970's mainframe which needs an IMP 
(Interface Message Processor) to connect to the Internet.

> The only way for a router not to be a host would be if it specially
> didn't listen for packets addressed to its own addresses, so that all it
> ever did was forward non-local packets. You have no monitoring of it, no
> routing protocols, and would have to configure it via a serial cable.

YEs, and there are many such forwarding-only routers especially in the 
'IoT' and 'M2M' worlds.  They are very small and simple.

Alex

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 7 Jan 2016 21:46:54 +0900

On Thu, Jan 7, 2016 at 8:57 PM, Eric Vyncke (evyncke) <[email-masked]>
wrote:

> Now, I respectfully disagree on the fact we have experience with host
> doing DHCP-PD: for sure about Linux (and even it is user space) but what
> about Windows? Or iOS (lowercase :-) )? Or ???
>

Windows has supported DHCPv6 since 2007:
https://blogs.technet.microsoft.com/teamdhcp/2007/01/23/dhcpv6-behaviour-in-windows-vista/

As for iOS - two of the authors work for Apple, and both of them write
code, so if they are saying that DHCPv6 PD is an option, I'd assume that
it's possible to implement it on iOS :-)

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Thu, 7 Jan 2016 12:57:51 +0000

I like it when my pessimistic view is correct :-)

OTOH, the Windows blog states "DHCPv6 Stateful mode is where a client uses DHCPv6 to obtain an IPv6 address from the DHCPv6 server along with other configuraiton parameters." so no hint about DHCP-PD... This was my concern about DHCP-PD on host: an issue of implementation only (fixable) and not in protocol or religious host vs router was (unfixable) ;-)

-éric

From: Lorenzo Colitti <[email-masked]<mailto:[email-masked]>>
Date: jeudi 7 janvier 2016 13:46
To: Eric Vyncke <[email-masked]<mailto:[email-masked]>>
Cc: Mark Smith <[email-masked]<mailto:[email-masked]>>, Fred L Templin <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]> WG" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [v6ops] Routers are hosts too! (Re: I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt)

On Thu, Jan 7, 2016 at 8:57 PM, Eric Vyncke (evyncke) <[email-masked]<mailto:[email-masked]>> wrote:
Now, I respectfully disagree on the fact we have experience with host doing DHCP-PD: for sure about Linux (and even it is user space) but what about Windows? Or iOS (lowercase :-) )? Or ???

Windows has supported DHCPv6 since 2007: https://blogs.technet.microsoft.com/teamdhcp/2007/01/23/dhcpv6-behaviour-in-windows-vista/

As for iOS - two of the authors work for Apple, and both of them write code, so if they are saying that DHCPv6 PD is an option, I'd assume that it's possible to implement it on iOS :-)

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 7 Jan 2016 22:03:47 +0900

Wrong link, sorry. Here's the right one.
https://blogs.technet.microsoft.com/rrasblog/2007/01/23/broadband-connections-and-dhcpv6-prefix-delegation-in-windows-vista/

On Thu, Jan 7, 2016 at 9:57 PM, Eric Vyncke (evyncke) <[email-masked]>
wrote:

> OTOH, the Windows blog states "DHCPv6 Stateful mode is where a client
> uses DHCPv6 to obtain an IPv6 address from the DHCPv6 server along with
> other configuraiton parameters." so no hint about DHCP-PD... This was my
> concern about DHCP-PD on host: an issue of implementation only (fixable)
> and not in protocol or religious host vs router was (unfixable) ;-)
>
> -éric
>
>
> From: Lorenzo Colitti <[email-masked]>
> To: Eric Vyncke <[email-masked]>
> Cc: Mark Smith <[email-masked]>, Fred L Templin <
> [email-masked]>, "[email-masked] WG" <[email-masked]>
> Subject: Re: [v6ops] Routers are hosts too! (Re: I-D Action:
> draft-ietf-v6ops-host-addr-availability-04.txt)
>

---

From: Gert Doering <[email-masked]>
Date: Thu, 7 Jan 2016 14:04:31 +0100

Hi,

> https://blogs.technet.microsoft.com/teamdhcp/2007/01/23/dhcpv6-behaviour-in-windows-vista/

This is not exactly mentioning DHCPv6-PD... only stateless/stateful mode.

Gert Doering
        -- NetMaster

---

From: Gert Doering <[email-masked]>
Date: Thu, 7 Jan 2016 14:07:51 +0100

Hi,

> https://blogs.technet.microsoft.com/rrasblog/2007/01/23/broadband-connections-and-dhcpv6-prefix-delegation-in-windows-vista/

"Only when Internet Connection Sharing is enabled on Windows Vista,
 where the host needs to act as a router for other clients on a home
 network does Windows Vista trigger the requesting router behaviour
 of prefix delegation."

So, yes, the code is there - but typically not active on your travelling
salesman's laptop (and if it were, it would as likely mess up everyone
else's network as ICSs would happily announce Teredo, 6to4 and ISATAP
prefixes everywhere...)

Gert Doering
        -- NetMaster

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 7 Jan 2016 22:13:43 +0900

> else's network as ICSs would happily announce Teredo, 6to4 and ISATAP

People do have it turned on. We know because it was a major cause of IPv6
brokenness in 2011.

https://en.wikipedia.org/wiki/IPv6_brokenness_and_DNS_whitelisting

IIRC the fix was not to disable ICS, but to stop ICS from sending 6to4 RAs.

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 7 Jan 2016 14:17:06 +0100

> Of course hosts do.  Why would any implementor not do that?

Why would a Host need to look out a nexthop in routing table?  To 
forward to whom?

Alex

---

From: Gert Doering <[email-masked]>
Date: Thu, 7 Jan 2016 14:21:17 +0100

Hi,

> Why would a Host need to look out a nexthop in routing table?  To 

Well, it needs to send its own packets somewhere, no?  And guess 
what, this is done using the normal routing table which (if you set 
ip.forwarding=1) magically turns into a forwarding table.

Hosts can have more than one interface, like "a LAN interface and a
VPN tunnel interface".  It really helps if they know which packet goes
where.

Gert Doering
        -- NetMaster

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 7 Jan 2016 14:26:26 +0100

Le 07/01/2016 14:21, Gert Doering a écrit :
> Well, it needs to send its own packets somewhere, no?

YEs, to its router.  There's only one - the default.  There are no 
neighbors to distinguish from.

> And guess what, this is done using the normal routing table

Yes, the 'normal' routing table because that's what we're used with 
since linux and Ethernet.

But a Host using serial to connect to a router (e.g. a UE) does not need 
a routing table.

> which (if
> you set ip.forwarding=1) magically turns into a forwarding table.
>
> VPN tunnel interface".  It really helps if they know which packet
> goes where.

YEs, but these are not pure Hosts.  They are more like desktop PCs and 
smartphones.

Alex

>
> Gert Doering -- NetMaster
>

---

From: Gert Doering <[email-masked]>
Date: Thu, 7 Jan 2016 14:36:55 +0100

Hi,

> neighbors to distinguish from.

My hosts have ethernet neighbours, and there can be any number of routers
on these ethernets.  The "default gateway" is just the fallback if nothing
more specific exists.

[..]
> But a Host using serial to connect to a router (e.g. a UE) does not need 

Of course it does.  The moment it also has a wifi connection, and two
interfaces are active, the locally connected networks alone require a
routing decisions (because you wouldn't send a packet for a host on
wifi to the 3G uplink).  Very basic routing table, but still.

> YEs, but these are not pure Hosts.  They are more like desktop PCs and 

Now that begs the question what you consider to be a "Host"?  A desktop
PC, a smartphone - that's what the IETF considers a "host", and those are
the largest mass...

Gert Doering
        -- NetMaster

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 7 Jan 2016 14:45:32 +0100

Le 07/01/2016 14:36, Gert Doering a écrit :
> on these ethernets.

They are not Hosts, they are desktop PCs.  Hosts are defined in an RFC.

>  The "default gateway" is just the fallback if nothing
> more specific exists.

YEs.

> wifi to the 3G uplink).  Very basic routing table, but still.

Yes, but these are smartphones or desktop PCs, not Hosts.

Other than that RFC defining a Host, a host is someone or something that 
receives.  And a router is something that makes roads (routes).

> PC, a smartphone - that's what the IETF considers a "host", and those are

The Host defined by IETF is in an RFC.

Alex

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 7 Jan 2016 15:50:53 +0000

I have been doing DHCPv6-PD to a host using AERO on both linux and Android for
quite some time now.

Thanks - Fred

From: Eric Vyncke (evyncke) [mailto:[email-masked]]
Sent: Thursday, January 07, 2016 3:58 AM
To: Mark Smith; Templin, Fred L
Cc: [email-masked] WG
Subject: Re: [v6ops] Routers are hosts too! (Re: I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt)

-éric

Mark.

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 7 Jan 2016 15:57:56 +0000

Hi,

> -----Original Message-----
> From: v6ops [mailto:[email-masked]] On Behalf Of Gert Doering
> Sent: Thursday, January 07, 2016 5:08 AM
> To: Lorenzo Colitti
> Cc: [email-masked] WG

I am not arguing for ISATAP, but there is no such thing as an
"ISATAP prefix". ISATAP can use any global IPv6 prefix, since
it operates only within the site.  Outside of the site, there is
no way to tell for sure whether ISATAP is being used inside
the site by examining only the prefix.

Thanks - Fred
[email-masked]

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Thu, 7 Jan 2016 16:29:08 +0000

Heu.. The discussion is whether routers are also hosts and NOT on whether
hosts are routers...

And in the same vein, routers DO listen to RA and do DHCP as client (for
example when they are a residential CPE)

-éric

---

From: Tim Chown <[email-masked]>
Date: Thu, 7 Jan 2016 16:40:20 +0000

> On 7 Jan 2016, at 13:13, Lorenzo Colitti <[email-masked]> wrote:
> 
> On Thu, Jan 7, 2016 at 10:07 PM, Gert Doering <[email-masked] <mailto:[email-masked]>> wrote:
> People do have it turned on. We know because it was a major cause of IPv6 brokenness in 2011.
> 
> https://en.wikipedia.org/wiki/IPv6_brokenness_and_DNS_whitelisting <https://en.wikipedia.org/wiki/IPv6_brokenness_and_DNS_whitelisting>
> 

Happy days. We monitored that over a year and >50% of the time some Windows host was doing 6to4 like that.  Hence the ramond code in advance of solutions from vendors.

Tim

---

From: Tim Chown <[email-masked]>
Date: Thu, 7 Jan 2016 16:42:50 +0000

> On 7 Jan 2016, at 16:29, Eric Vyncke (evyncke) <[email-masked]> wrote:
> 

So where does the ICS model sit with this?

Would the “host” providing the ICS function then serve (or relay) DHCP-PD requests from “hosts” behind it?

Tim

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 7 Jan 2016 18:01:06 +0100

Le 07/01/2016 17:29, Eric Vyncke (evyncke) a écrit :
> Heu.. The discussion is whether routers are also hosts and NOT on
> whether hosts are routers...
>
> And in the same vein, routers DO listen to RA

By spec, they listen to RA just to be informed about other routers,
maybe learn if some other router dies out and log the info.  But nothing
more.

For example, they can't SLAAC an address using the prefix received in an
RA, they can't set the MTU of the link, they can't decide they have have
experienced a handover by computing the difference between the received
prefixes, and so on.

> and do DHCP as client (for example when they are a residential CPE)

I agree with the behaviour.  But.

Contrary to ND specs the DHCP specs dont talk Host vs Routers.  They 
talk Client vs Server vs Relay.  And there is no defined relationship 
between Router and Servers, for example.  One can't say a Server is a 
Router.

As such one couldnt say that a DHCP Client is necessarily a Host.

Alex

>>>>>> - a router does implement longest-matching algorithms, a
>>>>>> Host doesn't.
>>>>>
>>>> Why would a Host need to look out a nexthop in routing table?
>>>> To forward to whom?
>>>
>> Yes, the 'normal' routing table because that's what we're used
>> with since linux and Ethernet.
>>
>> But a Host using serial to connect to a router (e.g. a UE) does not
>> need a routing table.
>>
>>> which (if you set ip.forwarding=1) magically turns into a
>>> forwarding table.
>>>
>>> Hosts can have more than one interface, like "a LAN interface and
>>> a VPN tunnel interface".  It really helps if they know which
>>> packet goes where.
>>
>> YEs, but these are not pure Hosts.  They are more like desktop PCs
>> and smartphones.
>>
>> Alex
>>
>>>
>> _______________________________________________ v6ops mailing list
>> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 8 Jan 2016 02:03:39 +0900

> maybe learn if some other router dies out and log the info.  But nothing

Yes, well. Since RFC 2460 was written, they have evolved to do quite a bit
more. For example, see the CPE router document (RFC 7084). Those send RSes,
listen to RA, use SLAAC, etc.

---

From: Joe Touch <[email-masked]>
Date: Thu, 7 Jan 2016 10:20:51 -0800

>         - a router doesn't use the information received in an RA, a

A router might have an interface by which it is accessible as a host but
for which it does not forward; that interface could use an RA for
autoconfiguration.

>         - a router doesn't join the all-hosts multicast address.

There's an "all nodes", which it clearly should join (see RFC4921, Sec.
2.8).

There is no "all-hosts" listed here (except for ST, which is obsoleted):
http://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml

>         - a router doesn't use SLAAC to configure an address for self,

It could where appropriate (e.g., see first item above).

>         - a router does implement longest-matching algorithms, a Host

This is needed for source address selection if the host has more than
one address.

---

From: Joe Touch <[email-masked]>
Date: Thu, 7 Jan 2016 10:22:28 -0800

> Why would a Host need to look out a nexthop in routing table?  To

Source address selection. See RFC1122 Sec 3.3.4.3.

Joe

---

From: "Niall O'Reilly" <[email-masked]>
Date: Thu, 07 Jan 2016 18:38:51 +0000

On Thu, 07 Jan 2016 12:39:47 +0000,
>         - a router doesn't join the all-hosts multicast address.

  Eh?

162(niall)4: for x in 1 2; do ping6 -c3 -I en1 ff02::$x; done
PING6(56=40+8+8 bytes) fe80::7a31:c1ff:feec:a2c6%en1 --> ff02::1
16 bytes from fe80::7a31:c1ff:feec:a2c6%en1, icmp_seq=0 hlim=64 time=0.141 ms
16 bytes from fe80::d6ca:6dff:fe26:e0dd%en1, icmp_seq=0 hlim=255 time=3.437 ms
16 bytes from fe80::7a31:c1ff:feec:a2c6%en1, icmp_seq=1 hlim=64 time=0.220 ms
16 bytes from fe80::d6ca:6dff:fe26:e0dd%en1, icmp_seq=1 hlim=255 time=3.411 ms
16 bytes from fe80::7a31:c1ff:feec:a2c6%en1, icmp_seq=2 hlim=64 time=0.233 ms

--- ff02::1 ping6 statistics ---
3 packets transmitted, 3 packets received, +2 duplicates, 0.0% packet loss
round-trip min/avg/max/std-dev = 0.141/1.488/3.437/1.581 ms
PING6(56=40+8+8 bytes) fe80::7a31:c1ff:feec:a2c6%en1 --> ff02::2
16 bytes from fe80::d6ca:6dff:fe26:e0dd%en1, icmp_seq=0 hlim=255 time=5.611 ms
16 bytes from fe80::d6ca:6dff:fe26:e0dd%en1, icmp_seq=1 hlim=255 time=2.255 ms
16 bytes from fe80::d6ca:6dff:fe26:e0dd%en1, icmp_seq=2 hlim=255 time=3.372 ms

--- ff02::2 ping6 statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 2.255/3.746/5.611/1.395 ms
162(niall)4:

---

From: joel jaeggli <[email-masked]>
Date: Thu, 7 Jan 2016 10:45:49 -0800

> There's an "all nodes", which it clearly should join (see RFC4921, Sec.

the platonic conception of a router as a device that simply forwards
packets maybe not, the router's control plane on the other hand is a
host on every subnet where it's addressed and is therefore a node.

---

From: Gert Doering <[email-masked]>
Date: Thu, 7 Jan 2016 19:55:07 +0100

Hi,

> 16 bytes from fe80::d6ca:6dff:fe26:e0dd%en1, icmp_seq=0 hlim=255 time=3.437 ms

This obviously is not an IETF Router, as we've learned today that
real existing devices, like "a PC" or "a smartphone" are not IETF Hosts.

Gert Doering
        -- NetMaster

---

From: Michael H Lambert <[email-masked]>
Date: Thu, 7 Jan 2016 14:07:04 -0500

> On 7 Jan 2016, at 13:22, Joe Touch <[email-masked]> wrote:
> 

Yep.  Back in the day we had "big iron" listening to RIP on multiple interfaces to select the best (ie, fastest active) interface.

Michael

---

From: Joe Touch <[email-masked]>
Date: Thu, 7 Jan 2016 11:11:17 -0800

> On 1/7/16 10:20 AM, Joe Touch wrote:
...
> host on every subnet where it's addressed and is therefore a node.

RFC4921 Sec 2.8 is very clear to the contrary:

   A host is required to recognize the following addresses as
   identifying itself:

      o Its required Link-Local address for each interface.

      o Any additional Unicast and Anycast addresses that have been
        configured for the node's interfaces (manually or
        automatically).

      o The loopback address.

      o The All-Nodes multicast addresses defined in Section 2.7.1.

      o The Solicited-Node multicast address for each of its unicast and
        anycast addresses.

      o Multicast addresses of all other groups to which the node
        belongs.

   A router is required to recognize all addresses that a host is
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   required to recognize, plus the following addresses as identifying
   ^^^^^^^^^^^^^^^^^^^^^
   itself:

I.e., there may be devices that forward packets that have no addressable
control plane but they still need to recognize exactly the same
addresses as a host.

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 7 Jan 2016 11:17:53 -0800

> Yep.  Back in the day we had "big iron" listening to RIP on multiple interfaces to select the best (ie, fastest active) interface.

FWIW, that works great if both interfaces are always up. If one ever
fails, you might cut off connections based on the failed interface
address even though you could have routed them through the other interface.

Our solution to this was to admit that a multihomed host was really
better modeled as a virtual internal router with separate internal
hosts, one for each IP address:

J. Touch, T. Faber, “Dynamic Host Routing for Production Use of
Developmental Networks,” in Proc. ICNP ’97, Atlanta, Oct. 1997, pp. 285-292.

Joe

---

From: Mark Smith <[email-masked]>
Date: Fri, 8 Jan 2016 06:58:11 +1100

> experienced a handover by computing the difference between the received

RFC7084, "Basic Requirements for IPv6 Customer Edge Routers" use RAs
for most or all of those things.

The Linux kernel was modified to support processing RAs when
forwarding was switched on to suit this purpose, which is how the
Linux kernel is used in OpenWRT to implement a router.

> Contrary to ND specs the DHCP specs dont talk Host vs Routers.  They talk
> Client vs Server vs Relay.  And there is no defined relationship between
> Router and Servers, for example.  One can't say a Server is a Router.
>

Agree, as I said, the distinction between a host and a router is a
layer 3 function, and limited to whether or not the device will accept
and process non-locally destined packets.

This Fedora Linux desktop PC is currently a host, as that is it's
default setting.

[root@opy mark]# echo 1 > /proc/sys/net/ipv4/ip_forward
[root@opy mark]#

Now it is an IPv4 and IPv6 router (the global forwarding switch being
under the IPv4 system settings is a historical artifact)

Perhaps less well known is that some implementations can have a mix of
routing and non-routing interfaces:

[root@opy mark]# echo 1 > /proc/sys/net/ipv4/ip_forward
                                # all interfaces are forwarding
interfaces
[root@opy mark]# echo 0 > /proc/sys/net/ipv4/conf/enp3s2/forwarding
                         # now enp3s2 won't accept non-local packet
destinations
[root@opy mark]#

This isn't Linux specific, if I recall correctly, I first read about
this behaviour and the functional distinction between hosts and
routers in Richard Steven's TCP/IP Illustrated Volume 1 many years
ago.

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 8 Jan 2016 11:26:26 +0100

> for which it does not forward; that interface could use an RA for

Yes.

> There's an "all nodes", which it clearly should join (see RFC4921, Sec.

Right, I should have said
'- a host does not join the all-routers address".

> http://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml

So I discover ST stands for Internet Stream Protocol RFC1819.

I think Ethernet maybe has a 48bit MAC address 33:33::3 address for 
"all-hosts", but I dont have the IEEE spec at hand to check.

> This is needed for source address selection if the host has more than

But we dont know how source address selection works with this respect. 
I think there are some RFCs for source address selection but it doesnt 
say to use longest-matching algorithms IIRC.  It could very well be 
exact match.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 8 Jan 2016 11:28:07 +0100

> Source address selection. See RFC1122 Sec 3.3.4.3.

I grepped "match" and it doesnt say whether exact match or longest-match 
are used.

As such I think it's exact match.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 8 Jan 2016 11:35:42 +0100

> round-trip min/avg/max/std-dev = 2.255/3.746/5.611/1.395 ms

Thanks right.

I agree with you.  The screenshot above means that the router joins the 
"all-nodes" and "all-routers" groups.

But the ambiguity introduced by the term 'node'[*] is maintained: the 
node that replies to requests is both a router and 'not a router'.  It's 
hard to wrap one's mind around that.

Alex
[*] rfc2464: a host is any node that is not a router.

---

From: [email-masked]
Date: Fri, 08 Jan 2016 12:10:15 +0100 (CET)

> As such I think it's exact match.

Irrespective of the source address selection issue, normal "host"
operating systems that I know of (e.g. FreeBSD) most definitely
implement longest match.

Think of it this way: If a host *can* be turned into a router by
changing a configuration knob, why on earth would you want to
implement exact match to be used only for host mode (when longest
match is needed in any case for router mode)?

Steinar Haug, AS2116

---

From: Jared Mauch <[email-masked]>
Date: Fri, 8 Jan 2016 08:48:10 -0500

I've not encountered a device in the past 20+ years that doesn't do longest match. 

Jared Mauch

---

From: Jeff McAdams <[email-masked]>
Date: Fri, 08 Jan 2016 09:08:22 -0500

That was going to be my point as well.

And if I did, I'd immediately send it back to the vendor telling them it was broken and its IP stack was unusable.

-- 
Jeff

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 8 Jan 2016 15:22:35 +0100

>> operating systems that I know of (e.g. FreeBSD) most definitely

YEs, I agree.  Wherever BSD and linux derivatives are running 
longest-match is there builtin.

But I think there may be a difference between OS understanding of a 
'host' and a Host defined in an RFC.

Where linux distros may distinguish between "desktop" and "server", an 
RFC may distinguish between a Host (RFC1122 and RFC1123) and a Router 
(RFC 1812).  Only the latter requires the use of "longest match".

As such, a memory-savvy and reduced clock computer Host may benefit from 
not implementing longest-match and still connect to the Internet.

>> match is needed in any case for router mode)?

Well, I agree.  With a simple knob you get it.

Exact match is useful for the search in the ND cache, or for the search 
in Ethernet-related databases.  But I did not mean to compare it to 
longest-match.

I wanted to say that a Host - as defined in RFC - does not implement 
longest-match.

A host as people call a laptop, a smartphone or a tablet does implement 
it though.

Alex

---

From: "Jeff McAdams" <[email-masked]>
Date: Fri, 8 Jan 2016 09:35:34 -0500 (EST)

...

> A host as people call a laptop, a smartphone or a tablet does implement

So, basically, you're saying that, to at least a vanishingly small
rounding error, there are no "RFC Hosts" on the Internet today.

So what's your point?

-- 
Jeff

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 8 Jan 2016 16:24:47 +0100

> rounding error, there are no "RFC Hosts" on the Internet today.

Maybe we should find that small rounding error - what OS does not 
implement longest-match and yet connects to the Internet?

Second, until we ifnd that small rounding error, we may stop talking 
about Hosts, and declare the Host RFC historic.  Or update it with a 
sentence saying that Hosts too must implement longest-match.

Alex

---

From: "Jeff McAdams" <[email-masked]>
Date: Fri, 8 Jan 2016 10:42:52 -0500 (EST)

>>> As such, a memory-savvy and reduced clock computer Host may benefit
>>> from not implementing longest-match and still connect to the Internet.
>>>
>>
>> ...
>>
>>
>>> A host as people call a laptop, a smartphone or a tablet does
>>> implement it though.
>>

> implement longest-match and yet connects to the Internet?

OK, I (and I suspect most others on this thread) am not convinced they
exist at all.  Maybe let us know if/when you find some?

> sentence saying that Hosts too must implement longest-match.

I'm still a bit confused about where this was specified.  Can you give
me/us a more specific cite than "an RFC" (or have I, perhaps, missed this
in the discussion that has happened...I will admit to not having read
every message in the thread)?  I, for one, would be willing to support
this, if there is, indeed, a place where this is specified.

-- 
Jeff

---

From: Warren Kumari <[email-masked]>
Date: Fri, 08 Jan 2016 15:50:44 +0000

> I've not encountered a device in the past 20+ years that doesn't do
Actually, I suspect that you have, as have I, as have all of us -- there
are many small embedded widgets which have *tiny* IP stacks which are
incredibly simple, and don't really seem to understand the concept of more
than one route - in fact, often it is even simpler than that - they don't
really understand a "subnet", all packets get sent to the router.

The uIP stack is (unless I'm very mistaken and routing was added later) an
example of a stack that doesn't seem to implement longest-match, largely
because it doesn't really seem to understand "routes" - if a destination is
within the local subnet it will ARP and send the packet there, otherwise
everything goes to "the default router":
If the destination IP address is not on the local network, the IP address
of the default router is used instead."v -
http://www.cs.tut.fi/kurssit/OHJ-4301/harjoitustyo/btweb/uip-0_9-refman.pdf

This stack still seems to be used in things like some petrol / fuel pumps,
and in some of the coffee machines in Burger King (it's fascinating what
you can pull off ROM / flash from discarded devices :-))

These are "devices", but possibly not "hosts"...
W

> Host

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 8 Jan 2016 17:05:08 +0100

> this, if there is, indeed, a place where this is specified.

RFC1122 "Reqs for Internet Hosts -- Communication Layers" does not 
mention longest-prefix match.

RFC1812 "Reqs for IPv6 Routers" requires a router to use 
longest-matching network prefix when forwarding, to use a forwarding 
table (aka rt table) etc.

Alex

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 8 Jan 2016 16:34:34 +0000

Hi,

> From: v6ops [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
> Sent: Friday, January 08, 2016 8:05 AM
> To: [email-masked]
> Subject: Re: [v6ops] Routers are hosts too!
> 
> 
> 

RFC4191 does mention longest-prefix match for what it calls "Type C" hosts.

Thanks - Fred

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 08 Jan 2016 16:56:48 +0000

> These are "devices", but possibly not "hosts"...

this sounds like we're considering perfectly spherical ipv6 hosts in a
vacuum.

Nick

---

From: "Jeff McAdams" <[email-masked]>
Date: Fri, 8 Jan 2016 12:01:35 -0500 (EST)

> longest-matching network prefix when forwarding, to use a forwarding table
> (aka rt table) etc.

1122?  Wow, ancient days.

So, there are copious examples of RFCs that post-date 1122 where wording
wrt hosts at the very least presumes longest-match behavior...even if not
explicitly stated as such.

I see someone else already posted one, I turned up RFC3442 with only a few
minutes of looking.  (And, really, I usually pretty much only lurk on the
periphery of IETF activity...I'm sure others that have been more involved
over the years can find even better examples)

-- 
Jeff

---

From: [email-masked]
Date: Fri, 08 Jan 2016 18:14:07 +0100 (CET)

> this sounds like we're considering perfectly spherical ipv6 hosts in a

And continuing in this vein, pretty soon we'll assume a spherical cow
of uniform density? :-)

Let's get back to discussing IPv6, though. Personally I would prefer
if all "hosts" (servers, PCs, whatever) could simply use DHCPv6 PD and
be done with it.

Steinar Haug, AS2116

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 8 Jan 2016 17:14:51 +0000

Hi,

> From: v6ops [mailto:[email-masked]] On Behalf Of Jeff McAdams
> Sent: Friday, January 08, 2016 9:02 AM
> To: [email-masked]

Another is RFC6434 which (perhaps wisely) represents itself a "node requirements"
and not host/route requirements.

Thanks - Fred

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 8 Jan 2016 18:59:25 +0100

> RFC4191 does mention longest-prefix match for what it calls "Type C" hosts.

So that 'Updates' RFC1122, and it should say so on the RFC1122 page in 
the section "Updated by:"
https://tools.ietf.org/html/rfc1122

(currently several RFCs update rfc1122 and rfc4191 is not included).

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 8 Jan 2016 19:00:50 +0100

> over the years can find even better examples)

In that sense, I dont know what makes a Host be a Host and not a Router.

What particular characteristic of Host is not a characteristic of a 
Router too?

Alex

---

From: t.petch <[email-masked]>
Date: Fri, 8 Jan 2016 18:04:50 +0000

----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, January 08, 2016 5:14 PM

> And continuing in this vein, pretty soon we'll assume a spherical cow

I love the way that this thread was originally
'Focused Discussion'
and is now, well, the usual, focused, I suppose.

There is something about IPv6 that causes this to happen, and I suspect
that whatever it is is not conducive to the progress of either the IETF
or of the use of IPv6.  For myself, I have an existence proof, of the
non-existence of IPv6 in my own neck of the woods, and track this list
against the day when it exists and I have an interest.  If and when that
day comes, I might understand how it is that IPv6 Operations generates
more discussion with less apparent consensus than anything else I see in
the IETF, a process which I find more interesting than the technical
details of, say,  M and O, SLAAC, DHCPv6-PD etc- at least, at present.

Tom Petch

---

From: "Jeff McAdams" <[email-masked]>
Date: Fri, 8 Jan 2016 13:15:31 -0500 (EST)

> What particular characteristic of Host is not a characteristic of a

So, I'm still not sure what you're trying to accomplish out of this
discussion, but ok....

I think you have it backwards.  At least in my mind and the working
definitions I've always used, a router is a device that forwards packets
between network interface using Layer 3 addressing information.  A device
that *doesn't* forward traffic would thus *just* be a host.

I've never worked up a good working definition in my mind to decide
whether routers are hosts or not...mostly because, in 20+ years of my
career, it has never been something I've had to even think about.  Thus my
questioning of what this whole discussion is really all about.  We're - in
my mind - well into the territory of angels dancing on the head of a pin,
much ado about nothing, and a huge heaping dose of bikeshedding.

If you find an example of a system that *doesn't* do longest match, then
let's talk about it.  (Yes, I saw the example of uIP, I would argue it
does do longest match as it chooses between localnet destinations and
0.0.0.0/0...it just has an *extremely* constrained routing table capacity
- 2 entries, and a very unusual internal representation of that routing
table)

-- 
Jeff

---

From: Gert Doering <[email-masked]>
Date: Fri, 8 Jan 2016 19:21:43 +0100

Hi,

> What particular characteristic of Host is not a characteristic of a 

"not forwarding IP packets not destined to one of its own addresses"

iow, 

  ip.forwarding=0 -> host
  ip.forwarding=1 -> router

done

Gert Doering
        -- NetMaster

---

From: Mark Smith <[email-masked]>
Date: Sat, 9 Jan 2016 09:48:34 +1100

On 9 January 2016 at 01:22, Alexandre Petrescu
<[email-masked]> wrote:
<snip>
> Exact match is useful for the search in the ND cache, or for the search in
> Ethernet-related databases.  But I did not mean to compare it to
> longest-match.
>
> A host as people call a laptop, a smartphone or a tablet does implement it
> though.
>

I think that is probably because in part because either it has become
a common convention to do that (I'd say Windows is an example), or
that the OSes have origins of when routers were general purpose
computers running general purpose OSes that could be used as routers
with the flick of a switch. For example, looking at the text network
Richard Steven's used in his TCP/IP Illustrated book, all of the
routers in his network are Unix "hosts" with exception to one Cisco
router.

True "host only" processing might have been implemented on low end
OSes for embedded devices, although Moore's law, and the corresponding
explosion of the use of CPUs as they've got cheaper might have been
making it cheaper to use more powerful embedded devices and a general
purpose and much more widely used and supported OS, instead of less
powerful embedded devices and a more specific and limited OS (i.e.,
the costs incurred of using more powerful hardware are mitigated by
the savings made from using a widely used and supported OS).

Regards,
Mark.

---

From: Mark Smith <[email-masked]>
Date: Sat, 9 Jan 2016 10:30:28 +1100

>>
>> So what's your point?
>
>
> Maybe we should find that small rounding error - what OS does not implement
> longest-match and yet connects to the Internet?
>
> Second, until we ifnd that small rounding error, we may stop talking about
> Hosts, and declare the Host RFC historic.  Or update it with a sentence
> saying that Hosts too must implement longest-match.
>

So I think that might be missing the fundamental point I was making.

The distinction between a host and a router is a functional one,
purely related to what a device does when it receives a packet with a
non-local address, rather than being an fixed attribute of a
particular box of electronics. For example, a box of electronics
having multiple physical interfaces doesn't always make it a router,
or a box of electronics that only has a single physical interface
doesn't always make it a host.

I think the simple question to ask to determine whether the device is
performing a host or a router function for a particular packet is
"does the destination address in the packet match one of the receiving
device's addresses?". If the destination address does, then the packet
has reached its final destination, and the receiving device is a host
and will process the complete packet.

Another question to answer (which is more or less a rephrasing of the
previous question), is "where is the packet payload care/don't care
boundary?" If the device doesn't care what the packet payload is, it
is a forwarding device i.e. a router. If the device does care what the
payload is, because it is going to be processing the payload, then it
is a host, and that means that the packet has reached the destination
indicated in the destination address field. In the end-to-end
argument, it is the ends that are processing payloads.

A more specific version of that question is "does payload encryption
matter to the device or not?". If payload encryption doesn't matter,
then the device is a forwarding device/router, if payload encryption
does matter, meaning that the receiving device needs to be in a
position to decrypt the payload, then the device is a host, and the
destination address in the packet matches one of the host's addresses.

Regards,
Mark.

---

From: Joe Touch <[email-masked]>
Date: Fri, 8 Jan 2016 22:26:55 -0800

> mention longest-prefix match.

Section 3.3.2.3 (source address selection) refers to Section 3.3.1,
which includes a set of mechanisms in Section 3.3.1.2 for selecting
among multiple gateways.

Note that this algorithm involves using a route cache with ICMP
redirects that help the system learn the "best" (quote from the RFC)
next-hop. Those entries are described in terms of host routes, but there
is a discussion about aggregating those entries in 3.3.1.3.

The net result of that aggregation is effectively longest-prefix matching.

So you're strictly correct - RFC1122 does not require longest prefix,
but a large number of entries in the route cache is more effectively
handled as such.

Joe

---

From: t.petch <[email-masked]>
Date: Sat, 9 Jan 2016 13:04:41 +0000

----- Original Message -----
From: "Joe Touch" <[email-masked]>
To: "Alexandre Petrescu" <[email-masked]>;
<[email-masked]>
Sent: Saturday, January 09, 2016 6:26 AM

> but a large number of entries in the route cache is more effectively

But then RFC1122 does not mention classless addressing or Variable
Length Subnet Masks - as I recall, they did not exist at that time.
Rather, RFC1122 deals with 32 bit Host addresses and Classful Networks,
ie 8 or 16 or 24 bit addresses, so while you might have more than one
entry in the cache for a given destination, they will all be the same
length so the concept of longest-prefix (and of course, the term prefix
has no meaning at that date) match does not come into consideration.

Tom Petch

---

From: Joe Touch <[email-masked]>
Date: Sat, 9 Jan 2016 08:19:52 -0800

> On Jan 9, 2016, at 5:04 AM, t.petch <[email-masked]> wrote:
> 
> Length Subnet Masks -

That was introduced 200 RFCs later.  

> as I recall, they did not exist at that time.

You can still do longest match for classful routing.  

Where the gist aggregates these route chache entries and how is up to them, but the alternative is a nonscalable set of host routes 

Joe

---

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 10 Jan 2016 13:45:11 +0100

> So, I'm still not sure what you're trying to accomplish out of this

The Host-Router distinction is omnipresent in RFCs.  Whenever writing 
text one has to be careful about it.  There are many RFCs exclusively 
dedicated to Routers, others exclusively dedicated to Hosts.

> that *doesn't* forward traffic would thus *just* be a host.

This is a definition I can agree with.  There is more to it, however, 
especially when it comes to the presence of the rt table and algorithms.

> - 2 entries, and a very unusual internal representation of that routing

It's maybe about finding such a system, or about writing one.

In an IP stack the operations needing most computing power are at 
longest-match and at the CRC computation.  Their elimination can lead to 
very performant stacks - for Hosts.

I mean stacks that must run in constrained CPUs and still react very fast.

It is maybe researchy angels on top of trees... or maybe go the right 
WGs needing it.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 10 Jan 2016 13:48:20 +0100

>    ip.forwarding=1 -> router

Yes, I agree.  But when ip.forwarding=0 the Host still does forwarding 
between self issuing a packet and a next-hop that is looked-up.  Most 
Hosts on the market do this forwarding, even if they dont need to.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 10 Jan 2016 13:52:53 +0100

> has no meaning at that date) match does not come into consideration.

DO you mean that the longest-prefix match operation was not there since 
the earliest days of Internet?

Alex

---

From: [email-masked]
Date: Sun, 10 Jan 2016 15:07:04 +0100 (CET)

> the earliest days of Internet?

Reading up on the history of the Internet is recommended. See for
instance

https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing

Steinar Haug, AS2116

---

From: Joe Touch <[email-masked]>
Date: Sun, 10 Jan 2016 10:39:08 -0800

> https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing

Yes, but classless routing has nothing to do with longest prefix. 

Longest prefix is relevant only if the route cache has overlapping rules. That won't happen with host redirects. It only could happen with subnet redirects or manual entries (on a host / on a router, routing protocol entries would also be included.). 

Joe

---

From: Joe Touch <[email-masked]>
Date: Sun, 10 Jan 2016 10:42:31 -0800

On Jan 10, 2016, at 4:48 AM, Alexandre Petrescu <[email-masked]> wrote:

> Yes, I agree.  But when ip.forwarding=0 the Host still does forwarding between self issuing a packet and a next-hop that is looked-up.  Most Hosts on the market do this forwarding, even if they dont need to.

The do this and it is required. 

It is a next hop lookup but it's not called forwarding because the packet was generated internally - it literally Isn't being "forwarded" on behalf of another device. 

Joe

---

From: t.petch <[email-masked]>
Date: Tue, 12 Jan 2016 10:43:48 +0000

----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Sunday, January 10, 2016 2:07 PM
> https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing

Well, may be:-)

When I got involved with TCP/IP in 1992, subnets were fixed length
across any one network and longest match does not figure in any
description of routing at that time (Perlman, Interconnections, 1992;
IBM, TCP/IP Tutorial, 1989).  Before then, subnets did not exist - they
first appeared in RFC in 1984 (RFC950, 1985) so routing was purely based
on the network address, Class A, B, C.

Even in 1992, commercial products may not have had subnet support so
when designing an IP network, I had to check vendor literature for
subnet support before using it in a design.

Variable length subnets meant that the routing protocols had to carry
the length of the mask with the advertisement and you see this in RIPv2
(RFC1388, 1993) and this, coupled with CIDR, introduced me to the idea
of longest match in the forwarding algorithm.  I know of that from
RFC1349 (1992) and it will have been around earlier, but not by much -
as I say, it would have been alien to most at that time, certainly in
the commercial world, as opposed to the more academic/research oriented
IETF.

Does the history matter?  Well yes, if you are citing documents such as
RFC written at that time, ones which have not been superseded or updated
in that regard, such as RFC1122.  Host versus Router is one such, but
another is gateway (the term router is relatively recent if you look at
the RFC series as a whole) while the definition of the Network layer
generates divergent opinions on some IETF list; and then, when did the
Internet start?  April 1995 is my date, but I recognise that that
depends on your definition of Internet.  Best practice is to put in, or
cite, a definition so others are clear what you (think:-) you are
talking about.

Tom Petch