Subject: IETF62 Network and Terminal Room Information

From: Jim Martin <[email-masked]>
Date: Mon, 7 Mar 2005 09:25:35 -0600

Network and Terminal Room Information
IETF 62 – Minneapolis, MN

Terminal Room
----------------------
The Terminal Room is located in Marquette and Hennepin on the second 
floor of the Minneapolis Hilton and is open 24 hours a day beginning at 
4pm on Sunday March 6th and ending at 12 noon on Friday March 11th. A 
help desk is being provided and will be manned from 8:00 AM to 8:00 PM 
every day.  The room itself consists of approximately 120 seats 
providing wired 10/100/1000 Ethernet access and 110v North American 
power ports.  There are also two duplex printers available. Please note 
that this terminal room has, in fact, no terminals, PCs or other 
user-accessible machines. It is simply a place to get power and wired 
Internet access.

When using the Ethernet connections in the Terminal Room, IPv4 
addressing is provided via DHCP. Please use Dynamic Autoconfiguration 
for IPv6. Unlike the wireless networks, IP multicast is enabled for the 
terminal room network.

Network Basics
---------------------
The IETF 62 network connects to the Internet via a metropolitan gigabit 
Ethernet link with a backup 54-megabit wireless link. The entire event 
is addressed out of the 130.129.0.0/16 block for IPv4 and 
2001:468:19ff::/48 for IPv6. IPv4 multicast and IPv6 are being provided 
from Abilene/I2.

Wireless
------------
An 802.11 a/b/g wireless network is being provided liberally in the 
Minneapolis Hilton. The areas being specifically covered are the 
meeting rooms and hallways in the conference area, the executive 
lounge, the lobby, and the bar area.

To use this network, associate with the beaconed SSID of “ietf62”. IPv4 
addressing is provided via DHCP. For IPv6 and IPv4 combined services, 
associate with the open but un-beaconed SSID “ietf62-ipv6” . IPv6 
clients should use Dynamic Autoconfiguration. Due to bandwidth concerns 
IP multicast is not available on this network.

For those interested in a bit more link-layer security, a 128-bit WEP 
enabled SSID is available. It must be manually configured, as there is 
no beacon for this network, The SSID is “ietf62-wep” and the WEP key is 
“wepisinsecure” (Hex: 7765706973696e736563757265)

For substantially better link-layer security, we are providing dynamic 
WEP keying using 802.1X.  It also must be manually configured because 
there is no beacon. Note that is dynamic WEP, not TKIP or WPA.

To use 802.1X:
1. Associate to SSID: ietf62-dot1x
2. Use PEAP/MSCHAPv2, TTLS/PAP, TTLS/CHAP, TLS
3. Do Not Verify Server Cert and we won’t verify yours :)
4. UserName and/or Realm can be anything, as well as outer tunnel 
identity for TTLS.
ex.  [email-masked]
5. Password must be  “ietf62”

The proper operation of the wireless network requires the assistance of 
all users.  One of the most significant issues with wireless 
performance in past IETF meetings has been wireless clients 
automatically, or accidentally initiating "ad-hoc" networks that act as 
the official IETF wireless network, causing other users to associate 
with false IETF wireless networks.  Therefore, please disable your 
client's ability to create an ad-hoc network and as well as the ability 
to automatically join an ad-hoc network.  If you are using Windows XP 
or Mac OS X 10.3 to manage your wireless client, the instructions to 
disable creation of ad-hoc networks are listed below. If you are using 
other systems, please do what ever your particular wireless client 
management system requires to turn off ad-hoc networks.

Instructions for Mac OS X
----------------------------------
   Open System Preferences -> Network -> Airport and un-check the box 
for "Allow this computer to create networks".

Instructions for Windows XP
-------------------------------------
   Open Properties -> wireless networks -> advanced and then select 
"access point (infrastructure) networks only" and unselect 
"automatically connect to non-preferred networks".

Printing
----------
Two printers are located in the Terminal Room and are available to all 
IETF users. The printers themselves are HP LaserJet 4200Ns which are 
Postscript capable and have the duplex option installed. The printers 
are accessible via IPP, LPD, and Windows Printing (via samba).
〈	IPP - URI ipp://lpd.ietf62.ietf.org/printer
〈	cups - browsing enabled and should be discovered automatically
〈	Mac - under Printer Setup Utility use "IETF_62_Terminal_Room" under 
shared printers
〈	Windows users - In an IE window type in 
‘\\lpd\terminal_room_printers” A warning/error message may pop-up 
saying the server does not have the correct printer driver installed, 
just hit OK. Next an Add Printer Wizard dialogue box will appear, you 
need to select two things: In the left window (Manufacturer) select 
'HP'. Then in the right hand window (Printers), scroll down and select 
'HP LaserJet 4200N', then hit 'Ok'.
	o	You may see the status of the printer say something like 'Access 
denied, unable to connect' just ignore this, it should work fine.
	o	You may need to disable your VPN connection(s).

Services
------------
The following network services are provided:
SMTP – {smtpp,smtp1,smtp2}.ietf62.ietf.org
SMTP relay services are provided for users on the IETF network.
NTP - ntp.ietf62.ietf.org
Stratum 2 time service is provided via IPv4 unicast.
Local IETF Website mirror – www.ietf.org
We have a local complete mirror of the IETF site. If you resolve 
www.ietf.org using the onsite DNS servers, you will be directed to the 
local mirrors.

These services are being provided from both of the following servers:
130.129.16.12 (IPv4) or 2001:468:19ff:16:230:1bff:fead:4e40 (IPv6)
130.129.16.13 (IPv4) or 2001:468:19ff:16:260:97ff:fed1:a86c (IPv6)

Additionally, full recursive DNS service is being provided from 
130.129.16.18 and 130.129.16.20. Our domain name is ietf62.ietf.org.

Thanks
----------
The terminal room and IETF network are made possible by the generous 
contributions by a number of companies and by the tireless efforts of 
our volunteer team. If you see any of these people in the halls, please 
be sure to thank them for all their work!

Contributors:
Alcatel, Airespace, Cisco Systems, Juniper Systems, Onvoy, University 
of Minnesota, Infoblox

Volunteers:
Jim Martin, Karen O'Donoghue, Bill Jensen, David Farmer, Dan Westacott, 
Chris Stradtman, Rob Nagy,
Geoff Horne, Ben Kochie, Terry Slattery, Jesse Lindeman, Terry Yackel, 
George Perakis, Francois Bourdais,
Rafael Rizo, Dennis Fazio, Chris Liljenstolpe, Jerry Wilson, Dave 
Ahlstrand, Frank Di Gravina, Steve Fletty

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 11 Mar 2005 01:08:05 -0600

Hi,

I will like to ask the responsible/s of setting up the IETF network to make
sure that we don't have again, a situation like we had this week, when the
network was not working most of the time, and no IPv6 available.

There was already some problems in the last IETF, and it seems to me that
the reason may be the APs, as by chance, it seems to me that are the same,
and that never had been used in previous IETFs. Of course, I may be wrong,
but seems an interesting coincidence, and if that's the case, we should
never use them.

This week has been really painful in terms of network, spending extra time,
and even some times being forced to "escape" from some meetings, because
this situation of general malfunction of the network.

Is also not acceptable, in my opinion, not being able to support IPv6, when
today, we know, from experience of past IETFs, that it has never seen a
problem. Again, the coincidence with the previous event and the same APs ?

This doesn't facilitate our work, dismisses our attention and in general
make IETF much less productive than it should be.

Thanks for making sure that this will NEVER happen again, please.

Regards,
Jordi

> De: Jim Martin <[email-masked]>
> Responder a: <[email-masked]>
> Fecha: Mon, 7 Mar 2005 09:25:35 -0600
> Para: "[email-masked]" <[email-masked]>
> Asunto: IETF62 Network and Terminal Room Information
>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 11 Mar 2005 16:31:39 +0100

Jordi, I thought that Jim Martin's message under subject
"IETF62 Wireless Network Update" had already explained
what was happening (and IPv6 was a victim of those
circumstances). Of course this was very annoying and nobody
wants to see it happen again.

In my experience the IPv4 network was working *most* of the time
after Monday, but there were roaming glitches. And if you
unintentionally associated with the hotel network, life became
more complicated.

      Brian

> network was not working most of the time, and no IPv6 available.

<snip>

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Fri, 11 Mar 2005 10:50:11 -0500

>unintentionally associated with the hotel network, life became

It's also not a new problem; we've had major wireless network meltdowns 
at many recent IETFs.  (I'm not at this IETF; I've been at every other 
one for the last 10 years, and it's an ongoing problem: running a 
large-scale wireless net with no time for stress-testing is *hard*.)

		--Prof. Steven M. Bellovin, http://www.cs.columbia.edu/~smb

---

From: Tim Chown <[email-masked]>
Date: Fri, 11 Mar 2005 16:01:33 +0000

> unintentionally associated with the hotel network, life became

I think Jordi was being rather harsh.

One thing that would be very useful, both for the IETF ops people (who I
assume change with each event) and attendees who may want to run large
events with WLAN, is for the ops team to do a 2-3 page writeup after
each IETF of what was deployed, what worked, what didn't and recommendations
for future deployments.  

I recall Austria had probably the best network seen in some time (even
Randy Bush praised it in the plenary ;) but the magic secret was lost in 
the mists of time.

Running an IETF network is a thankless task.  Maybe such reporting would
ease the task a little for future IETFs and for others running similar
events (though IETF is probably as demanding as it gets :)

I didn't see a Hilton SSID all week btw.  I had pretty much no connectivity
in meeting rooms from Mon-Wed, then it improved later yesterday, maybe as
the number of attendees/users diminuished.  My symptoms were wireless
association dropping sporadically and DHCP failing to issue an IP, but
when I was associated packet loss to the deafult gateway was high and RTT
to it often peaked up at a few 1000ms.   But if I needed access I could
just pop downstairs in the breaks and use the IETF network in the lobby
bar area :)

Tim

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 11 Mar 2005 09:56:48 -0600

Hi Brian,

I was not referring only to IPv6 (which is bad not have it working in any
case), but also to IPv4. It was not working for me in most of the meeting
rooms, most of the time (today seems to be fine) and talking to many people,
they had the same issue.

I think is terrible that the quality of the network, instead of being
improved with every meeting, seems to be going worst and worst, and this
probably requires some serious measures, in my opinion.

Regards,
Jordi

> De: Brian E Carpenter <[email-masked]>
> Organización: IBM
> Fecha: Fri, 11 Mar 2005 16:31:39 +0100
> Asunto: Re: IETF62 Network and Terminal Room Information
>

---

From: "Lucy E. Lynch" <[email-masked]>
Date: Fri, 11 Mar 2005 08:18:00 -0800 (PST)

On Fri, 11 Mar 2005, Tim Chown wrote:

<snip>
> Randy Bush praised it in the plenary ;) but the magic secret was lost in

Not exactly, Telekom Austria spent more than a year ramping up for the
meeting AND they had installed and controled all of the in building
network for the Austria Center Vienna. They did a great job, but they
had way more access and way more time in building than most IETF network
teams ever get. The difference between a production network and Rock &
Roll.

---

From: George Michaelson <[email-masked]>
Date: Fri, 11 Mar 2005 10:21:16 -0600

Caveat: I am not an RF engineer. I am no longer trusted to do much network
	config by my team. I run NetBSD rather than a commercial OS and can
	probably be regarded as a (l)user.

We're a mix of platforms, probably more diverse than most smaller, dense
deployments. Few of us get to CeBIT or other situations likely to be like
this, for worst-case networking. You can't compare this to the density
problem of normal offices.

I'm not convinced the RF sharing in the A/B/G world works well with older
cards, and I am sure we have some people who are using pre-'gold' lucent
chipsets locked at 2mbit. 

I saw a lot of non-printable SSID. I saw a lot of non-IETF, non-hotel SSID.
Some I think are in the area, some were undoubtedly the ad-hoc nonsense
which crops up. 

I got better WiFi in the Irish Pub.

I am not sure the range of SSID helped. the WEP ssid probably shouldn't be
even remotely close to 'ietf62' and having ietf62-wep didn't help me all
the time (this is classic 'problem between chair and keyboard' stuff)

We have people who freak their power budget. I don't think this is in the
wider community interest. 

We have people who run two cards at once. They probably get a good outcome
but I wonder if it helps everyone around them to have two cards
cataleptically bouncing between the same channel

We have people on laptops with bad engineering. some laptops with built-in
WiFi have truly awful issues with large pods of water and fat moving
between them and the base-station, some appear to prefer being in specific
orientation.

I was routinely seeing 8+ base stations on 2 channels. I've said this to
people in the NOC, and not yet been contradicted but isn't it meant to be a
bad idea to have that many base stations visible on the same channel? I
thought even spread spectrum had limits to how much RF you could use with
other people.

The reports that turning off one of A or G improved things makes me think
this has a lot to do with the link layer, the RF.

the DHCP service was odd. If the net is not actually congested, then why
would a DHCP server take so long to serve? I don't see why the beast was
stuck in backoff land for so long. Of course, if it too was seeing
melt-down of the carrier, the ARP must have been lost along with all the
good bits, but when the net was palpably 'up' -Why does a DHCP server
struggle? If its not scaling for a large flat net, should we be walking
back to smaller partitions, or to some other address discovery service
which does scale to large flat nets?

Not all Mac users had a good time. This is often a clue that things are bad
in the infrastructure. I don't have one, and they love to tell me how
perfect it was for them on their MacOS, but they just weren't doing it, and
I think that also says there was something wrong out there on the aether.

I respect the effort the NOC put in. I know its hard to do this stuff, I do
it writ small on far smaller conferences, and I know how hard it can be to
make it fly when the users are grumpy. But we're not going to get to a
better place without recognizing this was NOT a good network, even
relatively speaking inside the history of IETF nets.

-George

---

From: Simon Leinen <[email-masked]>
Date: Fri, 11 Mar 2005 17:23:19 +0100

I partly share Jordi's concerns about the newfangled IETF WLAN.

While the network basically worked reliably for me once I nailed my
adapter to 802.11a, it was truly disappointing to see IPv6 being
turned off a(between Monday and Tuesday IIRC).  I wonder whether the
decision to turn off IPv6 was just part of a general feature-shedding
strategy to stabilize the network, or whether there were actually good
reasons to assume that IPv6 actually caused those instabilities.

By the way, what were the reasons to switch to the new crop of
wireless access points? If it's "we don't have to pay for them", or
"they are much easier for the volunteers to set up/manager", I can
sort-of accept this (although I think the first could be said of the
older APs too, and the second would be hard to believe).  At the
previous meeting the new APs were touted to have some unspecified new
"security features".  I don't know about others, but personally I've
always found the IETF Wireless LAN largely secure enough, thank you.

Maybe this is all just a reminder on how the Internet in general has
"fossilized", when we cannot run IPv6 due to issues in what should be
link-layer devices (new ones to boot, designed probably about eight
years *after* IPv6 was defined.)
-- 
Simon.

---

From: Joel Jaeggli <[email-masked]>
Date: Fri, 11 Mar 2005 08:25:10 -0800 (PST)

> probably requires some serious measures, in my opinion.

So we can expect to see your working in the noc in Paris?

-- 
-------------------------------------------------------------------------- 
Joel Jaeggli  	       Unix Consulting 	       [email-masked] 
GPG Key Fingerprint:     5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2
_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Tim Chown <[email-masked]>
Date: Fri, 11 Mar 2005 16:25:27 +0000

> teams ever get. The difference between a production network and Rock &

But we don't have any documentation of what they did to make it so good?

Note we do reuse some venues a lot, Minneapolis being one, so if it's a
matter of site surveying/preparation, one might hope that each repeated
event at the same location would allow an ideal solution to be evolved. 

I don't see that we can do anything but gain by having IETF WLAN deployments
publicly documented post-event.  The lessons would also be lapped up by
other audiences.

-- 
Tim/::1

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 11 Mar 2005 10:29:04 -0600

My understanding is that even not considering Austria, the connectivity has
been much better in the last meetings (not counting this and the W DC one).

I also agree that 1 year is much better than just one week, but one week
on-site, plus several months up-front for planning, PLUS SEVERAL IETFs
having being organized here, seems to me a failure this time.

The suggestion about writing down the experience has been raised already in
previous occasions in this list, and not sure if this has been done.

I still believe there is an interesting coincidence in the usage of the same
equipment in the last two meetings (this and W DC). What measures had been
taken since the last meeting, once was clearly recognized that that
equipment had some problems ?

Regards,
Jordi

> De: "Lucy E. Lynch" <[email-masked]>
> Fecha: Fri, 11 Mar 2005 08:18:00 -0800 (PST)
> Para: Tim Chown <[email-masked]>
> CC: "[email-masked]" <[email-masked]>

---

From: "Lucy E. Lynch" <[email-masked]>
Date: Fri, 11 Mar 2005 08:37:45 -0800 (PST)

> event at the same location would allow an ideal solution to be evolved.

not just a site survey - they built the in-building network from the
ground up when the Center was constructed and as the national PTT they had
access to the (gov) building way ahead of time to install stuff like APs.

Ask Jim/Karen/etc when they got access to any given room here in the
Hilton...

> publicly documented post-event.  The lessons would also be lapped up by

This has been done several times - after things sucked in Atlanta we
published a crit/self crit and Joel did a round of presentations on
wireless deploy in dense environments at NANOG and several other ops
meetings.

The host document is w-a-y out of date - want to take a crack at
updating it?

---

From: Tim Chown <[email-masked]>
Date: Fri, 11 Mar 2005 16:47:27 +0000

> Ask Jim/Karen/etc when they got access to any given room here in the

It is a thankless task, I emphasise :)  But the rooms are preumably the
same with each Minneapolis running.
 
> wireless deploy in dense environments at NANOG and several other ops

Has it?  I have never seen a writeup of an IETF WLAN posted to the IETF
email list or posted to the IETF web site.

Please, post pointers.   

-- 
Tim/::1

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 11 Mar 2005 10:49:08 -0600

Yes, if required, maybe I can try to help, but my guess is still the problem
is not in the deployment, but in the equipment used.

Regards,
Jordi

> De: Joel Jaeggli <[email-masked]>
> Fecha: Fri, 11 Mar 2005 08:25:10 -0800 (PST)
> Para: JORDI PALET MARTINEZ <[email-masked]>
> Asunto: Re:IETF62 Network and Terminal Room Information
>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 11 Mar 2005 17:52:54 +0100

Simon Leinen wrote:
...
> I wonder whether the
> strategy to stabilize the network, 

This is my understanding

    Brian

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 11 Mar 2005 10:51:32 -0600

I also think that removing IPv6 didn't helped AT ALL and if IPv6 is not good
for those APs (and can be confirmed), then we have a coordination problem
here (well the maker has it also from another point of view).

Actually when the DHCP was down the first days, I was still able to work,
thanks to IPv6 !!!!

Regards,
Jordi

> De: Simon Leinen <[email-masked]>
> Fecha: Fri, 11 Mar 2005 17:23:19 +0100

---

From: "Lucy E. Lynch" <[email-masked]>
Date: Fri, 11 Mar 2005 09:02:42 -0800 (PST)

> email list or posted to the IETF web site.

http://www.nanog.org/mtg-0302/density.html

digging for posts to ietf list.

---

From: Simon Leinen <[email-masked]>
Date: Fri, 11 Mar 2005 18:13:00 +0100

> This is my understanding

Thanks, I suspected as much.  So here's a plea to consider un-shedding
that particular feature next time :-)
-- 
Simon.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 11 Mar 2005 11:19:32 -0600

Just to add an observation - we've been in Minneapolis before, but 
802.11 is catching on. Dean Willis noted early in the week that the 
projectors and hand controllers used 802.11 in ad hoc mode, and I 
hadn't noticed this at previous meetings.

I was seeing a LOT of other ad hoc networks, but it is interesting 
that we've been asking people to turn them off while equipment vendors 
have been turning them on in other places...

The problem really DOES morph within 18 months.

Spencer

---

From: Stephen Casner <[email-masked]>
Date: Fri, 11 Mar 2005 09:36:48 -0800 (PST)

I think my experience with the wireless network was on the lower end
of the scale, perhaps in part due to the fact that I am using an older
laptop and Cisco 340 card with 802.11b only.  I also run FreeBSD, so
that put me outside the norms.  The wireless network worked great on
Saturday and most of Sunday, but ran into trouble as the population
grew.

As a consequence, I spent some time working with the NOC folks after
they invited assistance to investigate problem situations.  They
explained to me that the equipment used in this network has dumb
access points hooked to centralized controllers.  Those controllers
implement or proxy the DHCP and ARP functions.  Furthermore, DHCP, ARP
and data packet forwarding are separate functional paths through the
controller which can independently work better or worse.  That can
result in surprising behavior relative to a more traditional
functional decomposition into separate boxes.  For example, a number
of times I got an address from DHCP, but could not ARP the first-hop
router.  Some of the improvements over the days came from turning off
features such as one that tries to protect against address use by
sources that had not obtained an address via DHCP.  In the later days,
I still had problems becomming disassociated, but always when
associated I got DHCP, ARP and packet flow.

I noticed that performance was always fine once the session was over
and most people shut down their connections.  One hypothesis was that
limits were reached in various state tables in the controller.  Only
the vendor could know about those details for sure.  But I draw the
conclusion that this particular system may not be ready yet to scale
to the density of radio participants at the IETF meeting.

                                                        -- Steve

---

From: Dave Singer <[email-masked]>
Date: Fri, 11 Mar 2005 09:38:41 -0800

Forgive me, I wasn't at the meeting, but I suspect that you had the 
usual slew of problems with 802.11 networks at large meetings, such 
as:

a) Users confusing other users by going into ad-hoc mode with the 
same network name;
b) some base stations seem to get royally confused when this happens, 
which is worse (and I suspect but do not know that this can cause the 
base stations to drop their transmit power)
c) radio-level problems caused by 802.11 devices using the same radio 
channels but not co-operating.  I even recently was at a meeting 
where the IS had setup 3 base stations on the same network and 
frequency, within feet of each other, because each had a 10-user NAT 
limit.  Asking for radio interference (and it didn't solve the 
problem, since users cannot then choose which base station they get!).
d) aggressive bluetooth devices making it difficult to get large 
packets through
...

Why do I bring this up?  Because at IETF and MPEG meetings, large 
company developer conferences, and so on, I observe it takes a 
significant team of people just managing the wireless network.  Is it 
time for those who have experience "at the sharp end" to pool the 
collected wisdom and talk to the 802.11 committee about this?  I 
think that otherwise these problems will (and probably are) damping 
the adoption and use of this, and hence IP-based services, and that 
it's time to consider changes to the spec. -- or at least 
recommendations -- to ameliorate some of these problems.

As to why some OSs switch automatically into ad-hoc mode if they 
cannot find the base station, I will remain silent...
-- 
David Singer
Apple Computer/QuickTime

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 12 Mar 2005 14:57:59 +0100

> that particular feature next time :-)

You won't find me diasagreeing. I haven't been posting on the "Why"
thread but my views on IPv6 and NAT are well known.

    Brian (momentarily out of the chair)