Re: [v6ops] new draft: draft-ietf-v6ops-6204bis

"STARK, BARBARA H" <bs7652@att.com> Wed, 19 October 2011 20:59 UTC

Return-Path: <bs7652@att.com>
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 BED1311E80B4 for <v6ops@ietfa.amsl.com>; Wed, 19 Oct 2011 13:59:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.397
X-Spam-Level:
X-Spam-Status: No, score=-106.397 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 yzPOb2GyxPAH for <v6ops@ietfa.amsl.com>; Wed, 19 Oct 2011 13:59:02 -0700 (PDT)
Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by ietfa.amsl.com (Postfix) with ESMTP id 1C9B711E80A5 for <v6ops@ietf.org>; Wed, 19 Oct 2011 13:59:01 -0700 (PDT)
X-Env-Sender: bs7652@att.com
X-Msg-Ref: server-14.tower-119.messagelabs.com!1319057939!45431633!1
X-Originating-IP: [144.160.20.146]
X-StarScan-Version: 6.3.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21993 invoked from network); 19 Oct 2011 20:59:00 -0000
Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-14.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 19 Oct 2011 20:59:00 -0000
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p9JKvZCJ029858; Wed, 19 Oct 2011 16:57:37 -0400
Received: from 01GAF5142010623.AD.BLS.COM (01GAF5142010623.ad.bls.com [139.76.131.87]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with SMTP id p9JKvA7P029189; Wed, 19 Oct 2011 16:57:10 -0400
Received: from 01NC27689010626.AD.BLS.COM ([90.144.44.201]) by 01GAF5142010623.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.4675); Wed, 19 Oct 2011 16:57:46 -0400
Received: from 01NC27689010650.AD.BLS.COM ([90.144.44.120]) by 01NC27689010626.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.4675); Wed, 19 Oct 2011 16:57:46 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC8EA1.C0B4E44E"
Date: Wed, 19 Oct 2011 16:58:29 -0400
Message-ID: <750BF7861EBBE048B3E648B4BB6E8F4F2012AB59@crexc50p>
In-Reply-To: <94C682931C08B048B7A8645303FDC9F35A2DDC091B@PUEXCB1B.nanterre.francetelecom.fr>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [v6ops] new draft: draft-ietf-v6ops-6204bis
Thread-Index: AcyNxXLGzPhIt8uRQE2ONYAe3RKZWwAEw7VAAADuEEAAF2kCQAAY3jHA
References: <201110111355.p9BDt1M23806@ftpeng-update.cisco.com><282BBE8A501E1F4DA9C775F964BB21FE3EB758B7A8@GRFMBX704BA020.griffon.local><1B8E4C5A-D08B-4F37-B701-A39745136A33@cisco.com><750BF7861EBBE048B3E648B4BB6E8F4F1FDCA4C3@crexc50p><282BBE8A501E1F4DA9C775F964BB21FE3EB758B7AB@GRFMBX704BA020.griffon.local><B06E5723-1EE5-4808-AE7F-3D98EB3F17CE@cisco.com><94C682931C08B048B7A8645303FDC9F35A2DDC07B7@PUEXCB1B.nanterre.francetelecom.fr><5B6B2B64C9FE2A489045EEEADDAFF2C303130A41@XMB-RCD-109.cisco.com><94C682931C08B048B7A8645303FDC9F35A2DDC0801@PUEXCB1B.nanterre.francetelecom.fr><5B6B2B64C9FE2A489045EEEADDAFF2C303130AAE@XMB-RCD-109.cisco.com><A29A998E-658F-4265-95C7-2B27EF160EEE@apple.com><839CD7F7A30CF149B5FE4D908ADE00A139FBFBBBD0@PRVPEXVS08.corp.twcable.com> <750BF7861EBBE048B3E648B4BB6E8F4F2008CD2A@crexc50p> <94C682931C08B048B7A8645303FDC9F35A2DDC091B@PUEXCB1B.nanterre.francetelecom.fr>
From: "STARK, BARBARA H" <bs7652@att.com>
To: mohamed.boucadair@orange.com, "Weil, Jason" <jason.weil@twcable.com>, james woodyatt <jhw@apple.com>, IPv6 Operations <v6ops@ietf.org>
X-OriginalArrivalTime: 19 Oct 2011 20:57:46.0297 (UTC) FILETIME=[C0D51290:01CC8EA1]
Subject: Re: [v6ops] new draft: draft-ietf-v6ops-6204bis
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: Wed, 19 Oct 2011 20:59:07 -0000

Hey Med,

There are many things that service providers make mandatory on routers they procure and provide to customers, that are not necessarily found on retail CE routers. Given your answer, my questions would be (1) Do you expect to allow customers to use their own CE router that they purchase at retail, that is not associated with your service, and (2) if so, would you tell customers that support for PCP in such retail-purchased routers is mandatory - they will not be allowed to connect, or the DS-Lite service won't work right, if there is no PCP support in the CE router.

 

The 6rd requirements that I'm pushing for are such that the service may not work (i.e., non-functioning or broken IPv6 connectivity via 6rd) if the requirements aren't implemented. That's why they're so important to me. I really have a hard time believing that this is true of PCP (WAN, LAN, or wherever) in the context of DS-Lite.

Barbara

 

From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] 
Sent: Wednesday, October 19, 2011 4:39 AM
To: STARK, BARBARA H; Weil, Jason; james woodyatt; IPv6 Operations
Cc: pcp-chairs@tools.ietf.org
Subject: RE: [v6ops] new draft: draft-ietf-v6ops-6204bis

 

Dear Barbara,

 

Speaking for our own DS-Lite deployment, PCP is mandatory to have. This is something we made clear to our DS-Lite vendors. Some of them support already PCP (based on version -13). 

 

Cheers,

Med

 

________________________________

De : v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] De la part de STARK, BARBARA H
Envoyé : mardi 18 octobre 2011 23:43
À : Weil, Jason; james woodyatt; IPv6 Operations
Cc : pcp-chairs@tools.ietf.org
Objet : Re: [v6ops] new draft: draft-ietf-v6ops-6204bis

In the 6204bis document, I'm only willing to consider the UPnP proxy + WAN-side PCP. There are so many other uses of PCP, that I think it would drag us down a rat-hole to try to specify all the other places where PCP would need to be supported. And since there's no indication as to level of support of PCP in LAN devices, I can't support its recommendation at this time for LAN-side use. That needs to be a homenet topic. But I'd only support this PCP requirement if PCP really were ready to become an RFC. And it sounds like it isn't anywhere near to being ready. It sounds like there are people who feel like there are a number of issues to address.

 

I need 6rd now. If 6204bis is going to be hijacked by those who want to describe all possible uses of PCP and insist on waiting for all issues around PCP to be resolved, then let's just forget about it, and let me figure out some non-IETF way to get out the message for 6rd. If others want to wait a year or two to do some comprehensive transition technology document, then y'all have at it. I've got more pressing matters to deal with (like getting the word out now on 6rd). It sounds like there's also a need to get out the word out on DS-Lite requirements. I'm happy to include DS-Lite with 6rd, because DS-Lite has stable RFCs. But if PCP is an absolute requirement for DS-Lite (WAN-side? LAN-side? simple-security? NAT46? NAT64? NAT44? - I really wish proponents of PCP would be extremely specific as to which aspect of PCP they need, because when they aren't specific, I can only assume they want it all, which I'm not ready to support), then I'm not happy to include DS-Lite. Because (1) if there's a need for all LAN clients to support PCP or UPnP in order for DS-Lite to be usable, then DS-Lite must be a long way off, and (2) it sounds like publication of a PCP RFC is a long way off.

 

My question to the DS-Lite proponents is:

Would you support DS-Lite requirements in a 6204bis without PCP requirements?

 

If your answer is "No", then I think it's time for me to get 6rd requirements published elsewhere. I've wasted too much time with the expectation that IETF would be a good venue for these 6rd CE router requirements, so I'd really like for there to be a decision soon.

Barbara

 

From: Weil, Jason [mailto:jason.weil@twcable.com] 
Sent: Tuesday, October 18, 2011 5:11 PM
To: james woodyatt; IPv6 Operations
Cc: pcp-chairs@tools.ietf.org; draft-ietf-pcp-base@tools.ietf.org; draft-ietf-v6ops-6204bis@tools.ietf.org
Subject: RE: [v6ops] new draft: draft-ietf-v6ops-6204bis

 

Fwiw my only interest in PCP today is to satisfy REC-48 type functionality in a native Dual-stack CPE Router with an IPv6 firewall enabled. We are specifying RFC6092 functionality today for home gateways and the two options on the table to allow applications to signal their requirements to firewall are (I thought) PCP and UPnP.  If PCP isn't ready to do this functionality fairly soon then it is becomes mostly  useless in my book and I will have to look elsewhere for that functionality. If it is close and we can get it included in 6204bis, it would make sense to wait for it. 

 

Thanks,

 

Jason 

 

From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of james woodyatt
Sent: Tuesday, October 18, 2011 2:41 PM
To: IPv6 Operations
Cc: pcp-chairs@tools.ietf.org; draft-ietf-pcp-base@tools.ietf.org; draft-ietf-v6ops-6204bis@tools.ietf.org
Subject: Re: [v6ops] new draft: draft-ietf-v6ops-6204bis

 

On Oct 18, 2011, at 10:33 AM, Hemant Singh (shemant) wrote:

	 

	 But the PCP base document needs to become a RFC ASAP

 

The current revision, I-D.ietf-pcp-base-14 is unsuitable for the purposes described in REC-48 of RFC 6092, in my opinion.  I'm hoping that the forthcoming -15 revision will be acceptable, but I don't actually see it on the server yet, and some of the more authoritative participants in the working group are balking at being asked to consider a new revision of the draft.

 

One of the things that would help here is for the PCP working group to stop thinking that their job is done after they specify how ports are mapped for translation and address amplification with NAT44 and NAT64 and to start remembering that their draft actually purports to explain how PCP can meet REC-48 of RFC 6092 as well.  Every time I bring up a point that shows how their draft falls down on that point, they complain that nobody cares about IPv6 CPE routers, or transports other than TCP and UDP, or this, that or the other thing, and tell me they plan to fix it in the next round of RFC development.  Fortunately, the chair and the technical editor of the draft seem to be paying attention to the problems, but I do *NOT* feel at all comfortable that the community of PCP implementers is ready to consider simple security in IPv6 CPE routers.

 

I am very concerned that IPv6 CPE router vendors will rush out devices that contain early reference implementations of PCP, because it is standards track, but have simple security functions that are *MUCH* less transparent than the Informational category RFC 6092 recommends.  If this happens, then PCP servers in these ubiquitous and sure-to-never-be-upgraded home gateways will establish a conventional restriction on the transparency of IPv6 residential service that unnecessarily mimics the brokenness of IPv4/NAPT.  We should endeavor to avoid the possibility of a disaster like that, if at all possible, and I'm sensing a significant resistance to that concern among an influential cadre of PCP working group participants and implementers.

 

Therefore, I'd prefer that any update to RFC 6204 either wait for PCP to be revised appropriately in a second RFC, or that it not contain any recommendation for a PCP server at all.  Alternatively, the stakeholders in RFC 6204 could engage more directly with the PCP working group, so that Keith Moore and I are not the only ones speaking up in the defense of your interests.

 

 

--

james woodyatt <jhw@apple.com>

member of technical staff, core os networking

 

 

 

________________________________

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.