Op 23 okt. 2012, om 19:19 heeft mike het volgende geschreven: > On 10/23/12 9:56 AM, Teco Boot wrote: >> Op 23 okt. 2012, om 17:20 heeft Michael Thomas het volgende geschreven: >> >>> On 10/22/2012 08:35 PM, Lorenzo Colitti wrote: >>>> On Tue, Oct 23, 2012 at 4:18 AM, Michael Thomas <m...@mtcc.com >>>> <mailto:m...@mtcc.com>> wrote: >>>> >>>> No, sorry. Corporate VPN's using v6 and the lack of a coherent source >>>> address selection mechanism causes breakage in bizarre and unpredictable >>>> ways. You are not going to get the results you hope for if your mac uses >>>> an ISP prefix to get back inside the corpro firewall, uRPF if nothing >>>> else. SLAAC changes a lot of things over v4. >>>> >>>> >>>> VPN clients already modify the routing table to ensure traffic going >>>> through the VPN goes through the VPN, to enforce policies around split >>>> tunneling, and so on. Mine even monitors the routing table for changes so >>>> it can act on them. >>> Routing is irrelevant. >>> >>>> Can you explain why this behaviour, combined with the "prefer matching >>>> interface" rule in RFC 3484, is not sufficient? If not, then there is no >>>> problem to solve here. >>> Your ISP gives you 2001:xxxx:: via SLAAC. Your employer gives you 2000::, >>> but also has 2001:yyyy::. You connect to a server on 2001:yyyy::. Your >>> 3484 v6 stack picks 2001:xxxx for the source address. Hilarity ensues: >>> >>> 1) the packet gets rejected via uRPF >>> 2) the return packet splats against the inside firewall since it's not >>> allowed outside >>> 3) the packet makes it outside unarmored with sad faces from the security >>> team >> Employer should also provide 2001:yyyy::. Or make server accessible via >> Internet. >> BRDP will handle this scenario nicely, also for existing hosts. >> > Presumably, the reason it's behind the corpro firewall is because they don't > want it accessible to the internet at large. OK.
> I'm not sure if giving each host a > prefix in 2001:yyyy's address space is scalable either for the hosts, the > SLAAC > announcements, or just carving up 2001:yyyy's addresses, especially if you > have > a large VPN population. I've done that myself, and I have doubts that it's the > right approach. I can't get why employer doesn't assign a 2000:: address to the server, other than test uRPF filters and get protocol designers crazy :-) Teco > > Mike > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
