Op 25 okt. 2012, om 18:30 heeft Michael Thomas het volgende geschreven: > 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.
More thoughts on this scenario. Assume the company has many branch offices (e.g. 1000 small sites, with 2001:xxxx::/48 from ISP), where main office has 2000::/48. Each branch office is equipped as a homenet, the gear is cheap and just acts as the requirements. It provides Internet access and VPN to main office and indirect to all other branches. Branch office managers set up their homenet equivalent to the branch offices. This doubles the number of VPN tunnels. For Internet access, nodes on branch offices / homenet configure a 2001:xxxx:0:mmmm::/64 address. Main office nodes configure 2000:0:0:nnnn::/64. We better not send 2000 routes during VPN tunnel setup, for access to main office and each branch office / homenet. We better configure a 2nd address on nodes in the branch offices / homenets, for connectivity to nodes in main office or branch office / homenet. VPN tunnel provides a 2000:0:0:zzz0::/60 prefix to each branch office / homenet and nodes configure an additional 2000:0:0:zzzz::/64 address for access via VPN. Routing shall forward packets with destination inside the site based on destination address. For packets outside, routing shall use the source address. Source addresses in 2001:xxxx::/48 are send to ISP, source addresses in 2000:0:0:zzz0/60 are send via VPN tunnel. IGP / VPN servers in main office may have to handle a bench of prefixes, prefix handling on tunnels is kept low. On source address selection, nodes prefer a 2000:0:0:zzzz::/64 for destinations within the company, 2001:xxxx:0:mmmm::/64 for elsewhere. Is this the model we have in mind? How can source address selection pick the 2001:xxxx:0:mmmm::/64 address for a destination out of 2000::/16, but not 2000::/48? This is a MIF problem. Use RFC 6724 policy table Label? Supersede Rule 8? Now, company acquires another and 2001:yyyy::/48 is connected to the main office. Branch offices / homenets wants to connect to a 2001:yyyy::/48 address via the VPN. I see multiple options: a) circumvent problems: first renumber acquired company to 2000::/48 b) push a 2001:yyyy::/48 route on VPN tunnels c) add another VPN prefix on all branch offices / homenets for 2001:yyyy::/48 Option a is the preferred solution, let's pass this to 6renum. Homenet protocols may help. Option b makes branch office / homenet IGP more complicated due to route redistribution, source address selection and ingress filtering. Option c makes VPN stack more complicated, due to assignment of multiple prefixes. NPT66 & happy eyeballs could help. But IMHO these are hacks. Opinions? 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
