Hi All, I've put together the following email as a bit of a thought provoker on how organisations may connect themselves together in the future, and how that may effect globally unique site-local use.
Note that I haven't thought out a lot of it thoroughly - it may all be totally bogus, or may be a totally wrong view of the future. |1|. IPsec is free in IPv6, why not use it ? At a certain point in time, IPv6 and the mandatory IPsec component will become prevalent. Presuming most organisations have a public Internet connection, they will be inclined to create IPsec tunnels between each of their geographical sites, rather than commissioning private circuits. As long as the IPsec tunnel over the Internet delivers good enough QOS, organisations will prefer them, as they are far cheaper than dedicated private circuits, even if that IPsec cost included of upping their Internet connectivity bandwidth. An organisation may end up with a large number of point-to-point tunnels, inter-connecting their geographical sites, in any number of arbitrary topologies. However, as the cost of a tunnel is only generally only configuration time, a full mesh tunnel topology is likely to be common. Manual tunnel configuration isn't scalable, but automated tools will be developed to provision these large IPv6 IPsec tunnel based VPNs (they already exist for IPv4 based ipsec). |2|. Overlay networks don't scale very well The problem with overlay or point to point IPsec tunnel VPNs is they cause IGP scaling problems. Because each router in the VPN is now directly connected to the others, running an IGP over the top of it means that each router now has a large number of IGP neighbors (N-1 in a full mesh topology). There are limits on how many IGP peers a router can cope with. This is not a new problem, apparently it has been suffered with IP over ATM based networks [1]. One way to solve this IGP scaling problem is to use traditional IGP scaling techniques - dividing the IGP into areas, introduce ASs and an EGP etc. |3|. A better solution to overlay network scalability is to flatten the network. To avoid the IPsec tunnel scalability problem, you need to get rid of the point-to-point tunnels, so that the routers at the edge of the VPN (or encryption domain) are not direct neighbors. This is similar to what MPLS has done for IP over ATM networks [2]. The routers that are at the edge of the VPN would now peer directly and equally with the upstream Internet gateway via an IGP or EGP. However, the consequence of this is that you cannot use any form of private addressing within the tunnel, as tunnels doesn't actually exist anymore. To still create a virtual network, the local VPN gateway would still need to be able to send traffic to a specific, remote VPN gateway. It also needs to be able to associate destinations with a IPsec Security Association. I imagine this could be achieved by using IPsec in transport mode, in combination with a loose source route extension header, listing the global IP address of the remote VPN gateway in the IPv6 header, and the first hop of the loose source route being the actual destination of the packet. For those familiar with IPsec terminology, I would describe this as a "bump-in-the-wire transport mode pseudo-tunnel". |4|. How does this bump-in-the-wire transport mode pseudo-tunnel VPN effect our proposed globally unique site-locals ? Now that the VPN gateway is peering directly with the Internet gateway via an IGP or EGP, rather than the other VPN gateways, it is not allowed to advertise site-local prefixes to the Internet gateway. Also, similar to BCP 38 - "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", ISPs are likely to drop traffic with site-local source addresses. Which means that all remote communications, to either Internet or VPN destinations, has to use global addresses. Under the above model, GUSLs are still useful, but only when two organisations directly connect or directly merge their physical infrastructure. This may be a rare occurrence, unless they are in adjacent buildings, and they pull an ethernet through a hole in the wall. Bringing up an IPsec tunnel (either todays type of IPsec tunnel, or the above psuedo tunnel model) is likely to be easier, and more popular. |5|. Exceptions, caveats and other notes 5.1 The above assumes that organisations don't immediately deploy true end-to-end, opportunistic transport mode IPsec between nodes. That being said, if they did deploy end-to-end opportunistic transport mode IPsec, they still can't use site-local addressing when communicating over the Internet. 5.2 I've been meaning to look into whether the ipsec working group have done any work on anything similar to my "bump-in-the-wire transport mode pseudo tunnle" ipsec model but haven't got around to it. I've been intending bring this up in that working group if they haven't. I've been a bit busy recently organising an interstate move unfortunately. 5.3 With today's IPsec tunnel model, I would prefer not to have the restriction of not being able to use GUSLs over my IPsec tunnels. Why do we have this mind set that a site is restricted to a geographical location ? This is the only instance I know of where a logical boundary has been defined by the ietf as having a geographical size. OSPF Areas don't, BGP ASs don't, arguably even link locals don't - you can build some really big ethernet segments - I know of at least one vendor who sell GBICs that can drive a 90 Kilometer long piece of single mode fibre. Surely 90 kilometer's would be bigger than a "site". I would prefer to be able to define the size of my "site", and include the "insides" of my IPsec tunnels within that site. 5.4 On the other hand, with my "bump-in-the-wire transport mode pseudo tunnel" ipsec model, there are now technical reasons not to use GUSLs over VPNs. |6|. References [1] and [2] - MPLS: Technology and Applications, by Bruce S. Davie, Yakov Rekhter - can't look up the page numbers, my copy is packed in a box - see point 5.2 above :-) Any thoughts ? Thanks, Mark. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
