IPv6 news

Jeroen Massar jeroen at unfix.org
Fri Oct 14 15:18:10 UTC 2005


On Fri, 2005-10-14 at 10:57 -0400, Joe Abley wrote:
<SNIP>
> Are you suggesting that something else is required for ISPs above and  
> beyond announcing PI space with BGP, or that shim6 (once baked and  
> real) would present a threat to ISPs?

There is one situation which is not really covered here, one can of
course announce multiple de-aggregates, but, these will be filtered.
As such announcing them will only hurt one a lot, as the 'transits'
that do carry them are mostly of bad quality.

eg take the following situation:

Big ISP, or a large corporate network, spread around the world. >200
customers and so, thus they can easily get a IPv6 prefix from their
favourite RIR. Thus they get, say a /32.

Now this ISP has a large webfarm in the US. They have a very small one
in say, Taiwan. In IPv4, this would mean: chunk up your PA and simply
announce them in /20's or whatever is comfortable for you. In IPv6
though, one is not supposed to announce chunks out of the /32, also when
you do, as mentioned above, one gets bad routing.

Anyway, you don't want your farm in Taiwan to attract all the local
(complete asia?) traffic, which you have to ship over that same small
link or your internal network in taiwan to the US again, while in IPv4
others would be doing that.

In this case, which is basically "traffic engineering for endsites with
a global prefix", one runs into the shim6 thing again....

For instance UUNET 'solved' this in a different way, they simply
requested a 10 or so separate /32's. See GRH for the list.
These chunks are still /32's thus only <n> of these /32's can exist in
the global routing table. It would still be 'nicer' if they only had to
use one prefix...

Greets,
 Jeroen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 240 bytes
Desc: This is a digitally signed message part
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20051014/47548787/attachment.sig>


More information about the NANOG mailing list