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-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf
Of
Fred Baker
Sent: Wednesday, July 29, 2009 6:05 AM
To: Azinger, Marla
Cc: draft-ietf-v6ops-ipv6-cpe-rou...@tools.ietf.org;
draft-donley-ipv6-
cpe-rtr-use-cases-and-r...@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
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
