Hi Margaret, I realise this is could be bit off topic, although I think it may help as it shows how Wind River could solve the multiple "site-local" addressing issue.
Wind River could set up a permanent IPsec VPN between the firewalls at the Internet connections at each of their geographical sites, and then weight the routes in the IGP to prefer the internal leased lines. This would allow the whole organisation to be considered part of the same "site-local" site, and therefore numbered out of a single site-local addressing instance. If any of the leased lines fails, the internally disconnected site is still part of the "site-local" site, due to the VPN. Alternatively, all geographical sites could still be considered part of the same "site-local" site (as the leased lines suggest), and then the VPN concentrator she connects to hands out a site-local prefix that is unique within the organisation's single site-local addressing instance ie. if a leased line fails, Margaret connects via her VPN client, through which her PC re-gains membership of the organisation's single "site-local" site. This client VPN option is a bit complex though, Margaret's PC now needs to know what "site-local" prefixes are at the end of the IPsec tunnel vs which site-local prefixes are locally attached via her LAN interface. However, VPN concentrators today can usually push static routes to their clients, indicating which destinations are at the end of the tunnel, relying on the default route for directly attached, local destinations, and Internet destined traffic. Hmm, this option could be a bit more complicated than I think. From the hosts and routers view point, the site-local site is partitioned. But from Margaret's PCs view point it isn't. I can't think of an application that does this off the top of my head (maybe a peer to peer app of some sort), but if Margaret's PC referred one of the local devices to a site-local address at the end of her tunnel, the local device wouldn't be able to see it, unless it had its own client VPN tunnel. Creating a VPN between the Internet firewalls looks to be the simpler solution. Wind River could even save money by using redundant Internet connections for each geographical site, and decommissioning their leased lines. Actually, as IPsec is a mandatory part of IPv6, I would suggest using IPv6 IPsec VPNs to replace internal leased lines will eventually become very common. Does IPsec VPN tunnels / logical links influence any of the current site-local discussions ? Mark. On Sat, 2002-11-09 at 10:27, Margaret Wasserman wrote: > > > > >What rule is that? Is the routing within Wind River "convex"? Assuming > >it is, I don't see why you wouldn't make Wind River a single site, even > >if it is geographically dispersed. > > Wind River has multiple sites with Internet connectivity that > are connected via linked lines. If you think of two of them, > you can picture a dumbbell shaped network. Our ISP is routing > different parts of the Wind River network space to different > locations. > > In this configuration, the preferred path for global traffic > between the two locations is to go over the leased line. This > keeps the traffic inside the firewall, etc. > > However, if the leased line goes down (or one of the routers to > it goes down, etc.), global traffic will fall-back to being routed > over the global Internet... This is great because it lets me > reach non-secure parts of the other Wind River site, even when my > secure link is down. And, I can run a client VPN solution to get > behind the firewall, if I need to. > > However, this fallback route breaks the concept that the site > needs to be "convex" at the global scope. So, I need to have > my two locations be two different sites. This has been discussed > a few times on the IPv6 list before. > > So, I need to have two sites. I'm not wild about that, but it > is required by our current scoped addressing architecture. > However, I am not require to number those two sites from different > /48 address allocations... And, if I change ISPs, I will need to > renumber the entire network. > > Margaret > > > > > > > -------------------------------------------------------------------- > 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] > -------------------------------------------------------------------- -------------------------------------------------------------------- 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] --------------------------------------------------------------------
