Barbara, Consider the following as well to facilitate route injection:
http://tools.ietf.org/wg/dhc/draft-ietf-dhc-dhcpv6-agentopt-delegate It enables route injection into a provider network absent the need for a dynamic routing protocol. Additionally, if the router at the edge of the home network is sub-delegating it is conceivable (perhaps certain) that it is aware of the routing topology in the home. It should at least be aware of all the next hops, right? We also need to consider what, if any, inefficiencies this introduces in the home network. I think you mention this below, if one of the sub-delegated routers need to forward packets within the home it will use its default route, punt to its northbound router which in turn should have all the necessary routing information. Does this seem logical? John ========================================= John Jason Brzozowski Comcast Corporation e) mailto:[email protected] m) 609-377-6594 ========================================= > From: "Stark, Barbara" <[email protected]> > Date: Wed, 29 Jul 2009 17:03:34 -0400 > To: Fred Baker <[email protected]>, "Azinger, Marla" > <[email protected]> > Cc: <[email protected]>, > <[email protected]>, IETF IPv6 > Mailing List <[email protected]> > Subject: RE: Comments on IPv6 Prefix Subdelegation > > I'm sorry if the following questions show my ignorance, but, here > goes... > > Why does it need to be a dynamic routing protocol? Why not a simple > configuration protocol, like with RFC 4191 or a DHCPv6 option as > suggested in > http://tools.ietf.org/html/draft-dec-dhcpv6-route-option-01? > > Why do the peered routers (such as CPE RTR 1 and 2, in Fig 3) need to > know which routes other routers claim to serve? There shouldn't be > misdirected traffic, if the routes are known to downstream devices. Or > is it the home/office RTRs (Fig 3) who need to know which prefixes have > been assigned to each other, advertising on their WAN interfaces? It > seems like if the home/office RTRs don't know about each other, it > doesn't really hurt efficiency that much; it'll still work. They'll send > the messages up to the next hop (CPE RTR) serving that prefix, and then > it'll get routed down to the right home/office RTR. > > If peered CPE RTRs do need to know each others' routes, why can't they > get it through an RFC 4191 or DHCPv6 method (this would be on the LAN > interface). I realize that there are those who say it's wrong for them > to solicit (RS or DHCPv6) on their LAN interfaces -- but why is it > wrong? > > And don't these routes need to get propagated down to the hosts, because > hosts may individually have multiple interfaces (e.g., smartphone with > Wi-Fi and 3G)? > Barbara > >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] On Behalf > Of >> Fred Baker >> Sent: Wednesday, July 29, 2009 6:05 AM >> To: Azinger, Marla >> Cc: [email protected]; > draft-donley-ipv6- >> [email protected]; IETF IPv6 Mailing List >> Subject: Re: Comments on IPv6 Prefix Subdelegation >> >> >> On Jul 29, 2009, at 10:35 AM, Azinger, Marla wrote: >> >>> Routing in such an environment calls for a routing protocol. Each >>> CPE must run either RIPv6 [RFC2080], IS-IS [RFC5308], or OSPF >>> [RFC5340] on a default route and to the homes interal upstream a >>> static default route. The issues raised in [RFC3704] also apply, >>> meaning that the two CPE routers may each need to observe the source >>> addresses in datagrams they handle to divert them to the other CPE >>> to handle upstream >> >> I'll figure something out there. This makes it sound like only the CPE >> routers have to run a routing protocol; in fact, all of the routers in >> the home have to run a routing protocol. But yes, something like that. >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> [email protected] >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
