Re: [v6ops] Up-leveling Transition Coexistence

Mark Townsley <mark@townsley.net> Sat, 17 December 2011 09:52 UTC

Return-Path: <mark@townsley.net>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C80B221F8C04 for <v6ops@ietfa.amsl.com>; Sat, 17 Dec 2011 01:52:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.428
X-Spam-Level:
X-Spam-Status: No, score=-3.428 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ExhBH2ttpDpD for <v6ops@ietfa.amsl.com>; Sat, 17 Dec 2011 01:52:42 -0800 (PST)
Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 7D43821F8BF0 for <v6ops@ietf.org>; Sat, 17 Dec 2011 01:52:41 -0800 (PST)
Received: by wgbds13 with SMTP id ds13so4372872wgb.1 for <v6ops@ietf.org>; Sat, 17 Dec 2011 01:52:40 -0800 (PST)
Received: by 10.180.95.136 with SMTP id dk8mr12616269wib.11.1324115560400; Sat, 17 Dec 2011 01:52:40 -0800 (PST)
Received: from ams-townsley-8717.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id et20sm17726831wbb.15.2011.12.17.01.52.38 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 17 Dec 2011 01:52:39 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary="Apple-Mail-15-63490491"
From: Mark Townsley <mark@townsley.net>
In-Reply-To: <DCC302FAA9FE5F4BBA4DCAD4656937791736C4719D@PRVPEXVS03.corp.twcable.com>
Date: Sat, 17 Dec 2011 10:52:37 +0100
Message-Id: <EC9AE40C-F92B-47D9-AA22-E1606640FABD@townsley.net>
References: <D61C0046-1B8D-4941-988F-F183CA10D0F4@townsley.net> <DCC302FAA9FE5F4BBA4DCAD4656937791736B134AF@PRVPEXVS03.corp.twcable.com> <212E1A9D-C827-4A46-ACEB-C2D24153223E@townsley.net> <DCC302FAA9FE5F4BBA4DCAD4656937791736C4719D@PRVPEXVS03.corp.twcable.com>
To: "George, Wes" <wesley.george@twcable.com>
X-Mailer: Apple Mail (2.1084)
Cc: "v6ops@ietf.org Operations" <v6ops@ietf.org>
Subject: Re: [v6ops] Up-leveling Transition Coexistence
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 17 Dec 2011 09:52:42 -0000

On Dec 16, 2011, at 10:52 PM, George, Wes wrote:

>> From: Mark Townsley [mailto:mark@townsley.net]
>> Sent: Friday, December 16, 2011 10:36 AM
>> To: George, Wes
>> Cc: v6ops@ietf.org Operations
>> Subject: Re: [v6ops] Up-leveling Transition Coexistence
>> 
>>> [WEG] I think you missed one...
>>> (4) no IPv4 and one Native IPv6 interface
>> 
>> Agree, but... 6204-bis currently does not enter the realm of v6-only. I
>> was working within the scope of that document in this email. That's why
>> I prefaced these 3 with:
>> 
>> "...steady-state combinations of "native" and "virtual" (tunneled)
>> dual-stack connectivity methods"
>> 
> [WEG] The scope of this whole discussion is a bit unclear to me, for 2 reasons - I haven't been closely following the 6204-bis mega thread, and I saw you make reference to several new drafts in your original message. It sounded to me like you were talking about abstracting transition coexistence a bit from the discussion of 6204-bis that it's currently mired in, which is why I pointed to this as being missing. I'm not saying that it has to be totally covered in 6204-bis, merely that any serious discussion about IPv4/IPv6 transition and coexistence needs to consider this its end state. I'm open for discussion on what the next step is in that regard, but I'm going to continue pointing at places where IPv6-only is not being considered so that it doesn't get missed in the discussion.

Perfectly reasonable, and you'll get no objection from me that IPv6-only needs to be addressed. The practical corollary of course is that we really know what is going to work and break when we try to turn off IPv4. It's not something many people have done :-)

I'm not sure what the fate of 6204-bis is in terms of the transition coexistence section. A the moment, it seems it will still include 6rd and DS-Lite requirements, but there is really no advice on how to make these work with their Native equivalents as you either have to include multihoming or figure out how to enforce only allowing one egress at a time. For 6rd, that means you can turn on IPv6 service over your IPv4 network, but if you turn on Native IPv6 at the same time 6204-bis is insufficient. For DS-Lite, it's a bit worse because it means that you can turn on IPv4 on an IPv6-only network, but turning on DS-Lite on a Dual-Stack 6204-bis will be insufficient.

Ole and I have tried to capture this problem as well as a proposed solution in our latest revision of:

http://tools.ietf.org/html/draft-townsley-troan-ipv6-ce-transitioning-02

Here, the IPv6 multihoming 6rd requirements seems fairly solid. IMHO, it would be an improvement to include them in 6204-bis, then at least it is a complete solution that allows you to turn on IPv6 with 6rd, then Native IPv6, then turn off 6rd. 

The paint is still dry on the the IPv4 DS-Lite+ model we are proposing. The main point though is that once you bring in a new IPv4 delivery model, you can't just wave your hands and expect it to work alongside the IPv4 that's already there, or wave your hands and expect you can turn off Native IPv4 without thinking it through. 

Please have a read and let us know what you think.

Thanks,

- Mark



> 
> Thanks
> Wes George
> 
> This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.