Subject: (IPng 6964) route distribution via ND

From: Richard Draves <[email-masked]>
Date: Tue, 22 Dec 1998 14:31:45 -0800

Marc Fiuczynski and I came up with a simple idea for distributing routes via
Neighbor Discovery.

The basic problem we want to solve is letting routers inform hosts about
routes. For example, we don't want to manually configure hosts to know that
a certain v6 prefix should be routed to Marc's v6-v4 translator.

One solution is not to bother with this: let hosts send to a default router,
and the default router can redirect as necessary. But the redirect overhead
might be undesirable in some environments.

My understanding of v4 practice is that hosts will sometimes "snoop" routing
protocols like RIP and so learn routes.

One can view ND as performing distribution of routes. For example receipt of
an RA with a non-zero router lifetime communicates a default route (/0
route). A prefix-information option with the L bit communicates an on-link
prefix (a /64 route).

Why not define an option to let RAs communicate routes more generally? For
example, define a new flag bit (call it the N bit) for prefix information
options to say that this prefix should be added to the receiving host's
route table, with the router sending the RA as the next-hop for the prefix?

This is more desirable than snooping random routing protocols. Hosts must
implement ND anyway so there is very little implementation overhead.

Some possible problems that have occurred to us:

1. Currently the conceptual data structures are simple - there's no routing
table, just an on-link prefix list and a default router list.
Answer: simple hosts can ignore these options. They will send to a default
router which can redirect.

2. Growth in size of ND messages, upper limit to number of routes that can
be communicated in one ND message.
Answer: yes, not suitable for super complex topologies. Routers should
aggregate and only distribute a few prefixes, if any, this way.

3. Should this be a variation of the prefix information option or separate
option?
There are only a few flag bits left. And in most scenarios, I don't see the
N bit being turned on in conjunction with another bit. So defining a
separate option type probably wouldn't hurt. On the other hand, using the
prefix information option means it takes very little additional code to
support this.

Anyway, we've implemented this idea and it's working great for us so far.
Is it worth writing up as an I-D?

Thanks,
Rich
--------------------------------------------------------------------
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: Craig Metz <[email-masked]>
Date: Tue, 22 Dec 1998 13:00:48 -0500

>route table, with the router sending the RA as the next-hop for the prefix?

  Unless I'm highly confused or the specs changed, ND already does this and was
intended all along to do this. Advertise a prefix with autonomous off and
on-link off.

									-Craig

---

From: "Matt Crawford" <[email-masked]>
Date: Tue, 22 Dec 1998 17:42:39 -0600

> > route table, with the router sending the RA as the next-hop for the prefix?

I don't think this scales at all, and it doesn't replace the redirect
sufficiently.  There could be zillions of routes you might want to
advertise, and you might want the first-hop router to be chosen based
on more factors than just the destination.  (E.g., the source address
or the traffic class.)

>   Unless I'm highly confused or the specs changed, ND already does
> this and was intended all along to do this. Advertise a prefix with
> autonomous off and on-link off.

No, no, not at all.  See, for exmaple, RFC 2461, page 53:
   The default behavior (see
   Section 5.2) when sending a packet to an address for which no
   information is known about the on-link status of the address is to
   forward the packet to a default router; the reception of a Prefix
   Information option with the "on-link " (L) flag set to zero does not
   change this behavior. 
--------------------------------------------------------------------
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: Thomas Narten <[email-masked]>
Date: Wed, 30 Dec 1998 08:16:56 -0500

> a certain v6 prefix should be routed to Marc's v6-v4 translator.

Note that the need to have prefix routes installed in hosts is only
necessary if the host has multiple interfaces (i.e., is
multihomed). If there is just one interface, using a single default
route and redirects will handle everything just fine.

> One solution is not to bother with this: let hosts send to a default
> router, and the default router can redirect as necessary. But the
> redirect overhead might be undesirable in some environments.

I'd like to better understand this argument. The overhead of one
redirect amortized over the life of every "flow" is almost always
going to be noise in the overall scheme of things. What part of the
overhead is undesirable?

Note also, that if prefixes were propagated via ND, one can still
construct scenarios where advertising prefixes would result in *more*
redirects than if prefixes were not advertised at all. For example, if
the advertised prefix was a large aggregate, more specific prefixes of
the aggregate might need go out through a different path.

> My understanding of v4 practice is that hosts will sometimes "snoop"
> routing protocols like RIP and so learn routes.

I would argue this is only useful/necessary on multihomed hosts, where
having a list of default routers doesn't help in choosing the correct
outgoing interface. (Once an interface has been selected, redirects
can be used to find the best router on that interface.)

> One can view ND as performing distribution of routes. For example
> receipt of an RA with a non-zero router lifetime communicates a
> default route (/0 route). A prefix-information option with the L bit
> communicates an on-link prefix (a /64 route).

> Why not define an option to let RAs communicate routes more
> generally? For example, define a new flag bit (call it the N bit)
> for prefix information options to say that this prefix should be
> added to the receiving host's route table, with the router sending
> the RA as the next-hop for the prefix?

I think it is worth stepping back and understanding the actual problem
that needs solving. If it is to handle the multihomed host case, it
seems like it might also be useful to have a metric, so that a host
could select the router with the "shorter" route for a prefix. Once
you add a metric, seems like you've reinvented RIP. Why not just use
it? Indeed, a client (receive-only) version of RIP wouldn't have to be
large and would seem to do the job already. 

> implement ND anyway so there is very little implementation overhead.

I agree that snooping "random" routing protocols is undesirable. But I
see nothing wrong with using RIP as a "last hop" technology for
communicating routing information from routers to hosts. One could
still run OSPF (or whatever) on the network, just using RIP for the
last hop.

Or if RIP doesn't quite do all the right things for this, define a
protocol that does. 

Thomas

---

From: Bill Manning <[email-masked]>
Date: Wed, 30 Dec 1998 06:50:07 -0800 (PST)

> Or if RIP doesn't quite do all the right things for this, define a

I presume that you are refering to RIPv2 here and not RIPv1.
IPv6 has inherited the concept of classless delegation and so
the base of any such work should come from the RIPv2 spec.

--bill