Subject: [pcp] interim meeting notes

From: Paul Selkirk <[email-masked]>
Date: Tue, 07 Jun 2011 16:38:49 +0000

[Note: Dave has notes in the issue tracker, that may differ slightly in
language, but should reflect the same consensus decisions.]

PCP Working Group Interim Meeting, 7 June 2011

Dan Wing
Dave Thaler
Alain Durand
Felipe Miranda Costa
Francis Dupont
Jean-Phillipe Dionne
Paul Selkirk
Stuart Cheshire

This call is to go over issues raised in the WGLC and come to closure,
so we can spin a new final draft, possibly issue a new LC if warranted.

#48: Is PEER opcode support mandatory?

Dave, Stuart: Should be mandatory to implement.
Consensus: Unless specified otherwise, all base-spec components are
mandatory to implement.

#55: MAP support mandatory or optional

Alain, Stuart: MAP should be mandatory to implement, but optional to
configure.

Francis: Making PEER mandatory but MAP optional doesn't make sense,
may be against the charter.

Stuart: Is FILTER mandatory to implement?  Having too many things
optional makes it unclear what it means to implement the spec.
Suggest mandatory to implement FILTER, mandatory to support at least
one, but acceptable to support only one.

Stuart: Not sure who's going to use it. If a client can't depend on
it being there, it has to do its own source filtering.  OTOH, it's an
optimization that keeps unwanted traffic away in the first place.

Paul: We can justify putting the minimum at one filter; if we try to
set a minimum greater than one, we're picking an arbitrary number that
we can't justify on engineering grounds.

#51: Mapping vs Filtering effect confusion

Dave: Somewhere in this doc needs to explain that MAP results in
EIF. PEER (without MAP) only needs APDF to support uses 7.2 (Reducing
NAT Keepalive Messages) and 7.3 (Restoring Lost Implicit TCP Dynamic
Mapping State).

Dan: For MAP, say explicitly that it creates EIM and EIF;
for PEER, say that it's implementation dependent, and no different
from what NAT does today.

Stuart: Be careful not to have feature creep in the base spec.
Let's not throw in this extra feature where we go into a partial
shutdown where new connections are denied but existing connections are
kept open.

#54: PEER creating mappings

Stuart: You can reboot an Airport, and it existing inbound connections
are restored, but not existing outbound connections, and this
asymmetry has always bothered me.
If a client wants to take advantage of this new capability, it needs
to issue a PEER request after connection.  It makes a local copy of
the NAT soft-state, which it can use to update the NAT.

Dave: Rough consensus to keep this ability.  Update pseudocode, add
language that PEER has no effect on filtering state.

#49: Multihoming confusion

Dave: "Multihoming" encompasses multiple address families, multiple
addresses in one address family, multiple default routers, and
multiple PCP servers.

Alain: We talked about this in relation to Zone ID.  When we removed
it, we decided to leave all multihoming discussion out of the base spec.

Dave: At least some of this needs to be specified.

Stuart: By analogy to DHCP, if there are multiple PCP responses,
client picks the "best" response, but in practice picks the first
response.

Dave: In this case, the base spec shouldn't specify a "list" at all.

Stuart: The DHCP extension spec (or some other extension spec) should
say how the client should deal with multiple server addresses.

Dave: Base spec should assume one PCP server per AF.

#52: More security considerations

Stuart: Tighten up the wording about ingress filtering.  e.g. a HGW
serving a local LAN should only accept requests on the LAN side, not
the WAN side.  Also tighten up language around THIRD_PARTY.

Dave - add mitigation that MAP can be disabled if admin chooses, since
hole is wider than SYN can do, if SYN doesn't create EIF.
Stuart - home gateway should only accept PCP on the internal interface

#53: Make PCP Client's IP Address field optional

Paul: This is a diagnostic tool only, and there are scenarios that
won't possibly have an on-path NAT.

Stuart: The trade-off is worth the extra bytes and processing.
Apple gets lots of tech support calls around misconfigured UPnP.
Diagnostics are valuable.  More complicated to make it optional than
to put it in every packet.

#56: Handling of the "O" bit is not fully specified for clients

On the client side, all Options are truly optional; if it gets a
success response with an Option that it doesn't understand, it ignores
it, regardless of whether the "O" bit is set.

#57: THIRD_PARTY scenarios are a bit confused and self-contradictory.

Stuart: "Subscriber" is not well specified.  THIRD_PARTY seems to be
aimed at DS-Lite, without actually mentioning DS-Lite.

Dave: You only use THIRD_PARTY if you can't send the PCP request from
the IP address of the device that actually wants the mapping.

#50: 128 bit PCP Client's IP Address and Suggested External IP Address fields

Dave: Why not use IPv4-mapped IPv6 addresses?
Dan: Kill the External_AF field then.
Dan: We don't have industry consensus about whether mapped addresses
can appear on the wire.
Alain: AF fields create corner cases and complexity that we can live
without; remove them.

Stuart: Putting an IPv4 address as the first 32 bits of a 128-bit
field could be misinterpreted as a v6 prefix.  Putting a v4 address as
the last 32 bits makes it a deprecated-form mapped address.  Make it a
current-form mapped address, with leading ::FFFF/96, and it's
unambiguous.

Consensus to make all address fields 128-bit fixed fields, remove AF
fields.

Next steps: We have multiple editors, so need to coordinate efforts.
Paul will check in editorial nits, Dan will integrate Dave's changes.
Stuart doesn't have time this week, will work on the plane this
weekend, shooting for a deadline of next Tuesday.

Start a new one-week WGLC as soon as the next draft is issued.