Re: Comments on IPv6 Prefix Subdelegation

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:john_brzozowski@cable.comcast.com
m) 609-377-6594
=========================================

> From: "Stark, Barbara" <bs7652@att.com>
> Date: Wed, 29 Jul 2009 17:03:34 -0400
> To: Fred Baker <fred@cisco.com>, "Azinger, Marla"
> <marla.azinger@frontiercorp.com>
> Cc: <draft-ietf-v6ops-ipv6-cpe-router@tools.ietf.org>,
> <draft-donley-ipv6-cpe-rtr-use-cases-and-reqs@tools.ietf.org>, IETF IPv6
> Mailing List <ipv6@ietf.org>
> 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: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf
> Of
>> Fred Baker
>> Sent: Wednesday, July 29, 2009 6:05 AM
>> To: Azinger, Marla
>> Cc: draft-ietf-v6ops-ipv6-cpe-router@tools.ietf.org;
> draft-donley-ipv6-
>> cpe-rtr-use-cases-and-reqs@tools.ietf.org; 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
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------