Subject: (IPng 6993) Re: route distribution via ND

From: Charles Perkins <[email-masked]>
Date: Wed, 30 Dec 1998 20:22:11 -0800 (PST)

Robert,

> "Default router" is a misnomer, "default" is not a property of the router,
> it is an attribution provided to it by the host.

O.K. so far...

>                                                  Any router that is truly
> a router should do.

I've been present in a number of discussions where some pretty
sharp people didn't agree on -what- exactly a router should do...
But, still, O.K. so far...

> If you are postulating an environment with some number (> 1) of brain dead
> semi-routers, that can't really route, but do forward some packets, then
> I think that is an environment that we ought to explicitly discourage (and
> certainly not fudge any protocols to support).

Here I think you go too far.

Q1) Is it legitimate (in your model of a collection of interconnected
    networks) for a network entity to agree to forward packets that it
    receives (somehow) and yet not to run a "routing protocol"?

Q2) If someone can build a small embedded system that incorporates
    such a network entity, and it is IPv6 addressable, why is it so
    bad for that entity to only want to forward a small number of
    packets?  I can easily imagine uses for such devices.

Q3) Even if such a network entity might have enough memory to run
    extra protocols, what if there were a great many of them, each
    of which only wanted to handle a few packets, and all of them
    had a network interface on a very busy network link so that none
    of them wanted to be a default router?

I'm not saying whether or not Router Advertisements ought to be doctored
up to supply this functionality, but I don't think it's so clearly
undesirable.  I'm also not claiming that IPv6 was designed for the case
in (Q3), but I don't understand the need to declare that case out of bounds.

Regards,
Charlie P.

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Robert Elz <[email-masked]>
Date: Thu, 31 Dec 1998 16:38:43 +1100

Date:        Wed, 30 Dec 1998 20:22:11 -0800 (PST)
    From:        Charles Perkins <[email-masked]>
    Message-ID:  <[email-masked]>

  | Q1) Is it legitimate (in your model of a collection of interconnected
  |     networks) for a network entity to agree to forward packets that it
  |     receives (somehow) and yet not to run a "routing protocol"?

It has to get its forwarding information from somewhere.   That somewhere
is a routing protocol (even if this means a human sitting at a keyboard once
a decade typing "route to abc/nn via pqr" type statements.)

So, no, it isn't, as without a routing protocol it cannot work.   

Note that we're talking exclucively of layer 3 forwarding devices here - that
is ones where the entity that originated the layer 2 packet explicitly
addressed it (at layer 2) to the device in question.   Devices that spoof
layer 2 type addresses, and such, to extract some packets from a layer 2
net and send them elsewhere are a different thing entirely (they most probably
need some kind of routing too, but not at layer 3).

Lastly, to perhaps avoid the need for further discussion, no, I don't 
necessarily see it as a requirement that a dynamic routing protocol be used.
Nor do I see that as relevant here.   (I also don't see send only RIP from
"routers" or listen only RIP on hosts as a dynamic routing protocol of any
substance).

  | Q2) If someone can build a small embedded system that incorporates
  |     such a network entity, and it is IPv6 addressable, why is it so
  |     bad for that entity to only want to forward a small number of
  |     packets?

Nothing wrong with that at all.   Certainly nothing I recall saying, or
intended to say, was supposed to require any specific ability to handle
any particular packet volume.

  | Q3) Even if such a network entity might have enough memory to run
  |     extra protocols, what if there were a great many of them, each
  |     of which only wanted to handle a few packets, and all of them
  |     had a network interface on a very busy network link so that none
  |     of them wanted to be a default router?

Somehow the hosts have to discover where to send the packets.   I doubt
that manual configuration of the hosts is the answer here (it wouldn't be
for the large number of postulated routing devices either, I suspect).

However that is to be done, something is going to have to be sending
some kind of announcements to the hosts telling them where to send the
packets.    For this, whether it is ND, or RIP seems to be fairly irrelevant.
Since RIP already accomplishes exactly this (and aside from indicating
which destinations can be forwarded to the router in question, allows the
router to indicate just how good a path it things it has to the destination
in question, so the host can select the best of possibly many paths).
RIP to me looks like a better fit as a protocol that will supply the
relevant information than ND.

About all that RIP lacks, and ND has, that might be useful are TTLs.   That
causes RIP to require protocol assumed TTLs, and consequently a higher
packet frequency (the protocol assumed TTL has to be low enough to handle
routes that change).   This just might be the justification required to
invent a new protocol.   I certainly don't see that the TTL missing from RIP
is any more (or even as) serious as the metric missing from the RA (were it
to be extended to this purpose - without that no metric is needed of course).

Then there's the question of redirects - the assumption has been that
redirects are too hard, somehow, for these devices to issue.   There are
two issues here - first traffic loads.   If, for whatever reason (perhaps
a new node that has seen an RA only from the device in question) a host decides
that it ought to be sending everything it has to this device, if the device
does not redirect, the host will slowly, at best, realise that it has picked a
poor default.   If it does send a redirect, then it can get rid of most such
traffic quite quickly.   Then there's the question of where to redirect to.
Unless we're assuming a half duplex device here, it is going to have to answer
that question for traffic coming the other way in any case - that has to be
forwarded somewhere, a redirect would be to wherever packets coming the
other way would be sent.

In theory that could be a "default router" which the device had been configured
to use - and which would then issue its own redirect - but if such a device
exists, it will be announcing itself in its RAs as a more preferred router
than these other devices, and hosts will be using that as their default
router instead of this imagined device - consequently it isn't likely to be
required to send many redirects.    If the only thing on the net are these
devices, then they're going to have to learn about each other somehow, and
which packets should go where - knowing that is sufficient to send
redirects, and if someone really built a net out of just these devices, that
is presumably what they'd want to occur.

Now what's left is the case where the devices are half duplex - they take
packets and send them, but never return any (and hence don't need to have any
clue at all where they would send packets on the net in question if one
arrives).   There are two cases here - one is where there is no return path
at all - hosts on the net in question have send only access (to everywhere, 
other than the level 2 net in question).   Personally I doubt this is a very
likely configuration...   (no access is possible, send only access seems 
useless).

On the other hand, if there is a router somewhere which can return packets
from these outside sources, then it must know the relevant routing information,
it can send redirects, and it would be the device to advertise itself as a
more preferred router, and hosts could send to it, and be redirected.  That
would fail only if it also is a half dupplex (incoming) device, unable to
receive from the local cable.   It seems to me that to get this far we're
indulging in flights of fantasy that are unrealistic in the extreme...

It is all very well to imagine building baby devices that have just the
absolute minimum that could be conceivably be required to function as an
IPv6 (or v4) router or host - but actually making the device be able to
do anything useful in a practical sense just about always is going to require
more than was first imagined (much more for routers than hosts).

kre