Re: Comments on IPv6 Prefix Subdelegation

On Jul 29, 2009, at 11:03 PM, Stark, Barbara wrote:
> 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?

Um, what does a router do? Look at the example in the text and ask  
yourself if you want an average user (my canonical "average user"  
being my daughter, who wanted me to come to her house to install a  
camera on her computer so she could use it on Skype - "did you try  
plugging it in?") manually installing routes in each of the four  
routers when they could in fact learn them from each other directly?

> There shouldn't be misdirected traffic, if the routes are known to  
> downstream devices.

Not so. First, communications are not limited to accesses to systems  
outside the SOHO - music, for example, is often an access to a server  
in the home. Second, the fact that a datagram was delivered to a  
device in the home via one CPE is no guarantee that its response will  
use the same CPE.

> 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?

... This comes back to my question about manual configuration. If I  
can make it work easily, what is the argument for not doing so?

> 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)?

That gets into a much larger discussion. Willing to go there, but  
that's beyond this draft.

> 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
>> --------------------------------------------------------------------