[v6ops] PCP and I-D.ietf-v6ops-mobile-device-profile

[james woodyatt <[e-mail]>]

everyone—

I haven’t prepared an exhaustive criticism of this draft, but I do have one concern in particular I would like to highlight. The recommendations (for they are not requirements) REQ#12 and REQ#15 discussing matters related to the Port Control Protocol (PCP) and traversal of NAT and firewalls is troubling to me.

REQ#12:  The cellular host SHOULD support a method to locally
        construct IPv4-embedded IPv6 addresses [RFC6052].  A method to
        learn PREFIX64 SHOULD be supported by the cellular host.

           This solves the issue when applications use IPv4 referrals on
           IPv6-only access networks.

           In PCP-based environments, cellular hosts SHOULD follow
           [I-D.ietf-pcp-nat64-prefix64] to learn the IPv6 Prefix used
           by an upstream PCP-controlled NAT64 device.  If PCP is not
           enabled, the cellular host SHOULD implement the method
           specified in [I-D.ietf-behave-nat64-discovery-heuristic] to
           retrieve the PREFIX64.

REQ#15:  The cellular host SHOULD support PCP [RFC6887].

           The support of PCP is seen as a driver to save battery
           consumption exacerbated by keepalive messages.  PCP also
           gives the possibility of enabling incoming connections to the
           cellular device.  Indeed, because several stateful devices
           may be deployed in wireless networks (e.g., NAT and/or
           Firewalls), PCP can be used by the cellular host to control
           network-based NAT and Firewall functions which will reduce
           per-application signaling and save battery consumption.

It seems to me that these recommendations are only worth following if there are to be PCP servers in *all* of the network elements in the paths between cellular hosts and the default free zone that implement stateful firewall (and NAT) functions.  Indeed, in at least one common cellular host architecture, there is a stateful filter in the baseband chipset firmware that blocks all inbound packets that it decides are unsolicited by applications on the main system CPU. There is no PCP service in those chipset firmware implementations, and no practical way to turn off the filtering, because it is tied up with tricky power consumption issues, and without either of those things, there is pretty much no good reason to implement a PCP client on the main system CPU. It does not matter whether there are PCP servers in the firewalls further upstream, if there is a firewall in the baseband chipset that you can’t disable or control.

I recommend dropping these recommendations and replacing them with text that recognizes the present reality that cellular hosts are simply not expected ever to receive unsolicited inbound connection flows from arbitrary remote Internet addresses. It would simplify the document and it would be a more honest appraisal of the situation.


--
james woodyatt <[e-mail]>
core os networking