Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd)

[Mark ZZZ Smith <[e-mail]>]

>________________________________
> From: Owen DeLong <[e-mail]>
>To: Mark ZZZ Smith <[e-mail]> 
>Cc: Andrew Yourtchenko <[e-mail]>; Bernie Volz (volz) <[e-mail]>; "[e-mail]" <[e-mail]> 
>Sent: Monday, 9 December 2013 4:20 PM
>Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd)
> 
>
>
>Technical people like choice and flexibility, because I think they think about "what ifs" - "what if I was in this situation, what if I was in that situation, and what would I like to tweak to make it work." Non-technical end-users (usually our customers or at least our relatives), who far surpass us in numbers, don't care, shouldn't care and shouldn't have to care. They just want it to work, work reliably, and don't want to have to engage technical people to either make it work or call in assistance if it doesn't work or stops working. Choices, options and parameters make things more complex and therefore more fragile and less robust.
>>
>
>I don’t mind the flipper door, but I really hate it when people remove all the knobs. (The non-technical users shouldn’t open the flipper door).
>


The knobs are still there, they're called static configuration.

>
>We currently have a single mechanism to announce a default gateway, and the default gateway announces itself, out of the box. That makes it pretty hard, if not impossible for that information to be wrong. DHCPv6 for default gateways would in the DHCPv6 relay scenario would require human entry of that information, creating the opportunity for human error, and potential conflict with what RAs are announcing.
>>
>
>It’s not hard at all. All you have to do is put a router on the network that is connected away from, instead of towards the internet and voila, you have arguably “wrong” RAs.
>

If I understand your scenario, the RAs are right, it is the route table in the router that is broken (or rather, the upstream network is partitioned). I don't see how putting default router information in DHCPv6 is going to prevent the same problem, or lessen the effects of it. Chances are it might increase the likelihood of issues, because it is one more thing for humans to get wrong when they enter it into their DHCPv6 server.

However, this discussion is only about how hosts learn their default gateway/router information, not whether once the packets make it to the router they can be forwarded by the routing domain to their destination successfully.

>
>This won’t usually break anything because redirects usually work and even if they don’t, you just put unnecessary load on the network and the router that can’t forward the packets. However, if that router doesn’t know the correct address for the other routers, then your RAs will be truly wrong and things do break.
>

There are a few ways of resolving this.

Firstly, the routers on the link could be trading routing information using e.g, OSPF via the link the hosts are attached to if that is the only way the two separate upstream networks are interconnected.

Secondly, one of the routers could have a High RA preference (RFC4191), and then that router has static routes towards the prefixes behind the other routers. Having the other routers continue to announce lower preference RAs means that if the High preference router fails, hosts still have a level of reachability to the prefixes behind the remaining routers.

Finally, some level of routing information could be pushed to the hosts so they pick the correct first hop router. RAs support providing this information via the Route Information Option (RFC4191).

There are VRRP options too, however I've limited the above to what can just be done with RAs.

Regards,
Mark.