[182157] in North American Network Operators' Group
Re: Hotels/Airports with IPv6
daemon@ATHENA.MIT.EDU (Mel Beckman)
Sat Jul 11 01:34:09 2015
X-Original-To: nanog@nanog.org
From: Mel Beckman <mel@beckman.org>
To: Owen DeLong <owen@delong.com>
Date: Sat, 11 Jul 2015 05:34:03 +0000
In-Reply-To: <EC51773B-2DD2-42C0-8374-CAAE01EBCDFC@delong.com>
Cc: North American Network Operators' Group <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
Owen,
I never said it was a greenfield deployment. Someone else tagged it with th=
at term.=20
My understanding of the term "greenfield" WRT wifi is that there are no int=
erfering signals to contend with. I don't know of any U.S. airport that mee=
ts that definition. First you have all the wifi of concessionaires, the air=
lines' passenger clubs and operations, and service organizations for food,=
fuel, and FAA. You can't control those users, thanks to the FAA's recent d=
ecisions restricting wifi regulation to itself.=20
Then comes radar and secondary-use DFS channels that may have to be exclude=
d. Finally you encounter waves of MiFi hotspots which tend to be synchroniz=
ed with aircraft arrivals and departures.=20
All this existing traffic requires extensive surveys and pre-deployment mod=
eling, plus lab testing for planned applications, such as way-finding.
Acceptance testing is straightforward once it's been designed and scripted.=
You bring in a wifi traffic generator (from a professional test services c=
ompany) that can simulate 1000 or more wifi clients to impose a known traff=
ic load on the network. You then use sample passenger devices of each type =
-- smartphone, tablet, and laptop -- as well as various popular OS's to run=
pre-engineered regression test scripts, recording performance via a wifi s=
niffer. The sniffer capture then goes through offline analysis to compare a=
ctual throughout and response times with the original design metrics. You d=
o this for selected sub areas having typical characteristics, such as a gat=
e, security queue, baggage or dining area, at a time when it's empty.=20
The testing process takes a day or two per airport terminal. Yes, the accep=
tance test needs to be revised and repeated for deploying IPv6. That is a s=
mall cost compared to the already-expended months of deployment planning an=
d rollout. The incremental IPv6 acceptance test cost is in the noise, dwarf=
ed even by the price of conduit.
I do agree that there are potential performance gains with IPv6, through av=
oiding NAT. But those benefits will still be there in a year or two, and wi=
ll be much larger then than they are today. Moreover, the user population i=
s not growing rapidly, and can easily fit into simple NAT with the airport'=
s existing IPv4 space.=20
-mel=20
> On Jul 10, 2015, at 9:55 PM, Owen DeLong <owen@delong.com> wrote:
>=20
> How can it be a large, complex deployment if it=92s greenfield.
>=20
> In that case, you need to acceptance test the IPv4 just as much as IPv6.
>=20
> The difference is that you don=92t have to rerun your acceptance tests 6-=
months later when you have to implement IPv6 in a rush because you suddenly=
learned that your major client gets major suckage on IPv4 due to their pro=
vider having put them behind the worst CGN on the planet.
>=20
> Owen
>=20
>> On Jul 10, 2015, at 15:08 , Mel Beckman <mel@beckman.org> wrote:
>>=20
>> There is most certainly a cost to IPv6, especially in a large, complex d=
eployment, where everything requires acceptance testing. And I'm sure you r=
ealize that IPv6 only is not an option. I agree that it would have been wo=
rth the cost, which would have been just a small fraction of the total. The=
powers that be chose not to incur it now. But we did deploy only IPv6 gear=
and systems, so it can probably be turned up later for that same increment=
al cost.=20
>>=20
>> -mel via cell
>>=20
>>> On Jul 10, 2015, at 3:03 PM, Mark Andrews <marka@isc.org> wrote:
>>>=20
>>>=20
>>> In message <A24F7CF2-0CD8-4EBA-A211-07BC36988A87@beckman.org>, Mel Beck=
man writ
>>> es:
>>>> Limited municipal budgets is all I can say. IPv6 has a cost, and if th=
ey
>>>> can put it off till later then that's often good politics.
>>>>=20
>>>> -mel via cell
>>>=20
>>> IPv4 has a cost as well. May as well just go IPv6-only from day one an=
d
>>> not pay the IPv4 tax at all.
>>>=20
>>> The cost difference between providing IPv6 + IPv4 or just IPv4 from
>>> day 1 should be zero. There should be no re-tooling. You just
>>> select products that support both initially. It's not like products
>>> that support both are more expensive all other things being equal.
>>>=20
>>> Mark
>>>=20
>>>>> On Jul 10, 2015, at 2:42 PM, Mark Andrews <marka@isc.org> wrote:
>>>>>=20
>>>>>=20
>>>>> In message
>>>> <CAL9jLabA5nO6YQ99CRhDgRTHTSB0VgP3GDNeu-VU2-4R_1_pLQ@mail.gmail.com>
>>>>> , Christopher Morrow writes:
>>>>>>> On Thu, Jul 9, 2015 at 11:04 AM, Mel Beckman <mel@beckman.org> wrot=
e:
>>>>>>> I working on a large airport WiFi deployment right now. IPv6 is
>>>> "allowed =3D
>>>>>> for in the future" but not configured in the short term. With less
>>>> than 10,=3D
>>>>>> 000 ephemeral users, we don't expect users to demand IPv6 until most
>>>> mobile=3D
>>>>>> devices and apps come ready to use IPv6 by default.
>>>>>>=20
>>>>>> 'we don't expect users to demand ipv6'
>>>>>>=20
>>>>>> aside from #nanog folks, who 'demands' ipv6?
>>>>>>=20
>>>>>> Don't they actually 'demand' "access to content on the internet" ?
>>>>>>=20
>>>>>> Since you seem to have a greenfield deployment, why NOT just put v6 =
in
>>>>>> place on day0? retrofitting it is surely going to cost time/material=
s
>>>>>> and probably upgrades to gear that could be avoided by doing it in t=
he
>>>>>> initial installation, right?
>>>>>=20
>>>>> +1 and you will most probably see about 50% of the traffic being IPv6=
if
>>>>> you do so. There is lots of IPv6 capable equipment out there just
>>>> waiting
>>>>> to see a RA.
>>>>>=20
>>>>> Mark
>>>>> --
>>>>> Mark Andrews, ISC
>>>>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>>>>> PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
>>>=20
>>> --=20
>>> Mark Andrews, ISC
>>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>>> PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
>=20
