RA & DHCP problem...

[Phil Mayers]

On 30/12/2013 12:13, Mikael Abrahamsson wrote:

> I am not asking these questions to be mean, I'm asking them to bring out
> all the reasons so someone will document them so they can be presented
> in a coherent consise manner (for instance an I-D). I know I have to do
> this when I want things to change. Been there, done that.

Disclaimer: although I think defgw-in-DHCPv6 would be useful, we run 
SLAAC+RA without too many issues, and my gut feeling is that the IETF 
will never allow standardisation of, nor will vendors engage in 
deployment of, such a protocol in any timescale I care about. So this 
discussion is interesting to me for academic reasons only.

That said: I'll document a specific issue we face in a large-ish 
enterprise-style (UK University) network, which I think RA-less IPv6 
might alleviate/solve.

We run a layer2 edge, layer3 core, and use MAC-based or 802.1x-based 
VLAN assignment to put devices at the edge into different networks, 
which are mapped into different L3VPN. Our edge switches support 
something that's getting pretty common now - "mutiple supplicant" mode, 
where >1 untagged vlan can be present on a port. RX traffic is mapped to 
the right vlan based on source MAC, and TX traffic from all vlans is 
sent to the port, including broadcast/multicast.

(You can probably see where this is going)

This feature is pretty useful because it allows end users in, for 
example, student residences to use a dumb switch on their port, but 
still lets us map the devices into different VLANs, allowing us to catch 
new ones and force them to do a click-through registration, for example.

Other use-cases are VoIP+PC on the same port without LLDP/CDP/other 
"voice VLAN" hassles, or VM guests on separate VLANs to the VM host on 
unmanaged or semi-managed machines.

One problem we have with this setup: If two devices are on a port, in 
different IPv6-enabled VLANs, they both see both RAs, and IPv6 
connectivity breaks.

If however there were no RAs, that would not be a problem. Possibly 
DHCPv6 + defgw would solve that?

Now I can anticipate a number of objections to this, so let me try and 
cover them up front:

1. "That's a terrible architecture it's (insecure | non-standard | blah)"

To be blunt: shove it. That's not your call, it's mine. It works great 
for us (mutiple RAs aside) and has the cost/benefit tradeoff is smack 
bang in the middle of where we, as an organisation, want to be. We're 
aware of its limitations, and don't claim it as perfect. But I know lots 
of other places that run substantially similar setups.

2. "The switch (could | should) intercept and unicast the RAs to the 
correct endpoint MAC"

Maybe; that's a possible solution. In our case, the vendor is 
IPv6-ignorant, and I hold no hope of them ever doing it. But it's 
certainly an option. It does imply a busy CPU on the edge device as the 
number of VLANs/RAs-per-second goes up, and there might be other 
problems I can't think of right now (are there cases where a device will 
process an RA even if it's to a different destination MAC?)

3. "802.1x-REV will solve this as each endpoint will have separate 
MACSEC associations, and not see each others traffic"

Yeeaahhhhh.... maybe, in about 15 years. Seems like it would be nice to 
solve it earlier than that... ;o)

===

Anyway, as I said above - I would have liked to have seen defgw in 
DHCPv6, but we run mostly OK on RA+SLAAC. Since people seem interested 
in having "issues with RA" documented, I thought I'd write this one up.

Thanks all for the interesting discussion (though I see lamentably 
little use of the principle of charity ;o)

Cheers,
Phil