Re: IPv4 Outage Planned for IETF 71 Plenary

Iljitsch van Beijnum <iljitsch@muada.com> Sun, 16 December 2007 15:55 UTC

Return-path: <ietf-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3vpk-0001Ac-Sk; Sun, 16 Dec 2007 10:55:16 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3vpi-00014t-Tv; Sun, 16 Dec 2007 10:55:14 -0500
Received: from sequoia.muada.com ([83.149.65.1]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J3vpi-00059E-9t; Sun, 16 Dec 2007 10:55:14 -0500
Received: from [163.117.139.241] ([163.117.139.241]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id lBGFsouE080342 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 16 Dec 2007 16:54:51 +0100 (CET) (envelope-from iljitsch@muada.com)
Message-Id: <0C29D33E-3BAD-4564-B0F3-6F7A5D1A8B59@muada.com>
From: Iljitsch van Beijnum <iljitsch@muada.com>
To: Marshall Eubanks <tme@multicasttech.com>, chair@ietf.org
In-Reply-To: <37AF8EDE-2B6F-49DB-8D02-0674B4F47677@multicasttech.com>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v915)
Date: Sat, 15 Dec 2007 19:55:03 +0100
References: <E1J3IFS-0002yV-CG@ietf.org> <20071214220518.GA14379@sources.org> <47631201.1070303@bogus.com> <p06240806c388d88dc9de@[165.227.249.204]> <a06240800c388daca0917@[192.168.1.101]> <4763EBD3.50804@cisco.com> <37AF8EDE-2B6F-49DB-8D02-0674B4F47677@multicasttech.com>
X-Mailer: Apple Mail (2.915)
X-Spam-Status: No, score=-1.8 required=3.5 tests=AWL,BAYES_00, ILJQX_SUBJ_NUMINWORD autolearn=no version=3.0.2
X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on sequoia.muada.com
X-Spam-Score: 1.8 (+)
X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3
Cc: IETF-Discussion Discussion <ietf@ietf.org>
Subject: Re: IPv4 Outage Planned for IETF 71 Plenary
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Errors-To: ietf-bounces@ietf.org

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