Barbara,

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?

the problem with static routes as you suggest here is just that, that they are static. a dynamic routing protocol would handle convergence, loops. with RFC4191 or DHCPv6 static route option there is no way for the owner of that prefix to signal that the route is no longer available.

Markus and I have an expired draft going in more detail on DHCP PD route injection here:
http://tools.ietf.org/html/draft-stenberg-v6ops-pd-route-maintenance-00
even though it is mainly focused on PD across a administrative boundary. in the home network the security issue of having the requesting router advertise the route doesn't exist.

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

if a multi-homed host should participate in routing? possibly... but should we leave that for another day?

cheers,
Ole

Attachment: smime.p7s
Description: S/MIME cryptographic signature

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to