Subject: Re: New draft on "Stub Router Advertisements in IPv6 NeighborDiscovery"

From: Thomas Narten <[email-masked]>
Date: Tue, 01 Dec 2009 09:09:33 -0500

"Templin, Fred L" <[email-masked]> writes:

> When a stub router connects a stub network to a link,
> it needs to somehow be provisioned with one or more
> default routes pointing to other routers on the link
> that can forward packets on toward a provider network.

"provisioned" is the wrong word, as it suggests some sort of manual
configuration (or configuration of a central database that pushes
config out to that router, using mechanisms other than normal IGPs).

> The normal IPv6 ND mechanism for this is RS/RA, but
> if the stub router were to send an RS the routers that
> receive it would immediately set 'isrouter' to FALSE
> and we don't want that.

No it is not. The normal way to "provision" default (and other) routes
is via routing protocols. I am not convinced that we have a need to
move away from this basic model, that has served the internet well for
pretty much its intire existance.

> At the same time, the stub router may need to publish
> its prefixes with other routers, and it can do so by
> including RFC4191 Route Information Options in the
> RAs that it sends.

What does "publish its prefixes with other routers" mean?

Yes, all routers somehow need to be configured to know what prefixes
to advertise via RAs on its links.  Nothing new here.

> A valid question is why not just run a routing protocol
> between all the routers on the link? That may be the
> preferred method in some cases, but when there are many,
> many routers on the link the control overhead would be
> excessive when only a few default routes are needed.

This is the standard default way to do this in IPv6. If there is
something wrong with this approach, i.e., there is a real concrete
problem, and the broader community/WG agrees that a valid problem
exists that needs solving, then we should discuss.

But some vague notion of "excessive control overhead" does not come
close to being a problem statement IMO.

> Also, discovery of other routers on the link in order
> to bootstrap neighbor relationships may be difficult
> to automate on links such as NBMA.

The let's talk specific links and how common they are in practice,
etc. But lets not just talk about generic NBMA links, as if they are
common.

> But the simplest explanation is that RFC4861 currently
> says that routers send RAs irrespective of whether/not
> they are authoritative for the link. So, this spec
> updates RFC4861 by specifying appropriate limits on
> the information stub routers may include in their RAs.

Sorry, I still do not get the concept of "authoritative"
vs. "non-authoritative" routers on a link.

Thomas

---

From: Thomas Narten <[email-masked]>
Date: Tue, 01 Dec 2009 09:12:44 -0500

Mark Smith <[email-masked]> writes:

> I think a "prefix redirect" mechanism is justified because it provides
> more optimal forwarding for inter-CPE traffic. I only brought up
> the LI issue and addressed it because that seemed to be the only
> objection there was to the idea when I suggested it before. I don't
> think it is a valid concern, and if the IETF has decided not to
> consider LI type requirements, then it is one less thing any drafts have
> to address and document.

A prefix redirect is a minor performance optimization over the current
redirects we have.

I remain skeptical that such a redirect is needed and provides
sufficient value.

Note that this is not the first time such a redirect was suggested.
It's been discussed in the past, but there was never really enough
support for it to go forward.

As always, what exactly is the problem that needs solving here? I'm
not talking about a generic "possible" performance benenfit in "some
cases". What specifically do we see happening in real (or planned)
deployments that justifies this sort of enhancement?

Thomas

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 1 Dec 2009 09:59:00 -0800

Thomas,

> -----Original Message-----
> From: Thomas Narten [mailto:[email-masked]]
> Sent: Tuesday, December 01, 2009 6:10 AM
> To: Templin, Fred L
> Cc: [email-masked]
> Subject: Re: New draft on "Stub Router Advertisements in IPv6 NeighborDiscovery"
> 

OK - I guess I probably should have said "it needs to
somehow discover one or more default routes".

> No it is not.

I think perhaps my wording was confusing. What I meant to
say was that the normal IPv6 ND mechanism *between a host
and a router* is RS/RA, but a stub router can't perform an
RS/RA exchange with a default router because then it would
then be mistaken for a host.

> The normal way to "provision" default (and other) routes

I agree that routing protocols can be used on links that
have a bounded and known set of routers (both default
and non-default). On links with an unbounded and/or unknown
set of routers (e.g., ISATAP), or when there is no trust
relationship between routers (again e.g., ISATAP) it may
not be feasible to engage all of the routers in a routing
protocol. 
 
> What does "publish its prefixes with other routers" mean?

I meant to say: "the stub router may need to advertise its
prefixes to other routers".

> to advertise via RAs on its links.  Nothing new here.

Right; this doesn't change anything but rather clarifies
what stub routers can and cannot do.

> exists that needs solving, then we should discuss.

This goes with what I was saying above. With ISATAP,
for example, there may be an unbounded and/or unknown
set of routers on the link, and there may be no trust
relationship between routers on the link (but SEND can
be used to establish the trust relationship). In that
case, it may not be feasible to use a standard IPv6
routing protocol whereas the IPv6 ND mechanisms I am
describing can be used.

> close to being a problem statement IMO.

I agree that my statement was weak and not well thought
out. A more thorough problem statement could certainly
be added to the document.

> etc. But lets not just talk about generic NBMA links, as if they are

Well, maybe that means we should just address this in
any "IPv6-over-(foo)" documents that deal with the
specific links?

> vs. "non-authoritative" routers on a link.

Perhaps my writings have been over-reaching in their
attempt to motivate these new terms. If I stuck with
the simplest terminology, perhaps I just could explain
things in terms of "stub routers" and "default routers"?

Fred
[email-masked]

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 1 Dec 2009 09:34:48 -0800

Brian,

> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Monday, November 30, 2009 5:53 PM
> To: Templin, Fred L
> Cc: Mark Smith; Thomas Narten; Hinden; [email-masked]; [email-masked]
> > The lawful intercept question is an interesting one, but
> > as you say if the ISP owns both the L2 and L3 infrastucture
> > there should be a way to support it. It may be much more
> > challenging to do the intercept from L2 switches located
> > close to the CPEs, however, since you may need many points
> > of intercept in order to watch all CPEs.
> >
> >> I think it'd be useful if this draft or associated ones provided a
> >> mechanism applicable to this ISP scenario.
> >
> > OK. Thanks.
> 
> However, the IETF policy stated in RFC2804 says
> 
> "1. Summary position
> 
>    The IETF has decided not to consider requirements for wiretapping as
>    part of the process for creating and maintaining IETF standards."
> 
> so while this issue may affect actual deployment scenarios, it can't
> directly affect our protocol design requirements here.

Thanks for pointing this out. The redirect mechanism we
have been discussing in this thread actually provides a
policy control point to the operator, in that the operator
can configure its routers to either send or not send the
redirects in accordance with its policy. None of this
needs to be dealt with in the protocol designs, which
deal only with mechanisms. 

> (I would suggest that statements of agreement or disagreement with
> this IETF policy don't belong on this list.)

Understood.

Fred

>     Brian

---

From: Thomas Narten <[email-masked]>
Date: Tue, 01 Dec 2009 13:17:51 -0500

Fred,

Let's up level. I fundamentally do not understand the motivation for
any of this work. That is what I mean by "what's the problem".  Let's
focus on that question alone, because if I (or the community) is not
convinced there is an actual problem that needs work, there is no
point in continuing.

Going back to your document:

>    The IPv6 Neighbor Discovery protocol [RFC4861][RFC2460] specifies the
>    operation of routers, including the process of sending and receiving
>    Router Advertisement (RA) messages.  However, the specification makes
>    no distinction between different classes of routers that may occur on
>    a link.  In particular, the specification is written from the
>    perspective of routers that are "authoritative" for the link, i.e.,
>    routers that connect the link to provider networks.  This document
>    discusses considerations for a different class of routers known as
>    "stub routers".

I question your first assertion that there are different "classes" of
routers, or rather, that we (the IETF) need to start defining what
these classes are. (I will agree that enterprise deployments may well
have differennt "classes" of routers, but that is for internal
purposes and so far does not appear to lead to problems that the IETF
needs to get involved in).

Second, I simply do not understand what you mean by defining routers
as "authoritative" or "not" for a link. If a router is attached to the
link, everyone assumes it is a router and is "authoritative". That is,
everyone trusts/believes it (in the absence of things like
SEND). There is no notion of some routers being more authoritative
than others.

If you are worried about security, the routers may do their own
security and thereby exclude "non authoritiative" routers. But this
does not need to be made visible in the protocols.

So, what are the real differences between what you call an
"authoritative" router from one that is not? And why is it
useful/necessary to make such a distinction?

Finally, I'm not sure I even understand exactly what "routers that
connect the link to provider networks" covers. Is it only the router
that connects to the ISP? or is it all the routers that form part of a
spanning tree that points to the ISP? (And what happens when you have
multi-homed sites?)

Some pictures might help here. Something with at least a handful of
internal links, and maybe 2 connections to the public internet
(through different ISPs). And then label the various routers and what
kind they are (and why).

Thomas

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 1 Dec 2009 13:02:43 -0800

Hi Thomas,

> Sent: Tuesday, December 01, 2009 10:18 AM
> To: Templin, Fred L
> Cc: [email-masked]

I am hoping some of this can be cleared up in a picture:

  http://osprey67.com/stub-router.pdf

In this picture, the link I am concerned with is labeled
"NBMA Link" in the diagram. As you can see, there are
stub networks connected to the link by stub routers, and
default routers that connect the link to provider networks
(which then connect to the Internet in some way). The link
is intentionally shown as two segments joined together by
"..." to show that it can be arbitrarily large and in some
cases may contain hundreds, thousands, or even more stub
routers and stub networks.

>From the diagram, only those routers labeled "default router"
should advertise default router lifetimes, M&O flags, PIOs,
and other RA information that provides operating parameters
for the link. If the routers labeled "stub router" also
advertised those kinds of parameters, then any hosts labeled
"host on NBMA link" would incorrectly update their link
parameters. As a simple example, if a router labeled "stub
router" advertised a non-zero default router lifetime in
an RA that was heard by a host labeled "host on NBMA link",
then the host would incorrectly configure a default route
that points to a stub network.

Does this help?

Fred

---

From: Thomas Narten <[email-masked]>
Date: Tue, 01 Dec 2009 16:53:32 -0500

Hi Fred.

the picture is a start...

> "NBMA Link" in the diagram.

Please add an indication for what a typical "site" is. Are all of the
stub networks considered part of the same site (i.e., same company,
same house, etc.)?

Also, you show "stub network 1", 2, 3, .etc.

What is the internal structure of those networks (or does it matter)?
In particular, there are presumably multiple links present in a stub
network. Are there only "normal" routers internally? Can a "stub"
router only exist on the NBMA link?

Can you provide a specific example of the kind of link technology you
are thinking of for the NBMA link? Is this DSL/Cable/ATM? Or just a
hypothetical NBMA link? And who runs the NBMA link? Is this not a link
operated by the Provider?

I see there are "hosts" on the NMBA link. Can you provide examples of
what kind of hosts? (I guess I really don't understand the deployment
model you are assuming here... i.e., why wouldn't the NBMA link only
have routers on it, with all hosts being behind a router.)

> As you can see, there are stub networks connected to the link by
> stub routers, and default routers that connect the link to provider
> networks (which then connect to the Internet in some way). The link
> is intentionally shown as two segments joined together by "..." to
> show that it can be arbitrarily large and in some cases may contain
> hundreds, thousands, or even more stub routers and stub networks.

OK.

> that points to a stub network.

OK. I understand this.

That said, my first reactions would be: 

1) is this a real deployment scenario? Who is setting up a network
   like this? Maybe they shouldn't do this and there are better
   approaches...

2) So what if the default route (on some hosts) points to the wrong
   thing, the stub router will presumably send a redirect for any
   traffic it is relaying, and the host will update its cache and from
   that point forward things are fine. Perhaps not "optimal" in a pure
   sense, but I certainly don't see this is as so broken a fix is
   needed... At least not without really understanding who is
   operating a network like this...

Thomas

---

From: Mark Smith <[email-masked]>
Date: Wed, 2 Dec 2009 09:41:30 +1030

Hi Thomas,

On Tue, 01 Dec 2009 09:12:44 -0500

> deployments that justifies this sort of enhancement?

I'm still a bit confused about Fred's scenario, however here is the one
I've been thinking about.

Broadband Forum TR-101 describes using Ethernet instead of ATM for
backhaul. This technology has been deployed here in Australia quite
significantly over the last 5 years.

The common deployment model for IPv4 over ADSL in these networks is
PPPoE, resulting in hair pinning of traffic between subscribers when
they're attached to the same ethernet segment. PPPoE makes
broadband look like high speed dialup, which allowed ISPs to introduce
broadband fairly rapidly without having to change their backend
authentication/billing systems etc. The drawback is the overheads of
potential authentication failures due to username/password errors, when
the ISP already knows who the subscriber is (i.e. they know where they
live), and the PPPoE 8 byte per packet cost which is to essentially
convert the multi-access nature of Ethernet into a point-to-point
service, resembling dialup.

The number of subscribers attached to an exchange/central office can be
small enough that installing redundant layer 3 infrastructure in each
exchange/C.O. can be cost prohibitive. Instead, in each exchange/C.O.,
only ADSL/Ethernet infrastructure is deployed. The supporting layer 3
equipment is located at a more central location, providing layer 3 to
multiple exchanges/C.O.s, over high speed backhaul. Depending on the
size or number of the layer 3 equipment you wish to operate, your
physical geography, and the cost of backhaul bandwidth, the number of
subscribers attached to the same layer 2 segment may number in the many
thousands.

If IPv6 was deployed "natively" over the ADSL/Ethernet backhaul in this
scenario (i.e. a multi-access segment, rather than an engineered
point-to-point one a la. PPPoE), you then have 1 or more likely 2
service provider routers (with e.g. VRRP), and potentially a large
number of downstream subscriber routers, a.k.a. CPE, with /48s
or /56s behind them.

The provider routers will have static routes pointing towards the
subscriber CPE for the /48s / /56s, while the subscriber CPE will have
a default route towards the provider routers.

With the potential for 1000s of subscriber CPE being layer 2
neighbours, as well as traffic having to be hair-pinned offsite for
inter-subscriber traffic, an optimisation would be to have the
subscriber CPE aware of it's on-link neighbour CPE's downstream
prefixes. This would reduce latency for that traffic, reduce required
backhaul bandwidth, and eliminate the hair-pinned traffic from entering
and leaving the provider routers, helping to increase the number of
subscribers who could be attached to this domain.

All the current methods I can think of that could be used to achieve
this optimisation have scaling and/or trust limitations:

- static routes in the subscriber CPE requires excessive operational
  overhead, and if subscribers own the CPE (which is the common
  situation here in .au), you're probably asking Mums (moms) and Dads to
  be (trusted) network operators, entering 100s or 1000s of static
  routes.

- dynamic routing is unlikely to be able to cope with the number of
  neighbour adjacencies it has to maintain, and if subscribers own the
  CPE, again they probably need to be network operators. The number of
  prefixes being distributed via the dynamic routing protocol may also
  be beyond the capabilities of the typical IGPs and the CPE CPUs that
  it's running on.

- possibly RAs with the route information option could be traded
  between the subscriber CPE and provider routers, however that would
  require inter-router RA support, and also would possibly encounter
  some of the trust and scaling issues that using traditional dynamic
  routing protocols would.

It seems to me that something like a prefix redirect, sent from the
provider routers to the subscriber CPE when traffic is to be
hair-pinned, would be a better solution. It retains the
topology authority that the provider routers have over the the segment,
avoids subscribers having to become network operators, and because it
is reactive to traffic flow, is, with appropriate controls e.g.
per-CPE rate limits on generation, more scalable than the proactive
dynamic methods like an IGP.

I started working on a draft a few weeks ago to propose this. It seems
that there might be overlap with Fred's draft, which is why I suggested
that it could a scenario that could be addressed in his.

Regards,
Mark.

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 1 Dec 2009 15:45:14 -0800

Hi Thomas,

> Sent: Tuesday, December 01, 2009 1:54 PM
> To: Templin, Fred L
> Cc: [email-masked]

OK.
 
> stub networks considered part of the same site (i.e., same company,

In my picture, each stub network is a separate site.
The NBMA link and all of its attached devices is also
a separate site, so the provider-facing interfaces of
all of the stub routers in the diagram are connected
to the same site. (This is not to say that stub
network "sites" cannot be multi-homed; they certainly
can, but the drawing does not show examples of that
in order to avoid excessive clutter.)
 
> What is the internal structure of those networks (or does it matter)?

It doesn't matter.

> network. Are there only "normal" routers internally?

Normal routers and links, yes. But, each stub network
could itself contain multiple internal NBMA links which
would appear to be sites within themselves (or, "sites-
within-sites"). Each of those "sub-sites" would have
a set of default routers and a set of routers that
appear as stubs within that site. In other words,
the model is recursive.

> Can a "stub" router only exist on the NBMA link?

Do you mean, are NBMA links the only examples where
one would find stub routers? I don't think so, but
NBMA links are peculiar and may present challenges
to ordinary routing protocols that are not as
prevalent on "ordinary" links.

> operated by the Provider?

One example is an ISP network that connects multitudes
of CPE routers (i.e., stub routers) with a finite
collection of gateways via IP-in-IP tunneling. ISATAP
is an example NBMA link type that could be used in
such networks.

> have routers on it, with all hosts being behind a router.)

Take ISATAP for example. The hosts configure tunnel
endpoints that connect to the ISATAP "link". Any
device that supports ISATAP can connect to the
NBMA link in this fashion, e.g., if there is no
way for the host to connect behind an "ordinary"
router.

>    like this? Maybe they shouldn't do this and there are better

There are a wide variety of use cases; 'draft-rangers-russert'
lists many of them.

>    operating a network like this...

I'm afraid I didn't understand this; the hosts will discover
default routes in the same way that the stub routers will.
ISATAP is an example of a mechanism that provides for hosts
to discover the unicast addresses of default routers.

Fred

---

From: Bob Hinden <[email-masked]>
Date: Tue, 1 Dec 2009 16:14:12 -0800

Fred,

Why not just use OSPF?  It already supports NBMA networks and is widely supported by existing routers.  Adding complexity to ND to solve what sounds like a routing problem seems to me like the wrong way to go.

Bob

On Dec 1, 2009, at 3:45 PM, Templin, Fred L wrote:

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

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 1 Dec 2009 17:09:03 -0800

Bob,

> From: Bob Hinden [mailto:[email-masked]]
> Sent: Tuesday, December 01, 2009 4:14 PM
> To: Templin, Fred L
> Cc: Bob Hinden; Thomas Narten; [email-masked]
> Why not just use OSPF?  It already supports NBMA networks and is widely supported by existing
> routers.

On the sorts of NBMA links I am concerned with (ISATAP being
the primary example), it may be impractical to involve great
multitudes of routers in a single OSPF instance. For instance,
in ISATAP applied to ISP networks it might be possible for
hundreds or thousands of CPE routers that don't know about
each other to engage in a routing protocol instance with a
set of well-known default routers in the provider network
and thereby discover one another. But, it might not scale
well, and it might not allow for secure exchanges between
CPE routers that must consult with 3rd party trust anchors
within the ISP network before they can communicate with each
other directly.  

> Adding complexity to ND to solve what sounds like a routing problem seems to me like the
> wrong way to go.

It is solving a routing problem without a routing protocol
by taking the ISATAP host-to-router model and extending it
to apply also to router-to-router. It leverages the concept
of the ISATAP link and the operation of IPv6 Neighbor
Discovery over the ISATAP link. 

Router-to-router tunneling is something that was left as
out-of-scope when RFCs 4214 and 5214 were published; I am
now working to address router-to-router tunneling through
a new document that would update RFC5214. Part of this is
how routing would work, and the other part is how ingress
filtering can be asserted so that packets that come from
a router that is not authorized to send them can be dropped.

Thanks - Fred
[email-masked]

---

From: Bob Hinden <[email-masked]>
Date: Tue, 1 Dec 2009 17:37:33 -0800

Fred,

In my personal view, I think you need to really investigate what can be done with OSPF.  There is a lot of experience with it and how it scales and there is real experience with OSPF on real NBMA networks.  It is an existing well known solution.

If the real focus of this is large deployments of ISATAP across thousands of routers, I think you need to provide some evidence that this is a real problem in some real deployment.  Also, why would someone want to use ISATAP in an environment like that?  Native or point to point tunnels seems a lot simpler to me.

With my w.g. chair hat on:  If you are trying to turn ND into a routing protocol (for ISATAP), then then is very likely out of scope for the 6man w.g.  This is not maintenance.

Regards,
Bob

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 02 Dec 2009 16:18:11 +1300

> a separate site,

Fred, can you explain what NBMA technologies you are thinking
of? I think we successfully proved that ATM is not a viable
access technology precisely because it creates the NBMA problem,
so I'm wondering why we are trying again to solve this problem.

As Mark Smith pointed out, the ADSL ISPs have adopted (or rather,
cobbled together) a hub and spoke solution for legacy reasons:

>> PPPoE makes
>> authentication/billing systems etc.

But at least that solution is clear.

Incidentally, we have existing terminology for distinguishing a particular
router on a subnet: the 'designated router' in OSPF. As I understand, it's
the only router on the subnet allowed to send Link State Advertisements.
Is your 'authoritative' router comparable to that? In what way does OSPF
not match your problem?

    Brian

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 2 Dec 2009 10:32:40 -0800

Hi Bob,

> Sent: Tuesday, December 01, 2009 5:38 PM
> To: Templin, Fred L
> In my personal view, I think you need to really investigate what can be done with OSPF.  There is a
> lot of experience with it and how it scales and there is real experience with OSPF on real NBMA
> networks.  It is an existing well known solution.

OK; clearly the consensus based on what you and others are
saying is that when OSPF (or some other IGP) can be used, it
should be used. That would not be inconsistent with what I
have written in the other documents I have been working on,
but it definitely needs to be called out more explicitly as
the preferred method for navigating an NBMA link. I can fix
that, and I will note these discussions for historic record.
 
> If the real focus of this is large deployments of ISATAP across thousands of routers, I think you
> need to provide some evidence that this is a real problem in some real deployment.  Also, why would
> someone want to use ISATAP in an environment like that?  Native or point to point tunnels seems a lot
> simpler to me.

I want to be able to turn up IPv6 in an IPv4-only network in
a manner that is as consistent as possible with the principles
identified in the Introduction of RFC1955:

      - No Changes to Hosts
      - No Changes to Most Routers
      - No New Routing Protocols
      - No New Internet Protocols
      - No Translation of Addresses in Packets
      - Reduces the Routing Table Size in All Routers
      - Uses the Current Internet Address Structure

I believe this can be done using an update to ISATAP that
enables router-to-router tunneling.

> With my w.g. chair hat on:  If you are trying to turn ND into a routing protocol (for ISATAP), then
> then is very likely out of scope for the 6man w.g.  This is not maintenance.

OK, I accept this and I think it answers my question as to
whether work on using ND as a routing protocol should be
addressed in a 6man document or in an "IPv6-over-(foo)"
document. It seems like it should be the latter if any
further work on this is to be done.

But looking strictly from a maintenance perspective as a
separate question, there still seems to be a class of devices
that are routers (i.e., that forward packets not addressed to
themselves) but that should either not send RAs at all or
should be very careful about the information they include
in RAs so as not to be inconsistent with the information
advertised by other routers on the link. The diagram I
cited in an earlier message shows a case where this is
true, and applies not only to NBMA links but also to any
other sort of shared link (multicast or non-multicast).
This question has come up in MANET discussions also, to
name one other venue.

Can we have further discussion in 6man as to when it is
appropriate for routers to send RAs and when it is not?

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 2 Dec 2009 11:35:24 -0800

Hi Brian,

> Sent: Tuesday, December 01, 2009 7:18 PM
> To: Templin, Fred L
> Cc: Thomas Narten; [email-masked]

The primary NBMA technology I am thinking of is ISATAP/VET.
To Bob's point, though, I am coming around to the point of
view that if OSPF or some other IGP can be used then it
probably should be used. If it cannot be used for some
reason, however, then the alternatives are to fashion
either a hub-and-spoke or mesh approach. 

> But at least that solution is clear.

ISATAP/VET can do hub-and-spoke by having stub routers
discover a well-known set of default routers on the link
via the Potential Router List discovery mechanisms. Then,
the stub routers can forward everything via a default
route even if the default router is only going to hairpin
the traffic back into another stub router on the link. 

ISATAP/VET can do mesh by having the default routers
send router-to-router redirects as we have discussed.
Then, stub routers can forward traffic directly to
one another while eliminating the dogleg.
 
> Is your 'authoritative' router comparable to that? In what way does OSPF

What I am calling 'authoritative' router is one and the
same with what ISATAP calls a Potential Router List (PRL)
router; they can advertise "default" and provide default
routing services for forwarding packets off the link.

To my understanding, however, the OSPF designated router
and backup designated router are not necessarily one and
the same as an authoritative/PRL router. For example, I
do not think it is necessary for an OSPF router to provide
default routing services in order for it to become an OSPF
designated router.

Fred