Hotels/Airports with IPv6
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
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
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:
-- :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:
-- :o@>
On Thursday, July 9, 2015, Mel Beckman <mel@beckman.org> wrote:
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
On Thu, 9 Jul 2015, Ca By wrote:
I wonder if the front desk ever understood and forwarded my complaints about filtered ports (like 22) and other issues with NAT and firewalls. How do we know what customers "demand" if they don't bother reporting or are unable to produce a sophisticated report going beyond "it does not work for me"? What if Microsoft releases a portable IPv6-only game console one day? ~Marcin
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?
In message <CAL9jLabA5nO6YQ99CRhDgRTHTSB0VgP3GDNeu-VU2-4R_1_pLQ@mail.gmail.com> , Christopher Morrow writes:
+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
In message <A24F7CF2-0CD8-4EBA-A211-07BC36988A87@beckman.org>, Mel Beckman writ es:
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
-- 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
In message <DA95983C-71F1-4AA6-B431-2F2FFD515F33@beckman.org>, Mel Beckman writ es:
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
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 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.
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 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 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.
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
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
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
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 Sat, Jul 11, 2015 at 05:34:03AM +0000, Mel Beckman wrote:
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
On Sat, Jul 11, 2015 at 07:41:53AM +1000, Mark Andrews wrote:
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.
In message <20150710215658.GC23237@puck.nether.net>, Jared Mauch writes:
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 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
On Mon, Jul 13, 2015 at 10:05:32AM -0400, Lee Howard wrote:
While this is true, the fear of new/unknown causes many people to behave like deer in the headlights. At some point someone needs to blink and move. On the "wifi here" locations they need these stickers also affixed: http://tnx.nl/legacy-ip-only.svg - 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'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
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
On Mon, 13 Jul 2015, Mel Beckman wrote:
Of course. The question is, is a highly visible public wifi network the place to hammer out problems? My customer decided no.
Public Wifi nets almost always have administratively built-in limitations which may not be apparent at first to the end-users. I don't think your end-users are gonna be moaning about IPv6 issues when there will likely be other limitations they'll be cursing about :) Antonio Querubin e-mail: tony@lavanauts.org xmpp: antonioquerubin@gmail.com
On Jul 9, 2015, at 9:53 AM, Jared Mauch <jared@puck.nether.net> wrote:
We use the HotSpot feature on a Mikrotik box as a captive portal. It does not re-direct IPv6 web traffic but it does redirect all IPv4 DNS traffic to a DNS resolver that only answers with A records. Once a device has been authenticated IPv4 DNS traffic goes to a DNS server that will answer with AAAA records also. --- Bruce Curtis bruce.curtis@ndsu.edu Certified NetAnalyst II 701-231-8527 North Dakota State University
participants (20)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan Buxey
-
Antonio Querubin -
Bruce Curtis -
Ca By -
Carsten Bormann -
Christopher Morrow -
Dennis Burgess -
Jacques Latour -
Jared Mauch -
Jared Mauch
-
Julien Goodwin -
Lee Howard -
Marcin Cieslak -
Mark Andrews -
Mel Beckman -
mikea -
Oliver O'Boyle -
Owen DeLong -
Shane Ronan