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 bemisdirected traffic, if the routes are known to downstream devices. Or is it the home/office RTRs (Fig 3) who need to know which prefixes havebeen assigned to each other, advertising on their WAN interfaces? It seems like if the home/office RTRs don't know about each other, itdoesn'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 thenit'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-00even 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, becausehosts 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
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 --------------------------------------------------------------------