Multi-6 [WAS: OT - Vint Cerf joins Google]

Iljitsch van Beijnum iljitsch at muada.com
Mon Sep 12 10:58:03 UTC 2005


On 12-sep-2005, at 4:55, Matthew Petach wrote:

> > And no, multiple IP addresses is not good enough.

> What requirements do you have that are fundamentally incompatible
> with using multiple addresses?

> How would a default-free content provider with 1000+  peering sessions
> be handled?  Would they be treated as an ISP, even though they have no
> downstreams, and get PI space?

There are a few corner cases that fall through the cracks in today's  
policies. A content network like you describe would be one, a transit  
ISP with customers that all have their own addresses would be  
another: where would they get the IPv6 addresses to number their  
routers?

However, the number of such networks is so incredibly small that  
whatever happens to them is completely insignificant with regard to  
scalability. Still, we need a decent policy for these cases, and JUST  
these cases but not random people who'd also like a /32.

> Or would you expect them to get prefixes from every peer they have,  
> and configure several hundred IP addresses on each server?

Getting address space from a peer doesn't make much sense. But  
99.999% of all content networks have 1 or more ISPs that they can get  
address space from and then announce to any peers.

> I'll be blunt.  As long as that question is up in the air, none of  
> the major content providers are going to do anything serious in the  
> IPv6 arena.

Well, I have no evidence of them doing anything with IPv6 anyway, so  
I don't know if this makes a difference.

The whole point of IPv6 is that we have a technology that will allow  
our networks to grow for decades to come. Importing IPv4 mistakes  
defeats the purpose.

> ACLs are already enough of a hassle with one
> IP address per host.

Ok, let's see... which is more important to keep the internet  
running, a routing table that fits in our routers, or acl monkeys  
that get to go home at 5?



More information about the NANOG mailing list