Hi Thomas, > -----Original Message----- > From: Thomas Narten [mailto:[email protected]] > Sent: Tuesday, December 01, 2009 10:18 AM > To: Templin, Fred L > Cc: [email protected] > Subject: Re: New draft on "Stub Router Advertisements in IPv6 > NeighborDiscovery" > > 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).
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 [email protected] > Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
