On 10/23/2012 11:01 AM, james woodyatt wrote:
On Oct 23, 2012, at 08:20 , Michael Thomas <m...@mtcc.com> wrote:
On 10/22/2012 08:35 PM, Lorenzo Colitti wrote:
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:
My IPv6 stack doesn't pick a 2001:xxxx:... address. When the VPN client
connects, it inserts a more-specific host route to 2001:yyyy::/z via the VPN
pseudo-interface, so the IPv6 stack picks the interface address assigned by the
VPN access concentrator as the source address for application flows to the
2001:yyyy:/z network.
Hilarity does not ensue. Happy faces on the security team.
As I alluded to in my previous note, this doesn't work unless the vpn is
terminated in host devices. When it's router-router, it fails as I mentioned
because the hosts are clueless. I expect that walled off overlay networks
will be more rather than less prevalent in v6, especially when homenets
are truly visible -- though access controlled -- from the outside which is
pretty untrue today with v4/nat.
Mike
_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
