[131218] in North American Network Operators' Group
IPv4 sunset date set for 2019-12-31
daemon@ATHENA.MIT.EDU (Jared Mauch)
Thu Oct 21 13:43:49 2010
In-Reply-To: <FD55067F70105D4BBDBE7FC036661C00012C3F0751CA@EXCHANGE.atlasbiz.com>
From: Jared Mauch <jared@puck.nether.net>
Date: Thu, 21 Oct 2010 13:42:54 -0400
To: Ben Butler <ben.butler@c2internet.net>
Cc: NANOG <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
How would you respond if that were announced? Carriers have been doing techn=
ology transitions for years. Cidr to classless. Amps to CDMA or gsm... This i=
s not new.
I do agree the incentives and technology don't exist in a desirable environm=
ent but the "ip" feature creep we've seen make a solution for everyone diffi=
cult without breaking something.
If I were king for a day, there are many things along these lines that I wou=
ld consider.
Sent from my iThing
On Oct 21, 2010, at 1:17 PM, Ben Butler <ben.butler@c2internet.net> wrote:
> Hi,
>=20
> What is the consequence of not managing to transition the v4 network and h=
aving to maintain it indefinitely. I think if the cost / limitations that t=
his may place on things is great enough then the "how" will reveal itself wi=
th the interested parties.
>=20
> Is there a downside to being stuck with both address spaces rather than ju=
st 6, idk, you tell me, but there seems to be from what I can tell.
>=20
> I am not suggesting any form of timeframe in the exact number of years / d=
ecades, just that a timeframe should exist where after a certain date - what=
ever that is - we can say ok, now we are turning off v4.
>=20
> In the absence of any form of timeframe what is the operational benefit of=
any existing v4 user migrating to v6 if the service provider is going to ma=
ke magic happen that enables them to talk to v6 only host via some mysteriou=
s bridging box. I can see none, which tells me they are not going to bother=
spending there time and money renumbering and deploying v6 - ever! There n=
eeds to be a technical, commercial or operational reason for them to want to=
go through the change.
>=20
> Ben
>=20
> -----Original Message-----
> From: Marshall Eubanks [mailto:tme@americafree.tv]=20
> Sent: 21 October 2010 18:09
> To: Ben Butler
> Cc: 'Dan White'; NANOG
> Subject: Re: Only 5x IPv4 /8 remaining at IANA
>=20
>=20
> On Oct 21, 2010, at 12:34 PM, Ben Butler wrote:
>=20
>> Hi,
>>=20
>> I can live with running dual stack for a number of years as long as IPv4 h=
as a turn off date, much like analogue TV services, thus putting onus of
>=20
> And how would you propose to achieve that ?
>=20
> Regards
> Marshall
>=20
>=20
>> responsibility onto the customer to also have a vested interest in migrat=
ing 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 gatew=
ays to bridge traffic to the pool of established v4 only customers. Presuma=
bly the evil that is NAT will have to be run on these gateways meaning we ha=
ve to endure yet more decades of many applications being undeployable for pr=
actical purposes as stun cant fix everything in the mish mash of different N=
AT implementations.
>>=20
>> The problem is there is no commercial incentive for the v4 customer to wa=
nt to move to v6 and there is no way for the ISP to force them to without lo=
osing the customer. However, if the RIRs or IANA turned around and said as o=
f xxxx date we are revoking all ipv4 allocations. Then we might be able to t=
ransition to a v6 only network in some decent timeframe without ending up go=
ing down the road of a broken dual level 4/6 half way in between broken inte=
rnet for the next 25 years.
>>=20
>> You either cross the bridge and get to the other side, or you tell all th=
e people waiting to cross they are too late and tough luck but we have run o=
ut 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.
>>=20
>> My 2c.
>>=20
>> Ben
>>=20
>> -----Original Message-----
>> From: Dan White [mailto:dwhite@olp.net]=20
>> Sent: 21 October 2010 16:30
>> To: Ben Butler
>> Cc: 'Patrick Giagnocavo'; Owen DeLong; NANOG
>> Subject: Re: Only 5x IPv4 /8 remaining at IANA
>>=20
>> On 21/10/10 16:07 +0100, Ben Butler wrote:
>>> Hi,
>>>=20
>>> 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.
>>>=20
>>> 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 i=
n
>>> the other. Is can sort of see some freaking huge NAT box type thing tha=
t
>>> 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 o=
f
>>> proxy / nat gateway between the two.
>>>=20
>>> Or are the two simply not inter-communicable?
>>=20
>> I think that's the $64K question. Do you wait to roll out v6 until you
>> start seeing v6-only hosts start popping up? =46rom an accounting and cos=
t
>> recovery stand point, that probably makes sense in some environments.
>>=20
>> 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 v=
6
>> only. That date is starting to become a bit more predictable too. Those v=
6
>> 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.
>>=20
>> 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.
>>=20
>> --=20
>> Dan White
>>=20
>>=20
>>=20
>> -------------------------------------------------------------------------=
-
>> BODY { MARGIN: 0px}.footerdark { LINE-HEIGHT: 13px; FONT-FAMILY: Arial, H=
elvetica, sans-serif; COLOR: #001a35; FONT-SIZE: 9px; FONT-WEIGHT: normal; T=
EXT-DECORATION: none}.blackcopy { LINE-HEIGHT: 12px; FONT-FAMILY: Arial, Hel=
vetica, sans-serif; COLOR: #000000; FONT-SIZE: 10px; FONT-WEIGHT: bold; TEXT=
-DECORATION: none}.bluecopy { LINE-HEIGHT: 12px; FONT-FAMILY: Arial, Helveti=
ca, sans-serif; COLOR: #29aae2; FONT-SIZE: 10px; FONT-WEIGHT: bold; TEXT-DEC=
ORATION: none}.address { LINE-HEIGHT: 12px; FONT-FAMILY: Arial, Helvetica, s=
ans-serif; COLOR: #000000; FONT-SIZE: 10px; TEXT-DECORATION: none}.footerlig=
ht { LINE-HEIGHT: 13px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #6=
67891; FONT-SIZE: 9px; FONT-WEIGHT: normal; TEXT-DECORATION: none}.pinkcopy {=
LINE-HEIGHT: 12px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #ed174=
d; FONT-SIZE: 10px; FONT-WEIGHT: bold; TEXT-DECORATION: none}
>> Ben Butler
>> Director Tel: 0333 666 3332=20
>> Fax: 0333 666 3331
>> C2 Business Networking Ltd
>> The Paddock, London Road, Nantwich, Cheshire, CW5 7JL
>> http://www.c2internet.net/
>>=20
>> Part of the Atlas Business Group of Companies plc=20
>> Registered in England: 07102986 Registered Address: Datum House, Electra W=
ay, Crewe CW1 6ZF Vat Registration No: 712 9503 48
>> This message is confidential and intended for the use only of the person t=
o whom it is addressed. If you are not the intended recipient you are strict=
ly prohibited from reading, disseminating, copying, printing, re-transmittin=
g or using this message or its contents in any way. Opinions, conclusions an=
d other information expressed in this message are not given or authorised by=
the Company unless otherwise indicated by an authorised representative inde=
pendent of this message. The Company does not accept liability for any data c=
orruption, interception or amendment to any e-mail or the consequences there=
of.Emails addressed to individuals may not necessarily be read by that perso=
n unless they are in the office.Calls to and from any of the Atlas Business G=
roup of Companies may be recorded for the purposes of training, monitoring o=
f quality and customer services.
>>=20
>>=20
>>=20
>>=20
>>=20
>=20
>=20
