I think what you will see is ever increasing fees for IPv4 transit rather than a hard deprecation date. As IPv4 becomes more expensive than IPv6, people will migrate to save money.
Owen On Oct 21, 2010, at 9:34 AM, 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 > 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:dwh...@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. > > >
