We manage 65+ hotels in Canada and the topic of IPv6 for guest internet connectivity has never been brought up, except by me. It's not a discussion our vendors or the hotel brands have opened either. On Thu, Jul 9, 2015 at 11:04 AM, Mel Beckman <mel@beckman.org> wrote:

I working on a large airport WiFi deployment right now. IPv6 is "allowed for in the future" but not configured in the short term. With less than 10,000 ephemeral users, we don't expect users to demand IPv6 until most mobile devices and apps come ready to use IPv6 by default.

-mel beckman

...

On Jul 9, 2015, at 7:53 AM, Jared Mauch <jared@puck.nether.net> wrote:

It’s my understanding that many captive portals have trouble with IPv6 traffic and this is a blocker for places.

I’m wondering what people who deploy captive portals are doing with these things?

https://tools.ietf.org/html/draft-wkumari-dhc-capport

seems to be trying to document the method to signal to clients how to authenticate. I was having horrible luck with Boingo yesterday at RDU airport with their captive portal and deauthenticating me so just went to cellular data, so wondering if IPv4 doesn’t work well what works for IPv6.

Thanks,

- Jared

-- :o@>

Yep, because most don't even know what NAT is! On Thu, Jul 9, 2015 at 11:33 AM, Dennis Burgess <dmburgess@linktechs.net> wrote:

Most hotels etc, are perfectly happy doing NAT.

Dennis Burgess, CTO, Link Technologies, Inc. dennis@linktechs.net – 314-735-0270 – www.linktechs.net

-----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Oliver O'Boyle Sent: Thursday, July 09, 2015 10:20 AM To: Mel Beckman Cc: North American Network Operators' Group Subject: Re: Hotels/Airports with IPv6

We manage 65+ hotels in Canada and the topic of IPv6 for guest internet connectivity has never been brought up, except by me. It's not a discussion our vendors or the hotel brands have opened either.

On Thu, Jul 9, 2015 at 11:04 AM, Mel Beckman <mel@beckman.org> wrote:

...

I working on a large airport WiFi deployment right now. IPv6 is "allowed for in the future" but not configured in the short term. With less than 10,000 ephemeral users, we don't expect users to demand IPv6 until most mobile devices and apps come ready to use IPv6 by default.

-mel beckman

...

On Jul 9, 2015, at 7:53 AM, Jared Mauch <jared@puck.nether.net> wrote:

It’s my understanding that many captive portals have trouble with IPv6 traffic and this is a blocker for places.

I’m wondering what people who deploy captive portals are doing with these things?

https://tools.ietf.org/html/draft-wkumari-dhc-capport

seems to be trying to document the method to signal to clients how to authenticate. I was having horrible luck with Boingo yesterday at RDU airport with their captive portal and deauthenticating me so just went to cellular data, so wondering if IPv4 doesn’t work well what works for IPv6.

Thanks,

- Jared

-- :o@>

-- :o@>

Absolutely agree. It's not their job to even know to ask for a specific protocol version in the first place. Their experience should be as seamless and consistent as possible at all times. What we should be be concerned about is that the hospitality industry is so far behind the game on technology. Hotels and restaurants will be some of the last to drop IPv4 unless they don't realize they're doing it in the first place. On Thu, Jul 9, 2015 at 1:45 PM, Jacques Latour <jacques.latour@cira.ca> wrote:

Just turn IPv6 on when you can.

...

We manage 65+ hotels in Canada and the topic of IPv6 for guest internet connectivity has never been brought up, except by me. It's not a discussion our vendors or the hotel brands have opened either.

I would argue customers never asked an IPv4 connection either, they asked for an Internet connection. The Internet is IPv4 and IPv6.

...

...

I working on a large airport WiFi deployment right now. IPv6 is "allowed for in the future" but not configured in the short term. With less than 10,000 ephemeral users, we don't expect users to demand IPv6 until most mobile devices and apps come ready to use IPv6 by default.

End users will never demand IPv6, turn it on :-)

-- :o@>

Unfortunately, the hotel staff wouldn't be able to answer that question. But they might give them free internet in exchange and hope the guest doesn't ask any more questions! On Thu, Jul 9, 2015 at 5:01 PM, Carsten Bormann <cabo@tzi.org> wrote:

Oliver O'Boyle wrote:

...

It's not their job to even know to ask for a specific protocol version in the first place

No. They should just ask, with the best geek intonation, whether "this place still is stuck with 32-bit Internet".

Grüße, Carsten

-- :o@>

Unfortunately, there are still some that would report 2mbit via dsl and think that was ahead of their competition (and it might be in some cases...)... On Jul 9, 2015 5:51 PM, "Alan Buxey" <A.L.M.Buxey@lboro.ac.uk> wrote:

...

No. They should just ask, with the best >geek intonation, whether "this place still is stuck with 32-bit Internet"

I'm sure they'd gladly report that their Internet is 24 mbit and not just 32 bit ;)

alan

On Thursday, July 9, 2015, Mel Beckman <mel@beckman.org> wrote:

I working on a large airport WiFi deployment right now. IPv6 is "allowed for in the future" but not configured in the short term. With less than 10,000 ephemeral users, we don't expect users to demand IPv6 until most mobile devices and apps come ready to use IPv6 by default.

1. Users will never demand ipv6. They demand google and facebook. So that road goes nowhere 2. What data do you have that most devices and apps are not default-on / ready for ipv6. My guess is most devices carried by airport users will accept and use ipv6 address, and most used destinations (google, fb, netflix, wikipedia, ....) use ipv6 CB

-mel beckman

...

On Jul 9, 2015, at 7:53 AM, Jared Mauch <jared@puck.nether.net <javascript:;>> wrote:

It’s my understanding that many captive portals have trouble with IPv6 traffic and this is a blocker for places.

I’m wondering what people who deploy captive portals are doing with these things?

https://tools.ietf.org/html/draft-wkumari-dhc-capport

seems to be trying to document the method to signal to clients how to authenticate. I was having horrible luck with Boingo yesterday at RDU airport with their captive portal and deauthenticating me so just went to cellular data, so wondering if IPv4 doesn’t work well what works for IPv6.

Thanks,

- Jared

On Thu, Jul 9, 2015 at 11:04 AM, Mel Beckman <mel@beckman.org> wrote:

I working on a large airport WiFi deployment right now. IPv6 is "allowed for in the future" but not configured in the short term. With less than 10,000 ephemeral users, we don't expect users to demand IPv6 until most mobile devices and apps come ready to use IPv6 by default.

'we don't expect users to demand ipv6' aside from #nanog folks, who 'demands' ipv6? Don't they actually 'demand' "access to content on the internet" ? 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/materials and probably upgrades to gear that could be avoided by doing it in the initial installation, right?

Limited municipal budgets is all I can say. IPv6 has a cost, and if they can put it off till later then that's often good politics. -mel via cell

On Jul 10, 2015, at 2:42 PM, Mark Andrews <marka@isc.org> wrote:

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> wrote: I working on a large airport WiFi deployment right now. IPv6 is "allowed = for in the future" but not configured in the short term. With less than 10,= 000 ephemeral users, we don't expect users to demand IPv6 until most mobile= devices and apps come ready to use IPv6 by default.

'we don't expect users to demand ipv6'

aside from #nanog folks, who 'demands' ipv6?

Don't they actually 'demand' "access to content on the internet" ?

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/materials and probably upgrades to gear that could be avoided by doing it in the initial installation, right?

+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.

Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

There is most certainly a cost to IPv6, especially in a large, complex deployment, where everything requires acceptance testing. And I'm sure you realize that IPv6 only is not an option. I agree that it would have been worth 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 incremental cost. -mel via cell

On Jul 10, 2015, at 3:03 PM, Mark Andrews <marka@isc.org> wrote:

In message <A24F7CF2-0CD8-4EBA-A211-07BC36988A87@beckman.org>, Mel Beckman writ es:

...

Limited municipal budgets is all I can say. IPv6 has a cost, and if they can put it off till later then that's often good politics.

-mel via cell

IPv4 has a cost as well. May as well just go IPv6-only from day one and not pay the IPv4 tax at all.

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.

Mark

...

...

On Jul 10, 2015, at 2:42 PM, Mark Andrews <marka@isc.org> wrote:

...

...

On Thu, Jul 9, 2015 at 11:04 AM, Mel Beckman <mel@beckman.org> wrote: I working on a large airport WiFi deployment right now. IPv6 is "allowed = for in the future" but not configured in the short term. With less

In message <CAL9jLabA5nO6YQ99CRhDgRTHTSB0VgP3GDNeu-VU2-4R_1_pLQ@mail.gmail.com> , Christopher Morrow writes: than 10,=

...

000 ephemeral users, we don't expect users to demand IPv6 until most mobile= devices and apps come ready to use IPv6 by default.

'we don't expect users to demand ipv6'

aside from #nanog folks, who 'demands' ipv6?

Don't they actually 'demand' "access to content on the internet" ?

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/materials and probably upgrades to gear that could be avoided by doing it in the initial installation, right?

+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.

Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

Mark, Few acceptance test regimes cover established feature testing. It's just too expensive. For example, an acceptance test of a firewall installation does not include validating the DPI implementation. Government and enterprise buyers rely on certifications, such as ICSA for firewalls, IPv6Ready for IPv6, and standards compliance, such as IEEE 802.11ac for wireless. Instead, an acceptance test exercises the full system to ensure that it hits predetermined performance benchmarks, meets all the customer's functional requirements, and is secure. If one of the several vendors in such a project unilaterally changes components to enable unspecified protocols or features, testing won't line up with the implementation, and people will be very unhappy with the presumptuous vendor. Having deployed many IPv6 upgrades in legacy networks, I don't see deferring IPv6 as a net higher cost. It would be nice to have now, but, as they say, the customer is always right. -mel via cell

On Jul 10, 2015, at 3:27 PM, Mark Andrews <marka@isc.org> wrote:

In message <DA95983C-71F1-4AA6-B431-2F2FFD515F33@beckman.org>, Mel Beckman writ es:

...

There is most certainly a cost to IPv6, especially in a large, complex deployment, where everything requires acceptance testing. And I'm sure you realize that IPv6 only is not an option. I agree that it would have been worth 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 incremental cost.

-mel via cell

Since you have IPv6 capable gear your acceptance testing should be including the IPv6 side of it so there are no saving there if you are doing your job correctly. It is hard to go back to the suppliers N years down the track and then say "This gear isn't working for IPv6" and request a return / fix.

Turning on IPv6 later will ultimately cost more than doing it from the start. You have to manage the potential disruption. The difference in perception between "teething troubles" and "you may break the service" is huge. If you havn't done proper acceptance testing or missed something there will be replacement costs.

Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

You perhaps haven't worked a large government network deployment before. One doesn't activate features not enumerated in the design. Ever. Because they won't get and can thus introduce security or reliability covered in acceptance testing and could introduce security or reliability problems. These networks have many engineers, months of meetings, and rigorous change control. Turning on IPv6 without authorization would result in termination. -mel via cell

On Jul 10, 2015, at 3:32 PM, Jared Mauch <jared@puck.Nether.net> wrote:

...

On Fri, Jul 10, 2015 at 10:08:15PM +0000, Mel Beckman wrote: There is most certainly a cost to IPv6, especially in a large, complex deployment, where everything requires acceptance testing. And I'm sure you realize that IPv6 only is not an option. I agree that it would have been worth 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 incremental cost.

I had the luxury that as we deployed IPv6 across the network we rolled it from the 6bone -> core -> edge over a period of a few months.

As we shut down the 6bone/3ffe stuff and moved people to gre/ip and native the core was ready. This doesn't mean the edges have IPv6 turned on, but it's usually the flip of a switch.

Where possible take your core and IPv6 enable it and then touch the upstreams at the same time/next time you do work there.

Assuming you patch devices for the various SIRT/PSIRT type events, most devices will be rebooted once every 6-12 months. this gives you the chance to drop in and enable ipv6 during or after that change/maint window.

Rolling out the core really isn't hard, go ahead and do it. There are plenty of people here who will help you with these steps.

- Jared

-- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.

Jared, http://static3.businessinsider.com/image/525db76369bedd1029d61f47-1200/augus... Perfect! -mel via cell On Jul 10, 2015, at 5:02 PM, Jared Mauch <jared@puck.Nether.net<mailto:jared@puck.Nether.net>> wrote: On Fri, Jul 10, 2015 at 11:48:46PM +0000, Mel Beckman wrote: You perhaps haven't worked a large government network deployment before. One doesn't activate features not enumerated in the design. Ever. Because they won't get and can thus introduce security or reliability covered in acceptance testing and could introduce security or reliability problems. These networks have many engineers, months of meetings, and rigorous change control. Turning on IPv6 without authorization would result in termination. I did not suggest turning it on without authorization, I discussed the steps I would take to deploy it as devices are touched. I will say that some organizations have draconian ideas of what change management looks like. I would also suggest that a state or federal government (such as the US technically mandates IPv6 already, but as with all things people waiver them) is not what may be in the subject line, with the exception of an airport authority that may perform this. Personally I consider it a bit of technical malpractice to arrive a decade late to the IPv6 game but am sympathetic to those that have been trying hard to do the righ thing despite the environment they are in. Either way, you're also correct that I'm not dealing with a government agency in $dayjob. I also plan to keep it that way, except in the extreme case where I'm given authority to fix said oversights. I've seen parades of people jump from organizations they were prepared to clean up because of oppressive change management processes or work conditions. I'm sure there is a series of dilbert or similar cartoons on this. Then again, I'm pretty sure IPv6 won't cause this to happen: http://static3.businessinsider.com/image/525db76369bedd1029d61f47-1200/augus... - Jared -- Jared Mauch | pgp key available via finger from jared@puck.nether.net<mailto:jared@puck.nether.net> clue++; | http://puck.nether.net/~jared/ My statements are only mine.

Owen, I never said it was a greenfield deployment. Someone else tagged it with that term. My understanding of the term "greenfield" WRT wifi is that there are no interfering signals to contend with. I don't know of any U.S. airport that meets that definition. First you have all the wifi of concessionaires, the airlines' passenger clubs and operations, and service organizations for food, fuel, and FAA. You can't control those users, thanks to the FAA's recent decisions restricting wifi regulation to itself. Then comes radar and secondary-use DFS channels that may have to be excluded. Finally you encounter waves of MiFi hotspots which tend to be synchronized with aircraft arrivals and departures. All this existing traffic requires extensive surveys and pre-deployment modeling, 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 company) that can simulate 1000 or more wifi clients to impose a known traffic 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 sniffer. The sniffer capture then goes through offline analysis to compare actual throughout and response times with the original design metrics. You do this for selected sub areas having typical characteristics, such as a gate, security queue, baggage or dining area, at a time when it's empty. The testing process takes a day or two per airport terminal. Yes, the acceptance test needs to be revised and repeated for deploying IPv6. That is a small cost compared to the already-expended months of deployment planning and rollout. The incremental IPv6 acceptance test cost is in the noise, dwarfed even by the price of conduit. I do agree that there are potential performance gains with IPv6, through avoiding NAT. But those benefits will still be there in a year or two, and will be much larger then than they are today. Moreover, the user population is not growing rapidly, and can easily fit into simple NAT with the airport's existing IPv4 space. -mel

On Jul 10, 2015, at 9:55 PM, Owen DeLong <owen@delong.com> wrote:

How can it be a large, complex deployment if it’s greenfield.

In that case, you need to acceptance test the IPv4 just as much as IPv6.

The difference is that you don’t 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 provider having put them behind the worst CGN on the planet.

Owen

...

On Jul 10, 2015, at 15:08 , Mel Beckman <mel@beckman.org> wrote:

There is most certainly a cost to IPv6, especially in a large, complex deployment, where everything requires acceptance testing. And I'm sure you realize that IPv6 only is not an option. I agree that it would have been worth 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 incremental cost.

-mel via cell

...

On Jul 10, 2015, at 3:03 PM, Mark Andrews <marka@isc.org> wrote:

In message <A24F7CF2-0CD8-4EBA-A211-07BC36988A87@beckman.org>, Mel Beckman writ es:

...

Limited municipal budgets is all I can say. IPv6 has a cost, and if they can put it off till later then that's often good politics.

-mel via cell

IPv4 has a cost as well. May as well just go IPv6-only from day one and not pay the IPv4 tax at all.

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.

Mark

...

...

On Jul 10, 2015, at 2:42 PM, Mark Andrews <marka@isc.org> wrote:

...

> On Thu, Jul 9, 2015 at 11:04 AM, Mel Beckman <mel@beckman.org> wrote: > I working on a large airport WiFi deployment right now. IPv6 is "allowed = for in the future" but not configured in the short term. With less

In message <CAL9jLabA5nO6YQ99CRhDgRTHTSB0VgP3GDNeu-VU2-4R_1_pLQ@mail.gmail.com> , Christopher Morrow writes: than 10,=

...

000 ephemeral users, we don't expect users to demand IPv6 until most mobile= devices and apps come ready to use IPv6 by default.

'we don't expect users to demand ipv6'

aside from #nanog folks, who 'demands' ipv6?

Don't they actually 'demand' "access to content on the internet" ?

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/materials and probably upgrades to gear that could be avoided by doing it in the initial installation, right?

+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.

Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

Owen, Lol. No, I'm a Mac guy. We think different :) I suppose when an airport is first built, that would be greenfield. But this airport already has a legacy wifi system that we are replacing, incrementally. I agree that a case exists for building in IPv6 from the start, but this deployment already has enough new features, such as 802.11ac and a slew of new applications, that the customer wanted to remove ipv6 as a variable. -mel beckman

On Jul 10, 2015, at 10:47 PM, Owen DeLong <owen@delong.com> wrote:

...

On Jul 10, 2015, at 22:34 , Mel Beckman <mel@beckman.org> wrote:

Owen,

I never said it was a greenfield deployment. Someone else tagged it with that term.

My understanding of the term "greenfield" WRT wifi is that there are no interfering signals to contend with. I don't know of any U.S. airport that meets that definition. First you have all the wifi of concessionaires, the airlines' passenger clubs and operations, and service organizations for food, fuel, and FAA. You can't control those users, thanks to the FAA's recent decisions restricting wifi regulation to itself.

I suppose if you’re going to use that definition, there’s no such thing.

However, as a general rule when I talk about a greenfield deployment of a network (of any form), I, and I suspect most people, are referring to a network that is not yet saddled with any legacy deployment issues. E.g. a building that has not yet been designed. A situation where you can start from scratch with a fresh design and specify everything from the ground up, at least in terms of the major design factors in the network.

...

Acceptance testing is straightforward once it's been designed and scripted. You bring in a wifi traffic generator (from a professional test services company) that can simulate 1000 or more wifi clients to impose a known traffic 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 sniffer. The sniffer capture then goes through offline analysis to compare actual throughout and response times with the original design metrics. You do this for selected sub areas having typical characteristics, such as a gate, security queue, baggage or dining area, at a time when it's empty.

The testing process takes a day or two per airport terminal. Yes, the acceptance test needs to be revised and repeated for deploying IPv6. That is a small cost compared to the already-expended months of deployment planning and rollout. The incremental IPv6 acceptance test cost is in the noise, dwarfed even by the price of conduit.

Right, but if you’re starting fresh with a new design, why not design IPv6 in from the start? There’s really no incremental cost to doing so and your long-term savings can be substantial.

...

I do agree that there are potential performance gains with IPv6, through avoiding NAT. But those benefits will still be there in a year or two, and will be much larger then than they are today. Moreover, the user population is not growing rapidly, and can easily fit into simple NAT with the airport's existing IPv4 space.

Let me guess… You’re still running on a computer with 640k of RAM.

Owen

...

-mel

...

On Jul 10, 2015, at 9:55 PM, Owen DeLong <owen@delong.com> wrote:

How can it be a large, complex deployment if it’s greenfield.

In that case, you need to acceptance test the IPv4 just as much as IPv6.

The difference is that you don’t 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 provider having put them behind the worst CGN on the planet.

Owen

...

On Jul 10, 2015, at 15:08 , Mel Beckman <mel@beckman.org> wrote:

There is most certainly a cost to IPv6, especially in a large, complex deployment, where everything requires acceptance testing. And I'm sure you realize that IPv6 only is not an option. I agree that it would have been worth 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 incremental cost.

-mel via cell

...

On Jul 10, 2015, at 3:03 PM, Mark Andrews <marka@isc.org> wrote:

In message <A24F7CF2-0CD8-4EBA-A211-07BC36988A87@beckman.org>, Mel Beckman writ es:

...

Limited municipal budgets is all I can say. IPv6 has a cost, and if they can put it off till later then that's often good politics.

-mel via cell

IPv4 has a cost as well. May as well just go IPv6-only from day one and not pay the IPv4 tax at all.

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.

Mark

...

> On Jul 10, 2015, at 2:42 PM, Mark Andrews <marka@isc.org> wrote: > > > 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> wrote: >>> I working on a large airport WiFi deployment right now. IPv6 is "allowed = >> for in the future" but not configured in the short term. With less than 10,= >> 000 ephemeral users, we don't expect users to demand IPv6 until most mobile= >> devices and apps come ready to use IPv6 by default. >> >> 'we don't expect users to demand ipv6' >> >> aside from #nanog folks, who 'demands' ipv6? >> >> Don't they actually 'demand' "access to content on the internet" ? >> >> 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/materials >> and probably upgrades to gear that could be avoided by doing it in the >> initial installation, right? > > +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. > > Mark > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

Right. FCC. Sorry -mel beckman

On Jul 13, 2015, at 10:53 AM, mikea <mikea@mikea.ath.cx> wrote:

...

On Sat, Jul 11, 2015 at 05:34:03AM +0000, Mel Beckman wrote: Owen,

I never said it was a greenfield deployment. Someone else tagged it with that term.

My understanding of the term "greenfield" WRT wifi is that there are no interfering signals to contend with. I don't know of any U.S. airport that meets that definition. First you have all the wifi of concessionaires, the airlines' passenger clubs and operations, and service organizations for food, fuel, and FAA. You can't control those users, thanks to the FAA's recent decisions restricting wifi regulation to itself.

FAA? Could you possibly have meant FCC? FAA has little or nothing to do with regulation of radio TTBOMK, while FCC has everything to do with it.

-- Mike Andrews, W5EGO mikea@mikea.ath.cx Tired old sysadmin

In message <20150710215658.GC23237@puck.nether.net>, Jared Mauch writes:

On Sat, Jul 11, 2015 at 07:41:53AM +1000, Mark Andrews wrote:

...

+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.

What I noticed when I ran a transparent HTTP proxy at my gateway where it had IPv6 on the outside but the hosts inside did not, a lot of traffic was converted from IPv4 to IPv6 on the exterior.

As the internet has been moving to HTTPS/HSTS having DHCP and client-side support of something like draft-wkumari-dhc-capport is going to become more critical as the days go by.

While attempting to trigger the captive portal at RDU this week, Boingo redirected a query for google to their HTTPS to the portal and since HSTS was enabled I had no way to proceed from there to the right location to authenticate.

There was also some other broken stuff at RDU so I ended up just using cellular data.

- Jared

-- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.

I just type a random IP address into the browser when this sort of thing happens. Most of my connections are encrypted. Once the landing page comes up and I've clicked through a pointless terms of service they start working. If they intercept the session with their own cert I get lots of error dialogs. I then cancel the connection attempts and go the browser. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

On 11/07/15 08:25, Shane Ronan wrote:

1.1.1.1 is usually a good bet

Sadly yes, even though it's valid public IP space Cisco still have it documented as their suggested captive portal address. Despite it (and 1.2.3.0/24) being advertised by $ORK for years at this point on behalf of APNIC.

On 7/9/15, 11:04 AM, "NANOG on behalf of Mel Beckman" <nanog-bounces@nanog.org on behalf of mel@beckman.org> wrote:

I working on a large airport WiFi deployment right now. IPv6 is "allowed for in the future" but not configured in the short term. With less than 10,000 ephemeral users, we don't expect users to demand IPv6 until most mobile devices and apps come ready to use IPv6 by default.

I didn¹t see anybody point out that most mobile devices and apps come ready to use IPv6 by default. At least, all Android and iOS devices do, and Apple recently announced that IPv6 support will be mandatory in future apps. Plus, Facebook, at least, says IPv6 is faster over mobile. Don¹t know how it does over Wi-Fi. Lee

I've done fairly extensive testing, and IPv6 support, while pretty solid on the carrier side, is still iffy on WiFi. Both iOS and Android have various reliability problems with IPv6 and WiFi, mostly related to acquiring a DNS address or maintaining a connection while roaming. Combine that with less-than-fully-baked IPv6 on some enterprise WiFi platforms, and it's easy to see that deploying WiFi IPv6 today is at least a challenge, and definitely a risk. Android, for example, doesn't yet support DHCPv6 on WiFi (it's not needed on the carrier side, which does DNS intercept), and intermittently looses its unicast address on some hardware devices (notably tablets, in my experience). Even when android gets DHCPv6, or these hardware problems get solved, there will be several years of legacy devices in the field to contend with. -mel beckman

On Jul 13, 2015, at 7:05 AM, Lee Howard <Lee@asgard.org> wrote:

On 7/9/15, 11:04 AM, "NANOG on behalf of Mel Beckman" <nanog-bounces@nanog.org on behalf of mel@beckman.org> wrote:

...

I working on a large airport WiFi deployment right now. IPv6 is "allowed for in the future" but not configured in the short term. With less than 10,000 ephemeral users, we don't expect users to demand IPv6 until most mobile devices and apps come ready to use IPv6 by default.

I didn¹t see anybody point out that most mobile devices and apps come ready to use IPv6 by default. At least, all Android and iOS devices do, and Apple recently announced that IPv6 support will be mandatory in future apps. Plus, Facebook, at least, says IPv6 is faster over mobile. Don¹t know how it does over Wi-Fi.

Lee

Of course. The question is, is a highly visible public wifi network the place to hammer out problems? My customer decided no. -mel beckman

On Jul 13, 2015, at 8:54 AM, "A.L.M.Buxey@lboro.ac.uk" <A.L.M.Buxey@lboro.ac.uk> wrote:

Hi,

...

I've done fairly extensive testing, and IPv6 support, while pretty solid on the carrier side, is still iffy on WiFi. Both iOS and Android have various reliability problems with IPv6 and WiFi, mostly related to acquiring a DNS address or maintaining a connection while roaming. Combine that with less-than-fully-baked IPv6 on some enterprise WiFi platforms, and it's easy to see that deploying WiFi IPv6 today is at least a challenge, and definitely a risk.

Android, for example, doesn't yet support DHCPv6 on WiFi (it's not needed on the carrier side, which does DNS intercept), and intermittently looses its unicast address on some hardware devices (notably tablets, in my experience). Even when android gets DHCPv6, or these hardware problems get solved, there will be several years of legacy devices in the field to contend with.

we had problems with IPv4 in the early days - people still adopted it. without adoption, the bugs/issues with clients dont get addressed.

alan