Only 5x IPv4 /8 remaining at IANA

Marshall Eubanks tme at americafree.tv
Thu Oct 21 17:09:21 UTC 2010


On Oct 21, 2010, at 12:34 PM, Ben Butler wrote:

> Hi,
> 
> I can live with running dual stack for a number of years as long as IPv4 has a turn off date, much like analogue TV services, thus putting onus of

And how would you propose to achieve that ?

Regards
Marshall
 

>  responsibility onto the customer to also have a vested interest in migrating from v4 to v6.  If there is no end data - then all the service providers are going to get stuck running dual stack and providing 4to6 and 6to4 gateways to bridge traffic to the pool of established v4 only customers.  Presumably the evil that is NAT will have to be run on these gateways meaning we have to endure yet more decades of many applications being undeployable for practical purposes as stun cant fix everything in the mish mash of different NAT implementations.
> 
> The problem is there is no commercial incentive for the v4 customer to want to move to v6 and there is no way for the ISP to force them to without loosing the customer.  However, if the RIRs or IANA turned around and said as of xxxx date we are revoking all ipv4 allocations.  Then we might be able to transition to a v6 only network in some decent timeframe without ending up going down the road of a broken dual level 4/6 half way in between broken internet for the next 25 years.
> 
> You either cross the bridge and get to the other side, or you tell all the people waiting to cross they are too late and tough luck but we have run out and you cant join the party, but the last thing we want to do is get half way across the bridge and need to straddle both sides of the river.
> 
> My 2c.
> 
> Ben
> 
> -----Original Message-----
> From: Dan White [mailto:dwhite at olp.net] 
> Sent: 21 October 2010 16:30
> To: Ben Butler
> Cc: 'Patrick Giagnocavo'; Owen DeLong; NANOG
> Subject: Re: Only 5x IPv4 /8 remaining at IANA
> 
> On 21/10/10 16:07 +0100, Ben Butler wrote:
>> Hi,
>> 
>> Showing my ignorance here, but this is one of the things I have wondered,
>> given that we run both v4 and v6 for a period of time on the Internet,
>> presumably at one time or another a particular resource may only be able
>> in v4 land, then v4 and v6, then finally v6 only.
>> 
>> I have never been particularly clear how an end network that exists only
>> in v4 or v6 address space is able to access a resource that only exists in
>> the other.  Is can sort of see some freaking huge NAT box type thing that
>> summarizes v6 in a v4 address scope or contains the v4 address range at
>> some point inside the v6 address space - but how can a v4 host get to a
>> hot in v6 world that sits outside this without going through some form of
>> proxy / nat gateway between the two.
>> 
>> Or are the two simply not inter-communicable?
> 
> I think that's the $64K question. Do you wait to roll out v6 until you
> start seeing v6-only hosts start popping up? From an accounting and cost
> recovery stand point, that probably makes sense in some environments.
> 
> However, consider the fact that there will be v6 only hosts popping up
> after IANA/RIR/ISP exhaustion. There will be new entrants in the public
> internet space that cannot obtain v4 addresses and will be reachable via v6
> only. That date is starting to become a bit more predictable too. Those v6
> only sites won't be Google or Yahoo, but they will be entrepreneurs with
> good ideas and new services that your customers will be asking to get
> access to.
> 
> We're pursuing a dual stacking model today because we anticipate that
> the dual-stacking process itself will take a while to deploy, and we want
> to anticipate customer demand for access to v6 only sites. We could hold
> off on that deployment, and then spend money on work at the moment of
> truth, but that approach is not very appealing to us.
> 
> -- 
> Dan White
> 
> 
> 
> --------------------------------------------------------------------------
> BODY { MARGIN: 0px}.footerdark { LINE-HEIGHT: 13px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #001a35; FONT-SIZE: 9px; FONT-WEIGHT: normal; TEXT-DECORATION: none}.blackcopy { LINE-HEIGHT: 12px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #000000; FONT-SIZE: 10px; FONT-WEIGHT: bold; TEXT-DECORATION: none}.bluecopy { LINE-HEIGHT: 12px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #29aae2; FONT-SIZE: 10px; FONT-WEIGHT: bold; TEXT-DECORATION: none}.address { LINE-HEIGHT: 12px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #000000; FONT-SIZE: 10px; TEXT-DECORATION: none}.footerlight { LINE-HEIGHT: 13px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #667891; FONT-SIZE: 9px; FONT-WEIGHT: normal; TEXT-DECORATION: none}.pinkcopy { LINE-HEIGHT: 12px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #ed174d; FONT-SIZE: 10px; FONT-WEIGHT: bold; TEXT-DECORATION: none}
> Ben Butler
> Director Tel: 0333 666 3332 
> Fax: 0333 666 3331
> C2 Business Networking Ltd
> The Paddock, London Road, Nantwich, Cheshire, CW5 7JL
> http://www.c2internet.net/
> 
> Part of the Atlas Business Group of Companies plc 
> Registered in England: 07102986 Registered Address: Datum House, Electra Way, Crewe CW1 6ZF Vat Registration No: 712 9503 48
> This message is confidential and intended for the use only of the person to whom it is addressed. If you are not the intended recipient you are strictly prohibited from reading, disseminating, copying, printing, re-transmitting or using this message or its contents in any way. Opinions, conclusions and other information expressed in this message are not given or authorised by the Company unless otherwise indicated by an authorised representative independent of this message. The Company does not accept liability for any data corruption, interception or amendment to any e-mail or the consequences thereof.Emails addressed to individuals may not necessarily be read by that person unless they are in the office.Calls to and from any of the Atlas Business Group of Companies may be recorded for the purposes of training, monitoring of quality and customer services.
> 
> 
> 
> 
> 





More information about the NANOG mailing list