On 15 dec 2007, at 16:14, Marshall Eubanks wrote:
Lets do the experiment, but lets not run it in prime time until we
know how it will impact productivity.
How do you know that until you try?
I would argue that the plenary sessions are not prime time network
usage hours.
An obvious idea would be to have a separate, IPv6 only, wireless
network for the part or all of the meeting locations for the entire
week, not just the plenary. I have a feeling that it might take more
than 2 hours to do useful debugging.
Agree. In cases like this you generally run into multiple hurdles, so
if you want to learn about more than the first one, you need to have
the time to jump over each of them. There have already been two
different wireless networks the last several meetings, one could be
made IPv6-only the whole week. Then during the plenary session, the
other network can be brought down and then back up again as IPv6-only
to trigger hosts to forget their DHCP leases.
But what about transition mechanisms, or would that be unfair?
If we want to simulate living in a world where there is no IPv4, lack
of IPv6 in the DNS root means no DNS so you can't even reach IPv6-
enabled destinations unless you remember their IPv6 address. So at the
very least we need fake AAAA records for the root in a resolving DNS
server (or get ICANN to move ahead with this within 3 months). A dual
stack resolver would be better, though. Not sure which OSes can learn
DNS resolver addresses from DHCPv6: Windows Vista maybe? Certainly not
Mac OS or any BSD/Linux distribution I've used. And I don't think
_anything_ supports DNS resolver addresses in RAs as the ink on the
RFC isn't dry yet.
NAT-PT is deprecated so I guess it's not appropriate to run that.
Having a dual stack HTTP(S) proxy means that pretty much all the web
and some other stuff is usable. (Even for Windows XP hosts, which run
IPv6 but can't do name lookups over IPv6. If you point to a proxy
using the literal IPv6 address you can work around this.) A TCP relay
could be useful for those of us without IPv6-capable mail servers.
A good way to test all of this could be to start with the most
complete set of transition mechanisms available on the IPv6-only
network and then remove one mechanism each day until on thursday night
it's IPv6-only all the time with no access to IPv4 allowed whatsoever.
My personal experience running IPv6-only on my MacBook Pro: my
mailserver is dual stack anyway, and a HTTP(S) takes care of the web
and pretty much anything that streams over HTTP. Main issue is IM:
Apple's iChat can do Jabber over IPv6 if there is also IPv4, but not
when running IPv4-only. I haven't found another client that will do
this but I haven't looked hard. Network printing also doesn't work.
I'm happy to volunteer for the preparations for all of this.
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf