Subject: "ROUTERS" vs. "routers"

From: Fred Templin <[email-masked]>
Date: Tue, 25 Nov 2003 06:03:59 -0800

The v6ops discussion from the 'draft-ietf-v6ops-mech-v2-01.txt' thread
took on an interesting twist that I felt warranted a new subject heading.

RFC 2461 specifies the behavior of traditional routers (i.e., "ROUTERS").
"ROUTERS" typically advertise autoconfig parameters and prefixes from
their attached networks. Hosts use them to reach off-link nodes via default
or more-specific routes. But, a new breed of routers (i.e., "routers") is
emerging from paradigms such as Mobile Ad-hoc Networks. "routers"
typically advertise host routes only (aka, "addresses" or "locators") and
no prefix or autoconfig parameters at all.

I talked about this dichotomy several years ago in my writings
in the MANET wg and in some of the contract work I did at SRI
International. The dichotomy is also discussed in documents such
as the "global6" work by Charles Perkins and his colleagues. But,
the notion of "routers" has really been around for decades and is
quite well known in some circles.

In the MANET paradigm, "routers" often have only a single network
interface which may be used for multi-hop forwarding within a flat
addressing space (i.e., using host routes and redirects to steer the
multi-hop forwarding decisions) while "ROUTERS" are used to reach
other off-link networks. But, the same paradigm can be applied to the
emerging global IPv6 Internet.

In particular, I believe we will soon see an emerging paradigm for
IPv6 in which most (if not all) nodes will be "routers" and a smaller
subset of the nodes will be "ROUTERS". A node can qualify as a
"router" IFF it has the proper credentials so that other nodes can
guard against redirection attacks. The NOID approach specifies
a method by which "routers" may attain the proper credentials
(it also supports site-multihoming as an added attraction):

  http://www.ietf.org/internet-drafts/draft-nordmark-multi6-noid-01.txt

"routers" will also need a means for distributing host routes w/o
including the normal information traditional "ROUTERS" advertise.
The "Default Router Preferences, More-Specific Routers and Load
Sharing" approach specifies the necessary mechanisms:

http://www.ietf.org/internet-drafts/draft-ietf-ipv6-router-selection-02.txt

So, what is missing? It would be desireable for a node sending
an RFC 2461 Router Solicitation to be able to specify whether
"ROUTER" or "router" information (or both) was being solicited.
This function can be accommodated by either providing a codepoint
(i.e., 1-2 bits) in the existing Router Solicitation message or a new
IPv6 Neighbor Discovery message type (call it a "Type II Router
Solicitaiton" for lack of a better name.) Perhaps this isn't even
needed; I would be happy to let others comment.

So, where does the "all nodes are routers" model lead us? To an
IPv6 Internet with end-to-end security, site multihoming, multi-hop
forwarding capability, and a restoration of the end-to-end principles.

I think we need to get on board with this, folks...

Fred
[email-masked]

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Havard Eidnes <[email-masked]>
Date: Tue, 25 Nov 2003 15:28:39 +0100 (CET)

Hm,

I hope I'm not the only one who find the choice of wording to be
unfortunate.

From the 10km-high perspective, there should be other and more
fundamental distinguishing marks than the prefix length of
advertisments or more general protocol behaviour to draw the line
between what has traditionally been named "hosts" and "routers".

I'll therefore give some pushback on introducing a subtle
for-ipv6-only distinction between "ROUTERS" and "routers".

Regards,

- Håvard

---

From: Fred Templin <[email-masked]>
Date: Tue, 25 Nov 2003 07:05:50 -0800 (PST)

Whoops! I got just a tad bit overboard in my message and need to
add some balance. There will still be *plenty* of simple hosts in the
new paradigm that neither need nor want to be considered as "routers"
or "ROUTERS". They will include things like my home printer, my
home security system, my car's speedomeer, etc. These will be
good candidates for an IPv6 local addressing scheme of some sort.
 
Fred Templin
[email-masked]
[email-masked]

Fred Templin <[email-masked]> wrote:
The v6ops discussion from the 'draft-ietf-v6ops-mech-v2-01.txt' thread
took on an interesting twist that I felt warranted a new subject heading.

Fred
[email-masked]

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Wed, 26 Nov 2003 14:12:12 +1100

On 2003-11-25, Fred Templin wrote:
> [...]
> interface which may be used for multi-hop forwarding [...]

Firstly, I don't think differentiating 'router' and 'ROUTER' is
a good idea.  I for one would find it hard to follow in conversation :-)

I think the usual definition of Router is a good one -- a Router
is a node which forwards packets.  

It seems to me that the confusion is not in the definition of
Router, but in the definitions of 'Interface', 'Link' and 'Network',
which don't generally take wireless into account.

-----Nick

---

From: Pekka Savola <[email-masked]>
Date: Wed, 26 Nov 2003 12:26:08 +0200 (EET)

(Tai out v6ops list..)

> which don't generally take wireless into account.

I agree with this view, it's no use trying to overload two different 
meanings for a router depending on capitalization.

I don't think it matters at all whether a router has just one 
interface or many, or what it advertises or not, or whether it 
pretends to be a host on one interface, or originates UDP/TCP packets, 
or whatever.  It's still a router.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Fred Templin <[email-masked]>
Date: Wed, 26 Nov 2003 11:12:52 -0800

As I said in my last message, my goal was to get a message  out and
not push new terminology. I agree with Pekka that it doesn't matter at
all whether a router has just one interface or hundreds; it is still a 
router.
(In fact, this is nearly the exact response I received when I asked a 
related
question during an IPv6 session at IETF 58.) Hosts with embedded gateway
functions, as described in RFC 1122, section 3.3.4.2 under: "Weak ES
Model" also qaulify as routers, and it doesn't matter at all what
different routers advertise - they are all still just *routers*.

However, the message that must not be lost in the terminology shuffle
is that it very much *does* matter that nodes be able to selectively
solicit at least two different classes of information from routers:

  1) Classical prefix/autoconfig information as specified in RFC 2461
  2) Route Information Options as specified in:

The two ways I see to do this are to either specify a new IPv6 ND option
(call it a "Type II Router Solicitation" for lack of a better name) or 
to add
bits to the existing IPv6 Router Soliciation message (e.g., in the 
"Reserved"
field) that indicate the type of information being solicited.

What does the wg feel is the best way to move forward with this?

Thanks - Fred
[email-masked]

---

From: Pekka Savola <[email-masked]>
Date: Wed, 26 Nov 2003 21:47:05 +0200 (EET)

On Wed, 26 Nov 2003, Fred Templin wrote:
> The two ways I see to do this are to either specify a new IPv6 ND
> option (call it a "Type II Router Solicitation" for lack of a better
> name) or to add bits to the existing IPv6 Router Soliciation message
> (e.g., in the "Reserved" field) that indicate the type of
> information being solicited.

I do not see the issue you describe.  You can solicit exactly this
kind of information from any node you wish, right?

Naturally, the hosts won't answer; some routers might not either
(e.g., if they aren't configured to advertise such information) -- but
that's not really relevant -- anyone can elect to be silent if they
wish!

Are you suggesting that all routers be somehow "forced" to return this
kind of information (when asked explicitly in some defined manner)
whether they advertise it or not?

That probably would not fly.  

Or are you suggesting that routers should be able to advertise (or 
tell, when asked explicitly) about the information they know about 
prefixes/autoconfig/routes, without the hosts implying they would act 
as a default router as well?  Not sure I'd see a point for something 
like that..

If you meant something else, I didn't understand ..

---

From: Fred Templin <[email-masked]>
Date: Wed, 26 Nov 2003 12:13:47 -0800

Pekka,

I meant only what I said - nodes should be able to selectively solicit
at least two different classes of information from routers. (Perhaps
there will be even more classes of information in the future; I
don't know).

Some routers might advertise only prefix/autoconfig information,
so they might not respond to the "Type II Router Solicitation" I
alluded to below. Other routers might advertise only route
information, so they might not respond to an ordinary IPv6
Router Solicitation. Still other routers might advertise both
classes of information, so they might happily respond to
either type of solicitation.

I'm not necessarily trying to write the MAY/SHOULD/MUSTs
here; I'm simply identifying the need and soliciting input from
the wg; thanks for providing yours.

Fred
[email-masked]

---

From: Fred Templin <[email-masked]>
Date: Wed, 26 Nov 2003 14:50:25 -0800

> field) that indicate the type of information being solicited. 

To respond to my own post, it just occurred to me there may be
a  least one other possibility (and probably countless others) to
get the needed message types. Maybe we could hijack an unused
ICMPv6 Type code from the IANA registries?

A quick look at the 'icmpv6-parameters' registry shows:

 138  Router Renumbering                               [Crawford]
 139  ICMP Node Information Query                      [Crawford]
 140  ICMP Node Information Response                   [Crawford]

I see that the Router Renumbering option is used by RFC 2894,
but does anyone know if the other options are used anywhere?

If not, the "Node Information Query" would be a perfect fit
for the "Type II Router Solicitation" I've been asking about,
and the "Node Information Response" could be used to carry
the Route Information Options needed by:

instead of hacking the IPv6 Router Advertisment message format.
Sounds like a win-win, doesn't it?

Matt, can you comment as to the availability of the Type codes?

Thanks - Fred
[email-masked]

---

From: Fred Templin <[email-masked]>
Date: Wed, 26 Nov 2003 16:47:17 -0800

Responding one final time to my own post, I think we should forget
this business about hijacking and just use Matt's document instead:

http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-icmp-name-lookups-10.txt

It looks mature, well fleshed out, and has some nice features
like references to interoperable implementations.

I also wrote a document of my own that references Matt's
work and posted it to the I-D registrar. You can find a
copy in the interim at:

  http://www.geocities.com/osprey67/isnoid-01.txt

Thanks - Fred
[email-masked]

Fred Templin wrote:

>> (call it a "Type II Router Solicitation" for lack of a better name) 
>> or to add

---

From: Fred Templin <[email-masked]>
Date: Wed, 26 Nov 2003 17:14:37 -0800

Thanks Matt,

I'm going to give things a rest for awhile now and let
the dust settle.

Have a Happy Thanksgiving to those who celebrate it.

Fred
[email-masked]

Matt Crawford wrote:

> On Nov 26, 2003, at 4:50 PM, Fred Templin wrote:
>
> There are multiple implementations of node informations queries (and 
> responses, of course).
>
> You could define new query types that might do what you want; I can't 
> comment on the fit of your application to this mechanism without doing 
> a lot of background reading.
>
>                                 Matt Crawford
>
>

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 26 Nov 2003 21:23:59 -0800 (PST)

>  Hosts with embedded gateway

That wouldn't be consistent with the definition of router
in RFC 2460; a node which forwards packets not explicitly addressed
to itself.
A host in the weak ES model would still only handle packets destined to 
the addresses assigned to that host; hence it isn't a router per the
RFC 2460 definition.

  Erik