For users that want to only use a IPv6 stack, yet be able to reach some IPv4 resources

yes

5Ghz only

v6 with access to some v4 resources through NAT64 and DNS64

eduroam

For educational users, authenticated against their home institution

yes

2.4 and 5Ghz

v4 and v6

ietf-hotel

A network over the hotel infrastructure with no filtering and utilizing the IETF uplinks

no

2.4 and (some locations) 5Ghz

v4 and v6

All networks marked as encrypted will offer layer 2 security. This is done using WPA enterprise with 802.1X (PEAP or TTLS) authentication and AES or TKIP encryption. As usual, we are all using the same credentials (user “ietf”, password “ietf”), yet each user will get unique session encryption keys. Our Radius authentication servers use a certificate that you can verify by going to the bottom of this page.

The “ietf” SSID (the closest thing we have to a “default” wireless network) now only will be seen on the 5Ghz spectrum. This network is also now encrypted.

The new “ietf-legacy” SSID will be open (no authentication or encryption) and available on both 2.4 and 5Ghz channels. This network is primarily designed for users of older (“legacy”) devices, but can be used by anyone for any reason. Obviously, there will be no layer 2 security.

The “ietf-2.4ONLY” SSID will allow you to select the 2.4Ghz band yet get an encrypted connection. This will be useful for those with devices that support only 2.4Ghz and those that have some issue with the 5Ghz network configuration.

The only changes to the “ietf-v6ONLY” and “ietf-nat64” SSIDs are the addition of encryption and the restriction to just the 5Ghz frequencies. While we’d like all attendees to use these SSIDs, we also improve the performance of the 2.4Ghz channels by reducing the number of SSID announcements. In addition, the majority of users of these networks have been doing so from 5Ghz-capable devices.

“eduroam” hasn’t changed. Those of you that will be using it will already be aware of it.

And, finally, the “ietf-hotel” SSID uses the hotel network infrastructure, yet the uplink is ours. This will give an improved experience for IETF users in their rooms and public spaces around the hotel not covered by the IETF wireless network. Note that, as we don’t control this network, we will need to work with the hotel to resolve any issues found.

As a little background, we (the IETF) have discussed the layout of wireless networks here at the IETF several times over the last few years, most recently in a thread Jari Arkko started on the ietf-announce list, with followups on the ietf list, July 24th of last summer [1]. In addition, we (the IETF/IAB and I* things) have published several items in this space, including BCP 188 [2] and the IAB Statement on Internet Confidentiality [3]. After careful analysis and testing, the NOC team is now able to deploy changes in keeping with the above to the IETF 92 network.

“The IAB now believes it is important for protocol designers, developers, and operators to make encryption the norm for Internet traffic. Encryption should be authenticated where possible, but even protocols providing confidentiality without authentication are useful in the face of pervasive surveillance as described in RFC 7258.”

We encourage you to authenticate our Radius server certificate. Here's the certificate in three different formats, including the SHA1 checksum and pgp signed versions.

Note that these files are stored on Snozzages (ask Warren…) because this Wiki will only allow me to upload pictures.

Please feel free to come by the help desk in the terminal room if you have questions or comments, or email me (see below), or, if you want to see me in particular, I'm likely to be found in the NOC in the Fountain room on the Garden Terrace level of the Fairmont Dallas.