Helsinki 00930 Finland markus.stenberg@iki.fi

PCP Proxy Homenet This document describes a minimalist PCP proxy function needed within the homenet architecture. It is notably a subset of a general PCP proxy.

This is mostly discussion fodder; I _personally_ find current PCP proxy defined in overcomplex for Homenet needs. So I'm defining Minimalist PCP Proxy (MPP) here instead. A GPLv2-licensed experimental and probably still incorrect sample implementation of MPP is currently under development at https://github.com/fingon/minimalist-pcproxy/ . Comments and/or pull requests are welcome.

In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL", "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as described in .

Homenet architecture defined in allows for multihoming -> multiple PCP servers MUST be supported. Notably, the PCP server choice MUST depend on the source address used by the client. IPv4 is not yet gone -> dual-stack PCP SHOULD be supported. Proposed homenet prefix assignment algorithm defined in assumes only zero or one upstream IPv4 links, NATted to a single IPv4 prefix. The amount stored state SHOULD be minimal. MPP SHOULD also have as simple as possible implementation for both footprint and correctness validation reasons.

Each first-hop router in a Homenet runs this algorithm. Each router with upstream connectivity additionally runs a real PCP server, but on an IP address that is not provided to any clients (TBD or just some weird port#? We're among consenting routers here after all..). is used to maintain the information about upstream connections for the running MPP instances, and therefore normal PCP server selection is not needed.

In addition to the local definition of epoch, for each server, following information is stored and updated as needed: Source IP prefix and length to match. Remote IP address of the server.match. Remote epoch tracking (prev_server_time, prev_client_time as per ).

The MPP defined here is only a subset of what official PCP proxy draft covers. However, it also is MUCH simpler to implement and define. Notable limitations include: This scheme cannot be used on PCP proxy nodes that actually perform NAT. In case of firewalling, or forwarding, it should work. This is because original destination address client used to contact the local proxy is reused, to store it for later forwarding the response back to the client. If NAT occurs, this is not possible. MPPs cannot be cascaded. MPPs may be hard to adapt to real server selection in non-Homenet environments (TBD).

Next behavior of MPP is described. MPP MUST have both PCP client and PCP server ports open.

On local epoch reset (when MPP is started, or based on detected epoch reset at one of the servers as defined in ), MPP SHOULD send unsolicited multicast ANNOUNCEs as specified in .

Just provide a direct response (given internal interface + local IP), as specified in . Otherwise, ignore.

On receipt of a PCP request on an internal interface on the PCP server port, MPP behaves as follows: Check if the source IP address and the PCP client IP Address are the same. If a mismatch is detected, the behavior specified in must be followed. Check that for the client's source IP address, there exists a PCP server responsible for it within the local configuration. If not, TBD (error, but which one). If THIRD_PARTY is already set, consider the request rejected. If the request is rejected, build an error response and send it back to the PCP client. The error status code is set to NOT_AUTHORIZED. If the request is accepted, adjust it (e.g., adding a THIRD_PARTY Option, updating the PCP client IP Address to the adddress client used when contacting the proxy) and forward it from local client port with the source address matching the IP address in the adjusted request.

On receipt of a PCP response on the PCP client port, MPP behaves as follows: Check that source IP matches one of the PCP servers, and that the source port matches PCP server port. If not, silently drop the packet. Check that THIRD_PARTY option is present, and store it for future use. If it is not present, or not in a locally connected prefix, silently drop the packet. Ensure that the per-server epoch is valid per . If not, reset local epoch. Adjust the epoch in the response to local epoch. Send the request forward to the client, with source address matching the original destination address, the destination address matching the address within the removed THIRD_PARTY option, and from the local server port to the remote client port.

As usual, this draft is available at https://github.com/fingon/ietf-drafts/ in source format (with nice Makefile too). Feel free to send comments and/or pull requests if and when you have changes to it!

The algorithm text is adapted from draft-ietf-pcp-proxy-04 Section 8. It is unfortunately gone from the more recent iterations.