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

[Owen DeLong <[e-mail]>]

On Dec 9, 2013, at 2:41 AM, Mark ZZZ Smith <[e-mail]> wrote:

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

I didn’t mean to imply that the knobs weren’t there. Indeed, RAs have a very large number of knobs for such a lightweight protocol and DHCPv6 has even more.


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

No, the route table in the router is not broken, it just doesn’t have a default route to the upstream routers. There are a number of situations where this could even be desirable (for example, the systems on the back-end network behind this third router are not supposed to send/receive from
networks beyond the LAN in question).

I’m not saying that it does. I’m saying that RAs from routers don’t necessarily guarantee that the routers are telling the truth. Not all routers are valid default route candidates.

However, the current IPv6 implementations seem to assume that they are.

The point is that while RA can be easier and more reliably accurate than routing information from DHCPv6 in many scenarios, this is not necessarily always true. Adding the equivalent of RIOs to DHCPv6 would be harmless to those who wish to use only RAs while allowing operators to choose the solution that works best for them.

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

Yes, but if hosts are learning default routers that aren’t good candidates for that function, one could make the argument that such a scenario is not desirable.

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

Which results in the redirects and hair pinning described in my paragraph you are claiming this solution resolves.

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

Which takes you back to fiddling knobs and the potential for human error in the configuration process.

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

Which also requires fiddling the knobs and re-inserting the potential for human error.

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

I wasn’t trying to put this forward as an insurmountable problem. I was just pointing out that RAs are not a panacea solution to all possible problems associated with routing information from DHCP.

Owen