15:20 Introduction Dave Thaler proposed adopting a new "Updates to PCP" WG document, for updates we have WG consensus on. Asked for comments. There were a few nodding heads; no objections. ------------------------------------ 15:30 PCP Proxy, Simon Perreault http://tools.ietf.org/html/draft-ietf-pcp-proxy-05 == Operational model for proxying unknown opcodes and options == Stuart Cheshire: Maybe differentiate between things like NAT gateways (that need to understand PCP to make local mappings) and things like routers (that forward packets without rewriting them). Tiru Reddy: With PCP authentication, client->gateway authentication might be different from gateway->ISP authentication. Simon Perreault: Why wouldn't options in packet just be passed upstream? Dave Thaler: Better precision in the wording in the document might help. Dan Wing: Risk is that a new option might be defined that can't usefully be ignored by a home gateway. Dave Thaler: Don't we have optional options? Dan Wing: We have options that are optional to process at the other end, but they make no statement about whether it's optional for intermediaries to understand them. Sam Hartman: What about new options that are handled by intermediaries but *not* understood by the far end? That case may be more common than the inverse. Back-to-back model is much clearer than forwarding proxy. With back-to-back, the server side of the back-to-back simply rejects unknown opcodes, instead of relaying them with unknown effect. Dave Thaler: Could have a "proxy behavior" option that tells proxies what to do with opcodes they don't understand. == When to terminate == Dave Thaler: Remove termination condition when device has public IP address Stuart Cheshire: Agree. Remove public address check. Having a public IP address doesn't guarantee that you're not behind a NAT gateway, and *not* having a public IP address doesn't guarantee that you *are* behind a NAT gateway. Dan Wing: Today's common termination condition is when client is behind a NAT gateway, but ISP has not yet implemented PCP capability, and the PCP client times out. == Unknown opcodes and options Ted Lemon: Might there be privacy concerns in forwarding unknown opcodes and options that may contain information that should not be leaked? Stuart Cheshire: Remove language about making behaviour for handling unknown opcodes and options be configurable. Any clear decision, even a bad one, is better than no decision. Better if all intermediaries are doing the same thing than having some do one thing and some do another. ------------------------------------ 15:50 PCP Authentication, Dacheng Zhang http://tools.ietf.org/html/draft-ietf-pcp-authentication-03 Tiru Reddy: What is Key ID for? Dacheng Zhang: Because the key can change. Dan Wing: How often does the key change? Do we need a 32-bit Key ID? 8-bit? None at all? Sam Hartman: Need 1-bit (two keys: the one I'm using, and the one I'm going to use). Dan Wing: What is typical lifetime? Sam Hartman: Greater than the life of the server. Dan Wing: Then why not get rid of Key ID? Stuart Cheshire: If there are two keys in use only very occasionally, then the server can just try both. Sam Hartman: Stuart's suggestion is probably okay; I need to think about it. Dave Thaler: Conclusion: Remove Key ID from draft; can put it back later if we decide we do need it after all. Dan Wing: Please make sure the ladder diagram in the document is annotated with sequence numbers. ------------------------------------ 16:05 PCP Anycast, Sebastian Kiesel http://tools.ietf.org/html/draft-ietf-pcp-anycast-01 Sebastian presented summary of changes Question? Removed appendices about alternative discovery methods and discussion of anycast Stuart Cheshire: Appendices Simon Perreault: There are IPv4 and IPv6 anycast addresses. Which to use? Dave Thaler: Reference Server Selection document Sam Hartman: For reference, with Amazon's services today, you ask for a v6 external port using a REST protocol over v4. It's conceivable they could in future support requesting v6 ports using PCP over v4 in a similar way. ------------------------------------ 16:20 PCP Extension for Third Party Authorization, Tiru Reddy http://tools.ietf.org/html/draft-wing-pcp-third-party-authz-02 Stuart Cheshire: Getting adoption may be a struggle. Why would sites use a blocking mechanism that no apps currently support? Why would app vendors adopt a mechanism to circumvent a blocking mechanism when no sites are currently using the blocking mechanism or supporting the circumvention mechanism? ------------------------------------ 16:35 PCP Support for Multi-Homing/Egress NATs, Zhangzhan (Channy) List discussion around http://tools.ietf.org/html/draft-penno-pcp-zones-01 Current state without pcp-zones is that PCP server with multiple egress networks must present itself to its clients as multiple PCP servers. ------------------------------------ 16:45 PCP Tunnel ID Option, Rolf Winter http://tools.ietf.org/html/draft-ripke-pcp-tunnel-id-option-00 Dave Thaler: Is this DS-Lite specific? And if so, should DS-Lite draft take a normative dependency on this? Some discussion that this might be needed outside of DS-Lite. Dan Wing: No. Not all DS-Lite providers will even want a manual port mapping portal, so this is not required for DS-Lite PCP to work. Ed Lopez (Fortinet): I like the idea of things being automatic. Our CPEs support neither UPnP nor PCP (yet), but I'm hoping that will change. Stuart Cheshire: PCP was designed for DHCP-like automatic configuration. Permanent manual configuration may be better achieved using some other protocol more suited to that. By analogy, people do not use a manual DHCP tool to obtain an address to be statically configured into a device that doesn't support DHCP. They either get a device that supports DHCP, or they obtain a static address for the device via other means outside of DHCP. They don't try to turn the Dynamic Host Configuration Protocol into the Static Host Configuration Protocol. ------------------------------------ 17:00 Airport Extreme Interop Test Report, Stuart Cheshire Authors not present. Stuart Cheshire ran through the slides giving his observations on what appeared to be the noteworthy information. Stuart expressed his pleasure (or relief) that they reported Apple's PCP implementation as: "Solid, no major issues". ------------------------------------