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

["Hemant Singh (shemant)" <[e-mail]>]

DS-Lite folks,

 

Both you and Barbara have said rfc6204bis has to be out ASAP including
shooting for an RFC by end of this year.   Cmon, now, Barbara is on PTO
and she's had to reply during her time off!   PCP has issues if PCP does
not support REC-48 from RFC 6092.   I agree with Barbara.  If PCP will
delay rfc6204bis due to DS-Lite, we have no choice but to yank out
DS-Lite too.   We have guidance from the v6ops Chair to send the
document to the IESG ASAP.   We are already one month behind.    What is
it going to be?  DS-Lite included with no PCP or DS-Lite out since PCP
just is not near closure?    This thrashing has to stop. 

 

Hemant

 

From: [e-mail] [mailto:[e-mail]] On Behalf
Of STARK, BARBARA H
Sent: Tuesday, October 18, 2011 5:43 PM
To: Weil, Jason; james woodyatt; IPv6 Operations
Cc: [e-mail]
Subject: 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:[e-mail]] 
Sent: Tuesday, October 18, 2011 5:11 PM
To: james woodyatt; IPv6 Operations
Cc: [e-mail]; [e-mail];
[e-mail]
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: [e-mail] [mailto:[e-mail]] On Behalf
Of james woodyatt
Sent: Tuesday, October 18, 2011 2:41 PM
To: IPv6 Operations
Cc: [e-mail]; [e-mail];
[e-mail]
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 <[e-mail]>

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.