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

["Reinaldo Penno (repenno)" <[e-mail]>]

Hi,

Inline with [RP]

From: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, September 10, 2013 1:27 AM
To: james woodyatt <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]> WG" <[e-mail]<mailto:[e-mail]>>
Cc: Cisco Employee <[e-mail]<mailto:[e-mail]>>
Subject: RE: [v6ops] PCP and I-D.ietf-v6ops-mobile-device-profile

Hi James,

I appreciate your effort for reading and raising a technical point. I really don’t care if you shared this comment during the WGLC or now once the IETF LC is over.

Some general answers:

* This document does not aim to provide a static picture of what current implementations are doing but we are listing also features to ease adoption of the IPv6-only model. For this reason, there is a list of feature that are needed for that model: these recommendations are all SHOULD ones and not MUST. FWIW, the document included some details on broken implementations and tests but that text was removed as suggested by some reviewers. The document is not intended to ACK the current broken implementations but to list of features to have more and more implementations that can be connected in IPv6-only and DS modes without service degradation.

* The feature of retrieving the PREFIX64 using PCP has been implemented and tested (see for example http://tools.ietf.org/html/draft-boucadair-pcp-nat64-experiments-00)

* Motivations for PCP from a provider perspective are mentioned in the document. No need to re-iterate that. From a customer standpoint, some users are using their mobile connection as their main line. As such, they have the same requirements as for fixed services. I have been told that there are customers running game consoles using their mobile connection (If I’m not mistaken, Reinaldo has mentioned this case in an e-mail. I will let him confirm/infirm).

[RP] Right, FWIW in US there are wireless subscriber (LTE/4G) that do not have wireline internet. They use (and expect) this high speed wireless to carry traffic usually associated with wireline deployments. The case through a Wireless provider was related to subscribers that want to use XBOX through 4G/LTE.


* The document includes the following:

   Some of the features listed in this profile document require to
   activate dedicated functions at the network side.  It is out of scope
   of this document to list these network-side functions.

* Some operators have included PCP as a requirement for their NAT64 in the context of ongoing RFPs. For those  operators, the client-side functionality is needed.

Cheers,
Med


De : [e-mail]<mailto:[e-mail]> [mailto:[e-mail]] De la part de james woodyatt
Envoyé : lundi 9 septembre 2013 17:59
À : [e-mail]<mailto:[e-mail]> WG
Objet : [v6ops] PCP and I-D.ietf-v6ops-mobile-device-profile

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<http://tools.ietf.org/html/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<http://tools.ietf.org/html/draft-ietf-v6ops-mobile-device-profile-05#ref-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<http://tools.ietf.org/html/draft-ietf-v6ops-mobile-device-profile-05#ref-I-D.ietf-behave-nat64-discovery-heuristic>] to

           retrieve the PREFIX64.


REQ#15:  The cellular host SHOULD support PCP [RFC6887<http://tools.ietf.org/html/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]<mailto:[e-mail]>>
core os networking