RE: IPv6 Allocation Policy
"Michel Py" <michel-nyboWHt8SIrJRljzj3WzodHdOEOI8IWic20RSKp2L0g@public.gmane.org>
| Newsgroups | gmane.org.apnic.global-v6 |
|---|---|
| Message-ID | <963621801C6D3E4A9CF454A1972AE8F504F812@server2000.arneill-py.sacramento.ca.us> |
Pekka, >> Pekka Savola wrote: >> would use a company, globe-wide /32 address, would >> advertising the /32 in all the locations be a problem? > Craig A. Huegen wrote: > Yes, it would -- if a user on the east coast of the US > downloads something from Australia, why should we bring > that traffic onto our network in Australia, then pay > another (very expensive) provider to haul it over the > private WAN to the east coast of the US? Isn't that > what I pay ISP's to do locally? Yep. In the end, a specific announcement being filtered and sending the traffic to a different entry point than it should have results in paying three times transit for the traffic: - Granted, transit has to be paid once. Then, if the ingress traffic comes to the wrong location, there are two ways. 1. Backhaul the ingress traffic to the right location (typically not too much bandwidth) then backhaul the egress return traffic to the same point it came in. This allows skipping the replication of firewall state over the WAN, but is 3x the cost: a) 2x: traffic between the server and the egress point: two times. Either this is a private ptp link that typically costs twice as much as transit, or it is a VPN over the public Internet that indeed costs twice the traffic since both the source and the destination pay for transit. b) 1x egress traffic. This has to be paid anyway. The issue is the extra 2x above. 2. Backhaul the ingress traffic to the right location (typically not too much bandwidth) and egress the traffic right at that location. Problem with doing this is that it requires replicating firewall state, which means 100mpbs Ethernet over OC-3 to start with or GigE over SONET for larger setups :-( In any case, way too much money which is why I stated before that as long as there is a risk of filtering long prefixes it is a major issue. Michel. _______________________________________________ global-v6 mailing list [email protected] http://mailman.apnic.net/mailman/listinfo/global-v6