Bob, > -----Original Message----- > From: Bob Hinden [mailto:bob.hin...@gmail.com] > Sent: Monday, November 30, 2009 12:15 PM > To: Templin, Fred L > Cc: Bob Hinden; Thomas Narten; ipv6@ietf.org > Subject: Re: New draft on "Stub Router Advertisements in IPv6 > NeighborDiscovery" > > Fred, > > > Have my responses wrt your comments cleared up the concerns > > to the point that this document can be considered as a 6man > > working group item to update RFC4861? > > No, we would have to see more support from the working group before it could > be considered a working > group document. You could ask for a slot at the next IETF meeting if you > wish.
An alternative is that this could be written up in an "IPv6-over-foo" document that might have a more pressing need for what I am calling "stub router advertisements" than would be the case for other IPv6 links. But, two factors that might suggest a standalone document are: - there is a need to procure two new flag bits in Router Advertisement messages - at a minimum, it seems like there should something said about the sort of information that a stub router MUST NOT include in any RAs it sends. In particular, it must not include any information that would override the information advertised by routers that are authoritative for the link. Fred fred.l.temp...@boeing.com > Bob > > > Thanks - Fred > > fred.l.temp...@boeing.com > > > >> -----Original Message----- > >> From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of > >> Templin, Fred L > >> Sent: Wednesday, November 25, 2009 8:47 AM > >> To: Bob Hinden; Thomas Narten > >> Cc: ipv6@ietf.org > >> Subject: RE: New draft on "Stub Router Advertisements in IPv6 > >> NeighborDiscovery" > >> > >> Hi Bob, > >> > >>> -----Original Message----- > >>> From: Bob Hinden [mailto:bob.hin...@gmail.com] > >>> Sent: Tuesday, November 24, 2009 2:52 PM > >>> To: Thomas Narten > >>> Cc: Bob Hinden; Templin, Fred L; ipv6@ietf.org > >>> Subject: Re: New draft on "Stub Router Advertisements in IPv6 Neighbor > >>> Discovery" > >>> > >>> > >>> On Nov 24, 2009, at 11:37 AM, Thomas Narten wrote: > >>> > >>>> Fred, > >>>> > >>>> Can you summarize what problem this draft is aimed at solving? What > >>>> is the motivation for this draft? (I've read it, but I don't > >>>> understand what the benefit of this approach is or what problem it > >>>> solves.) > >>>> > >>> > >>> In the Introduction says: > >>> > >>> A stub router is any router that attaches stub networks to the link, > >>> but does not itself attach the link to a provider network. Here, a > >>> "stub network" could be as simple as a small collection of IPv6 > >>> links, or as large as a complex corporate enterprise network. Stub > >>> routers are said to be "non-authoritative" for the link, since they > >>> cannot themselves provide forwarding services for packets emanating > >>> from their stub networks without using another router on the link as > >>> a transit. > >>> > >>> I disagree with this and don't think that a router that is connected to > >>> an ISP is inherrently > >> higher > >>> priority than other routers. > >> > >> I don't understand this comment. The entity I am calling > >> "stub router" is simply trying to find a way to forward > >> packets on to their final destination using the best > >> possible exit router. There is nothing said or implied > >> about "priority". > >> > >>> This is definitely not true in enterprise networks. > >> > >> This is actually all about enterprise networks; in some ways, > >> an ISP network can be seen as just a special case of an > >> Enterprise network. > >> > >>> We have other ways of doing this in a more general fashion such as > >>> RFC4191 "Default Router > >>> Preferences and More-Specific Routes". > >> > >> Exactly; this document very much expects that stub routers > >> will advertise RFC4191 more-specific routers. > >> > >>> I don't see any need to define "stub routers" and see a lot > >>> of harm doing so. For example, in an enterprise, routing may be setup to > >>> keep the traffic inside > >> of > >>> the enterprise for a long as possible and not use the local ISP > >>> connection. The inter-enterprise > >>> links might be much faster. > >> > >> The way it works is that the stub router may have a default > >> route but may not have a more-specific route to the destination > >> inside the enterprise. It then sends the packet to a default > >> router which hairpins it back to a router within the enterprise > >> that aggregates the more-specific route, but also sends a > >> redirect back to the stub router that originated the packet. > >> The stub router then sends an RA to the enterprise router > >> that aggregates the more-specific route, then subsequent > >> packets flow through the more-specific route and eliminate > >> the dogleg. > >> > >> So yes; packets stay inside the enterprise and do not go out > >> the local ISP connection only to come back in again. > >> > >> Fred > >> fred.l.temp...@boeing.com > >> > >>> Bob > >> > >> -------------------------------------------------------------------- > >> IETF IPv6 working group mailing list > >> ipv6@ietf.org > >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >> -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
