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

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

[Noel Chiappa]

    > From: Grant Taylor

    > I'm not quite sure what you mean by naming a node vs network interface.

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...

    > But I do know for a fact that in IPv4, IP addresses belonged to the
    > system.

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.)

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

    > I don't understand what you mean by using "names" for "path selection".

Names (in the generic sense above) used by the path selection mechanism
(routing protocols do path selection).

    > That's probably why I don't understand how routes are allocated by a
    > naming authority.

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.

	Noel

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

[Bakul Shah]

On Feb 4, 2019, at 12:29 PM, Noel Chiappa <jnc@mercury.lcs.mit.edu> wrote:
> 
>> From: Grant Taylor
> 
>> I'm not quite sure what you mean by naming a node vs network interface.
> 
> 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...

Xerox Network System (XNS) also had this property. A node had a
unique 48 bit address and each network had a unique 32 bit address.
Absolute host numbering meant you could move a host to another
network easily. IDP packet layout:


{checksum(2), length(2),
 transport ctl(1), packet type(1),
 dst net(4), dst host(6), dst socket(2),
 src net(4), src host(6), src socket(2),
 transport data(0 to 456), pad(0 to 1 byte)
}

IDP is @layer 3, same as IPv4 or IPv6.

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

[Clem Cole]

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

On Mon, Feb 4, 2019 at 4:23 PM Bakul Shah <bakul@bitblocks.com> wrote:

> On Feb 4, 2019, at 12:29 PM, Noel Chiappa <jnc@mercury.lcs.mit.edu> wrote:
> >
> >> From: Grant Taylor
> >
> >> I'm not quite sure what you mean by naming a node vs network interface.
> >
> > 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...
>
> Xerox Network System (XNS) also had this property. A node had a
> unique 48 bit address and each network had a unique 32 bit address.
> Absolute host numbering meant you could move a host to another
> network easily. IDP packet layout
>

Yeah, at the time, MetCalfe had the advantage of seeing what NCP and IP had
already learned.   We used to say in hindsight, Ethernet had too many
address bits and IP not enough.    So Noel and team invented ARP ;-)

Clem
ᐧ

[-- Attachment #2: Type: text/html, Size: 2089 bytes --]

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

[Grant Taylor via TUHS]

[-- 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 --]

[TUHS] IP weak/strong host model (was Re: OSI stack (Was: Posters))

[Derek Fawcus]

On Tue, Feb 05, 2019 at 11:01:23AM -0700, Grant Taylor via TUHS wrote:
> 
> 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.

This is generally referred to as the weak host model (or End System),
as opposed to the strong host model.  See RFC 1122, sect 3.3.4.2.

> 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 is not my understanding.  Either protocol can use either model in
a given system.  In theory it could even differ depending upon configurations.

Most systems I've worked on have used the weak model, but that is largely,
because they were routers, and looked up destinations in a FIB (or RIB)
before (or as well as) considering interface addresses.

Some OS's I've used followed the weak scheme, some followed the strong
scheme.

The following suggests that Linux defaults to weak, and that BSDs
default to strong; I've never tested that BSD case, but from memory
OSX (xnu) defaults to weak.

https://unix.stackexchange.com/questions/258810/linux-source-routing-strong-end-system-model-strong-host-model

DF