Re: [IAOC] Re: IPv4 Outage Planned for IETF 71 Plenary

Ray Pelletier <rpelletier@isoc.org> Sun, 23 December 2007 02:41 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 1J6GmX-0007iS-HH; Sat, 22 Dec 2007 21:41:37 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J6GmV-0007iE-7e for ietf@ietf.org; Sat, 22 Dec 2007 21:41:35 -0500
Received: from smtp167.sat.emailsrvr.com ([66.216.121.167]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J6GmT-0005iT-Ht for ietf@ietf.org; Sat, 22 Dec 2007 21:41:35 -0500
Received: from relay6.relay.sat.mlsrvr.com (localhost [127.0.0.1]) by relay6.relay.sat.mlsrvr.com (SMTP Server) with ESMTP id 371021B4032; Sat, 22 Dec 2007 21:41:33 -0500 (EST)
Received: by relay6.relay.sat.mlsrvr.com (Authenticated sender: rpelletier-AT-isoc.org) with ESMTP id C6B6D1B4030; Sat, 22 Dec 2007 21:41:32 -0500 (EST)
Message-ID: <476DCBED.9010909@isoc.org>
Date: Sat, 22 Dec 2007 21:46:05 -0500
From: Ray Pelletier <rpelletier@isoc.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en, zh, zh-cn, zh-hk, zh-sg, zh-tw, ja
MIME-Version: 1.0
To: rpelletier@isoc.org
References: <E1J68kX-0000kg-Rd@ietf.org> <1646213754-1198348562-cardhu_decombobulator_blackberry.rim.net-427825475-@bxe022.bisx.prod.on.blackberry>
In-Reply-To: <1646213754-1198348562-cardhu_decombobulator_blackberry.rim.net-427825475-@bxe022.bisx.prod.on.blackberry>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 75ac735ede4d089f7192d230671d536e
Cc: ietf@ietf.org
Subject: Re: [IAOC] 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>
Content-Type: multipart/mixed; boundary="===============0267309017=="
Errors-To: ietf-bounces@ietf.org


rpelletier@isoc.org wrote:

>Russ
>Congrats. The ripples from this are and will be significant. It certainly nudged ICANN
>  
>
I erred. I was not aware of the background concerning the work underway 
at ICANN.. 
The timing by them will provide additional momentum to the efforts 
underway and the good work done by many over an extended period.

Ray

>Best for the experiment. 
>Happy holidays 
>Ray
>Sent via BlackBerry by AT&T
>
>-----Original Message-----
>From: IETF Chair <chair@ietf.org>
>
>Date: Sat, 22 Dec 2007 13:07:01 
>To:IETF Announcement list <ietf-announce@ietf.org>
>Cc:iaoc@ietf.org, iesg@ietf.org, ietf@ietf.org
>Subject: [IAOC] Re: IPv4 Outage Planned for IETF 71 Plenary 
>
>
>Dear Colleagues:
>
>I had no idea that my previous announcement would generate such a long
>stream of responses.  The lively discussion has been surprising,
>interesting, and also informative.  I need to share some history, some
>plans, and some reactions to this lengthy discussion.
>
>The IETF meeting network supported IPv6 for at least the last five years.
>Both IPv4 and IPv6 routing have been available on all of the subnets in
>the primary meeting venue, and that there have been IPv6 transit to the
>greater Internet. The goal has been for this to be native IPv6 transit,
>but tunnels have been required in some venues due to upstream provider
>limitations or gross routing inefficiency in the native path. IPv6
>addressing has recently employed a /32 that has been kindly made
>available for the IETF meetings by APNIC.  Previously, IPv6 addressing
>employed a per-meeting /48 allocation. Local meeting services, such as
>DNS, NTP, LPR, and IPP, have been accessible using IPv6 via dual stack
>on-site servers, and recently DHCPv6 has been added to provide IPv6
>nameserver information.
>
>Following the mail list discussion, we have considered several different
>configurations for achieving the desired network experiment environment.
>It is important that everyone have adequate opportunity for advance
>configuration, and it is important that severe impact on other network
>resources at the meeting venue be avoided.  With these goals in mind, we
>intend to add an additional IPv6-only subnet, with a different SSID on
>the wireless network.  The SSID will include some clever name that
>includes the string "v6ONLY".  This SSID will be available on all the
>wireless access points throughout the venue for the entire week.
>Everyone is encouraged to try using this network well before the plenary
>session.  Neighbors and friends are encouraged to help each other debug
>problems, and the kind folks at the help desk in the Terminal Room will
>also be happy to assist with any configuration challenges, IPv6-related
>or otherwise.
>
>During the plenary session, at a well advertised time, which will be
>after the host greeting and several other information packed
>presentations, all of the IPv4/IPv6 capable SSIDs (the usual ietf* ones
>that have been available at meetings for the last few years) will be
>disabled on the APs in and around the plenary room. Only the v6ONLY
>network will be accessible to the plenary session attendees for 30 to 60
>minutes. The APs outside the plenary room area, including the lobby, the
>bar, and other public spaces, as well as the entire wired network, will
>remain unchanged.  To ensure proper coverage of the public spaces with
>both IPv4 and IPv6, there is likely to be some leakage of the IPv4-
>enabled networks into the plenary room. The plenary attendees will be
>asked to refrain from using them.  These resources will be overwhelmed if
>all of the plenary attendees attempt to use them, so please leave them
>for the people in the public spaces.  If you are in the plenary, please
>participate in the experiment.  We are trying to figure out how to
>display in real time the traffic statistics on the v6ONLY network during
>the plenary.  I'm hoping it can be projected while the experiment is
>running.
>
>I should note that the IETF meeting network infrastructure will be
>running on IPv4.  That is one reason that v6ONLY will be offered on the
>wireless network.  Management traffic on the wired network needs IPv4.
>Consider this the first item on the "not quite ready" list that will be
>compiled during the experiment.
>
>During the experiment, a mechanism to capture notes on the experience
>will be made available.  We have not figured out whether a wiki, mail
>list, jabber room, or something else will be employed.  The idea is to
>gather the experience of the engineers that choose to participate in the
>experiment. Please note that the IETF meeting network will provide IPv6
>connectivity, name resolution, and transit, but any additional services
>such as IPv6/IPv4 ALGs, are outside the scope of this experiment.  If
>someone would like to use such a resource during this experiment, please
>hold that thought.  A mail list will be set up and announced for this
>kind of coordination.
>
>This experiment is an opportunity for the IETF community to see what we
>can make happen by IETF 71. IANA has accepted the challenge to get AAAA
>records into the root zone.  I sincerely hope that they are successful.
>Others are trying to get IPv6 service to servers that are often visited
>by IETF meeting attendees.  I sincerely hope they are successful too.
>Activities like these need milestones, otherwise they get pushed to the
>back burner.  This plenary experiment is serving as one such milestone.
>
>This experiment is also an opportunity for the engineers that make up the
>IETF community to learn.  My ISP does not offer IPv6, so I have no hands-
>on IPv6 experience.  This plenary experiment, and the v6ONLY network that
>will be available the entire week, offer an opportunity for real hands-on
>experimentation.  Even people that have this capability in their homes or
>work environments will learn from helping others get their configurations
>sorted out.  We all learn best from hands-on experience, not just talking
>about what would happen if you could do it yourself.
>
>Wishing you and your family a safe and warm holiday season,
>   Russ Housley
>   IETF Chair
>
>
>At 04:39 PM 12/14/2007, IETF Chair wrote:
>  
>
>>Dear Colleagues:
>>
>>How dark is the IPv6 Internet?  Let's find out.
>>
>>During the IESG/IAOC Plenary at IETF 71, we are going to turn off IPv4
>>support on the IETF network for 30 to 60 minutes.  We will encourage
>>the audience to use the Internet and determine which services that they
>>have come to take for granted remain available.
>>
>>If you are from a service provider, we encourage you to make your
>>service a bright spot on the IPv6 Internet.
>>
>>To facilitate this experiment, a URL with instructions on how to get
>>IPv6 running on Windows, Mac OS X, Linux, and so on.  Some information
>>will also be available for a 4-to-6 tunnel.
>>
>>We will ask everyone to list things that work and things that do not.
>>The results will be part of the proceedings for the plenary session.
>>
>>We will make more information about the structuring of this activity
>>over the next few weeks.  Please do whatever you can to make ready ...
>>
>>Russ Housley
>>IETF Chair
>>    
>>
>
>_______________________________________________
>IAOC mailing list
>IAOC@ietf.org
>https://www1.ietf.org/mailman/listinfo/iaoc
>  
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Ietf mailing list
>Ietf@ietf.org
>https://www1.ietf.org/mailman/listinfo/ietf
>  
>
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf