v6 multihoming (Re: The Choice: IPv4 Exhaustion or Transition to IPv6)

Fri Jun 29 15:11:58 UTC 2007

Hi Stephen,

Supose you have STM4 links, ok?
And you have 2G of trafic from your 100000 ADSL customers, ok?
And those STM4 go to 3 dif carriers in USA.
Then, how you advertise only one IPv6 prefix to all and make the 2G go 
trough one STM4 ?

On Fri, 29 Jun 2007, Stephen Wilcox wrote:

steve. >
steve. >Hi Christian,
steve. > I am not seeing how v4 exhaustion, transition to v6, multihoming in v6 and destruction ov DFZ are correlated.
steve. >
steve. >If you took everything on v4 today and migrated it to v6 tomoro the routing table would not grow - actually by my calculation it should shrink (every ASN would only need one prefix to cover its current and anticipated growth). So we'll see 220000 routes reduce to 25000.
steve. >
steve. >The technology we have now is not driving multihoming directly and v4 vs v6 is not a factor there.
steve. >
steve. >So in what way is v6 destroying DFZ?
steve. >
steve. >Steve
steve. >
steve. >On Fri, Jun 29, 2007 at 02:13:50PM +0000, Christian Kuhtz wrote:
steve. >> 
steve. >> Amazink!  Some things on NANOG _never_ change.  Trawling for trolls I must be.
steve. >> 
steve. >> If you want to emulate IPv4 and destroy the DFZ, yes, this is trivial.  And you should go ahead and plan that migration.
steve. >> 
steve. >> As you well known, one of the core assumptions of IPv6 is that the DFZ policy stay intact, ostensibly to solve a very specific scaling problem.
steve. >> 
steve. >> So, go ahead and continue talking about migration while ignoring the very policies within which that is permitted to take place and don't let me interrupt that ranting.
steve. >> 
steve. >> Best Regards,
steve. >> Christian 
steve. >> 
steve. >> --
steve. >> Sent from my BlackBerry.      
steve. >> 
steve. >> -----Original Message-----
steve. >> From: Stephen Wilcox <steve.wilcox at packetrade.com>
steve. >> 
steve. >> Date: Fri, 29 Jun 2007 14:55:06 
steve. >> To:Christian Kuhtz <kuhtzch at corp.earthlink.net>
steve. >> Cc:Andy Davidson <andy at nosignal.org>, owner-nanog at merit.edu,       Donald Stahl <don at calis.blacksun.org>, nanog at nanog.org
steve. >> Subject: Re: The Choice: IPv4 Exhaustion or Transition to IPv6
steve. >> 
steve. >> 
steve. >> multihoming is simple, you get an address block and route it to your upstreams.
steve. >> 
steve. >> the policy surrounding that is another debate, possibly for another group
steve. >> 
steve. >> this thread is discussing how v4 to v6 migration can operate on a network level
steve. >> 
steve. >> Steve
steve. >> 
steve. >> On Fri, Jun 29, 2007 at 01:37:23PM +0000, Christian Kuhtz wrote:
steve. >> > Until there's a practical solution for multihoming, this whole discussion is pretty pointless.
steve. >> > 
steve. >> > --
steve. >> > Sent from my BlackBerry.      
steve. >> > 
steve. >> > -----Original Message-----
steve. >> > From: Andy Davidson <andy at nosignal.org>
steve. >> > 
steve. >> > Date: Fri, 29 Jun 2007 14:27:33 
steve. >> > To:Donald Stahl <don at calis.blacksun.org>
steve. >> > Cc:nanog at nanog.org
steve. >> > Subject: Re: The Choice: IPv4 Exhaustion or Transition to IPv6
steve. >> > 
steve. >> > 
steve. >> > 
steve. >> > 
steve. >> > On 29 Jun 2007, at 14:24, Donald Stahl wrote:
steve. >> > 
steve. >> > >> That's the thing .. google's crawlers and search app runs at layer  
steve. >> > >> 7, v6 is an addressing system that runs at layer 3.  If we'd (the  
steve. >> > >> community) got everything right with v6, it wouldn't matter to  
steve. >> > >> Google's applications whether the content came from a site hosted  
steve. >> > >> on a v4 address, or a v6 address, or even both.
steve. >> > > If Google does not have v6 connectivity then how are they going to  
steve. >> > > crawl those v6 sites?
steve. >> > 
steve. >> > I think we're debating from very similar positions...
steve. >> > 
steve. >> > v6 isn't the ideal scenario of '96 extra bits for free', because if  
steve. >> > life was so simple, we wouldn't need to ask this question.
steve. >> > 
steve. >> > Andy
steve. >> > 
steve. >