Thomas, > -----Original Message----- > From: Thomas Narten [mailto:nar...@us.ibm.com] > Sent: Tuesday, December 01, 2009 6:10 AM > To: Templin, Fred L > Cc: ipv6@ietf.org > Subject: Re: New draft on "Stub Router Advertisements in IPv6 > NeighborDiscovery" > > "Templin, Fred L" <fred.l.temp...@boeing.com> 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).
OK - I guess I probably should have said "it needs to somehow discover one or more default routes". > > 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. 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 > 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. 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. > > 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? I meant to say: "the stub router may need to advertise its prefixes to other routers". > Yes, all routers somehow need to be configured to know what prefixes > 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. > > 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. 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. > But some vague notion of "excessive control overhead" does not come > 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. > > 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. Well, maybe that means we should just address this in any "IPv6-over-(foo)" documents that deal with the specific links? > > 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. 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 fred.l.temp...@boeing.com > Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
