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
