"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). > 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 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
