Re: [TUHS] OSI stack (Was: Posters)

[Grant Taylor via TUHS <tuhs@minnie.tuhs.org>]

[-- Attachment #1: Type: text/plain, Size: 3894 bytes --]

On 02/04/2019 01:29 PM, Noel Chiappa wrote:
> Does one name (in the generic high-level sense of the term 'name'; 
> e.g. an 'address' is a name for a unit of main memory) apply to the node 
> (host) no matter how many interfaces it has, or where it is/moves in 
> the network? If so, that name names the node. If not...

The vagaries of multi-homed hosts make the answer more complicated.

I generally think that a host name applies to the host, no matter how 
many interfaces it has, or where it is / moves in the network.  But 
that's the "host name".

There are other names, like service names, that apply to a service and 
can (re)pointed to any desired back end host name at any given time.

I usually think that host names should resolve to all IPs that are bound 
to a host.  I then rely on the DNS server to apply some optimization 
when possible about which IP is returned first based on the client's IP. 
  I also depend on clients preferring IPs in the directly attached 
network segment(s).

> No. Multi-homed hosts in IPv4 had multiple addresses. (There are all sorts 
> of kludges out there now, e.g. a single IP address shared by a pool of 
> servers, precisely because the set of entity classes in IPvN - hosts, 
> interfaces, etc - and namespaces for them were not rich enough for the 
> things that people actually wanted to do - e.g. have a pool of servers.)

Please allow me to clarify.

First, I'm excluding load balancers or similar techniques that spread an 
IP out across multiple back end servers.  Save for saying that I'd argue 
that such an IP belongs to the load balancer, not the back end server. 
That aside.

Multi-homed IPv4 hosts (all that I've tested) usually allow traffic to a 
local IP to come in on any interface, even if it's not the interface 
that the IPv4 address is bound to.

Take the following host:

+---+   +-----------------+   +---+
| A +---+ eth0   B   eth1 +---+ C |
+---+   +-----------------+   +---+

Even if B has IPv4 forwarding disabled, A will very likely be able to 
talk to B via the IPv4 address bound to eth1.  Likewise C can talk to B 
using the IPv4 address bound to eth0.

My understanding is that IPv6 changes this paredigm to be explicitly the 
opposite.  If B has IPv6 forwarding disabled, A can't talk to B via the 
IPv6 address bound to eth1.  Nor can C talk to B via the IPv6 address 
bound to eth0.

That's why I was saying that the IPv4 addresses on eth0 and eth1 
belonged to the OS running on B, not the specific interfaces.

> Ignore what term(s) anyone uses, and apply the 'quack/walk' test - 
> how is it used, and what can it do?

I will have to test this when time permits.

But the above matches how I remember the duck quacking and walking.

> Names (in the generic sense above) used by the path selection mechanism 
> (routing protocols do path selection).
> 
> They aren't. But the path selection system can't aggregate information 
> (e.g.  routes) about multiple connected entities into a single item (to 
> make the path selection scale, in a large network like the Internet) 
> if the names the path selection system uses for them (i.e. addresses, 
> NSAP's, whatever) are allocated by several different naming authorities, 
> and thus bear no relationship to one another.
> 
> E.g. if my house's street address is 123 North Street, and the house next 
> door's address is 456 South Street, and 124 North Street is on the other 
> side of town, maps (i.e. the data used by a path selection algorithm to 
> decide how to get from A to B in the road network) aren't going to be 
> very compact.

Agreed.  The number of routes / prefixes and the paths to get to them 
has been exploding for quite a while now.  I think the IPv4 Default Free 
Zone is approaching 800,000 routes / paths.



-- 
Grant. . . .
unix || die


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4008 bytes --]