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

[Ole Troan <[e-mail]>]

James,

>>  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.

agree, and I don't see the rush for 6204bis.
asking CPE vendors to do 6204 + 5969 + 6333 isn't any harder than making them learn yet a new RFC number.
let's shelf 6204 until we have something real to put in there.

cheers,
Ole