RA & DHCP problem...

[Phil Mayers]

On 30/12/2013 14:21, Lorenzo Colitti wrote:

> How are these "different VLANs" if broadcast/multicast packets can pass
> from one to the other?

This only happens in the TX direction, leaving the edge switch. From the 
client PoV, you're right I guess - they are the "same" VLAN.

> Also, it's not secure if all clients get all the RAs for all the VLANs,
> and (in theory at least) can thus just pick the one that works. The

Well, RAs contain both the gateway and prefix info. So "the one" isn't 
quite that simple. For gateways, in theory dead neighbour detection will 
do the job (unless you have a dumb stack that only uses 1 gateway 
grumble NetworkManager grumble). For prefixes...

> objective is to deny Internet connectivity to certain clients, right?

No, the objective is to put different clients into appropriate networks 
- maybe non-university members go out a different default route, or similar.

Denying connectivity is done by denying connectivity i.e. dropping the 
traffic.

> And with that out of the way - are you sure the problem is the default
> route and not the source address? If the switch maps received traffic to

It *is* the source address, correct. Sorry if I was unclear.

> a "VLAN" based on source MAC, then it will receive all hosts's packets,
> so outbound from the hosts should be fine. The problem is that some of
> the outbound packets will have the source address from the wrong "VLAN",
> and thus the replies will go to the wrong place. If that's the case,
> then you don't need to do routing in DHCPv6 for this to work - if you
> want to solve this using DHCPv6, you can do that by using DHCPv6 to
> configure addressing, not routing (which you can already do today).

Good point. But then I have to run DHCPv6-for-addressing with M=1 to 
give the clients VLAN-appropriate source-addresses *in addition* to RA 
for prefix/router info. Which gets us back to "why run two protocols" ;o)

There's also a small but not inconsiderable number of clients that don't 
do DHCPv6 yet; so I'd be locking them out, which is maybe tolerable 
given the alternatives.

And finally, it's been a while since I tested it, but last time I looked 
the DHCPv6 relay in Cisco IOS didn't work in MPLS L3VPN scenarios on our 
platform, as it fails to lookup the next-hop correctly, so right now we 
can't run DHCPv6 (doh!). Which of course makes the whole thing academic 
from our PoV.

> Routing is already fine.

I guess there's a problem with communications from prefixA to prefixB; 
the endpoints will see prefix and on-link info for both, and try to send 
to each other directly but fail? Haven't tested it, but if so, we're 
back to suppressing/demuxing/whatever the RAs (or not doing this entire 
thing).

> Also, mostly for my own curiosity - what will you'll do when everything
> is available over IPv6? Will you disable IPv6 to maintain security, or
> will you stick to restricting IPv4 traffic even though it doesn't really
> do anything useful any more because everything is available over IPv6?

Not sure yet. It may be we have to give up the ">1 vlan" thing and 
forgoe the benefits. Or perhaps DHCPv6 will be widely deployed enough 
that we can force it for addressing without losing too many clients. Or 
maybe we'll have ripped & replaced the entire network by then, and some 
other solution will exist.

At the moment, we're avoiding deploying IPv6 on any VLAN which is likely 
to be on the same port as another VLAN; that's not as hard or 
restrictive as it might sound, but is also not very satisfactory.

I know it's all a bit odd-sounding, but we didn't just roll dice and 
come up with this architecture - it evolved with careful thought over 
many years, and gives us a lot of benefits. It'll be a real operational 
cost when we lose some of them for what seems like a trivial reason 
(gateway and prefix info are flooded at layer2).

OTOH I can see that putting gw+prefix into DHCPv6 just for us is a bit 
overkill... Oh well.