4 Feb
2019
4 Feb
'19
8:29 p.m.
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
4 Feb
4 Feb
9:13 p.m.
New subject: OSI stack (Was: Posters)
On Feb 4, 2019, at 12:29 PM, Noel Chiappa <jnc(a)mercury.lcs.mit.edu> wrote:
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.
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... 
9:34 p.m.
New subject: OSI stack (Was: Posters)
On Mon, Feb 4, 2019 at 4:23 PM Bakul Shah <bakul(a)bitblocks.com> wrote:
On Feb 4, 2019, at 12:29 PM, Noel Chiappa
<jnc(a)mercury.lcs.mit.edu> wrote:
an
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
ᐧ
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. '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
5 Feb
5 Feb
6:01 p.m.
New subject: OSI stack (Was: Posters)
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
10:14 p.m.
New subject: IP weak/strong host model (was Re: OSI stack (Was: Posters))
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…
DF
1918
days inactive
1919
days old
4 comments
5 participants
participants (5)
-
Bakul Shah -
Clem Cole -
Derek Fawcus -
Grant Taylor -
jnc＠mercury.lcs.mit.edu