Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"?

[Dave Michaud <[e-mail]>]

I agree with Mohamed. The goal of the document is broader than to ensure same service set in IPv6 than in IPv4 but to provide a base set of practical requirements to actually make it happen.

As an operator, having IPv4v6, IPv6 and 464XLAT is enough to cover the simplest case (user browsing or using an app that connects to an IPv4 endpoint, while on the home network).

When you start considering roaming, tethering, migration strategy, grey market devices and service evolution, the situation becomes slightly more complex. These variables are part of the core offering and must be handled from day one. As an engineer, I will get NO support from my executives if any of the previous item is broken by one of my solutions.

In the mobile world, there are 2 classes of operator, the big ones that can get whatever configuration/personalization they want from their UE vendors and the others. For the others, having a set of common requirements goes a long way in helping immediate transition into the IPv6 world.

This is directly in line with the v6ops charter:

The IPv6 Operations Working Group (v6ops) develops guidelines for the
operation of a shared IPv4/IPv6 Internet and provides operational
guidance on how to deploy IPv6 into existing IPv4-only networks,
as well as into new network installations.

The main focus of the v6ops WG is to look at the immediate
deployment issues; more advanced stages of deployment and transition
are a lower priority.




Dave Michaud
Sr. Architect Mobility – Access Networks & IP Network Services
Network Technology | Rogers Communications
[e-mail]<mailto:[e-mail]> | tel: [phone] | mobile: [phone]


From: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Date: Thursday, February 19, 2015 at 07:13
To: Lorenzo Colitti <[e-mail]<mailto:[e-mail]>>, BINET IMT/OLN <[e-mail]<mailto:[e-mail]>>
Cc: IPv6 WG <[e-mail]<mailto:[e-mail]>>
Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"?

Hi Lorenzo,

Please see inline.

Cheers,
Med

De : v6ops [mailto:[e-mail]] De la part de Lorenzo Colitti
Envoyé : jeudi 19 février 2015 11:33
À : BINET David IMT/OLN
Cc : IPv6 Ops WG ([e-mail]<mailto:[e-mail]>)
Objet : Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"?

On Thu, Feb 19, 2015 at 1:39 AM, <[e-mail]<mailto:[e-mail]>> wrote:

[DB] Could you be more explicit and indicate which features are not useful in the draft ? As you can mention it, all features are not indicated as mandatory in the draft so I do not clearly understand how this document conflicts with what you say considering that the goal for the operator is to provide at least the same service access for users with IPv6 connectivity than for users with IPv4 connectivity whatever the strategy retained by the operator.

If the goal of the document is "to provide at least the same service access for users with IPv6 connectivity than for users with IPv4 connectivity whatever the strategy retained by the operator"

[Med] This is one of the goals of the I-D not the only one. e.g., the I-D lists features that are not covered in RFC7066 and RFC6434: e.g., prefix delegation or prefix sharing.

then you can reduce the document to two requirements:

[Med] I’m afraid compacting the recommendations is not helpful. For example, these two items are covered as follows in the I-D for the sake of deterministic behavior.

1. Support both IPv4v6 and IPv6.

[Med] These items cover this 1st point:

   C_REC#1:  In order to allow each operator to select their own
             strategy regarding IPv6 introduction, the cellular host
             must support both IPv6 and IPv4v6 PDP-Contexts [TS.23060<http://tools.ietf.org/html/draft-ietf-v6ops-mobile-device-profile-18#ref-TS.23060>].
             IPv4, IPv6 or IPv4v6 PDP-Context request acceptance depends
             on the cellular network configuration.

   C_REC#2:  The cellular host must comply with the behavior defined in
             [TS.23060<http://tools.ietf.org/html/draft-ietf-v6ops-mobile-device-profile-18#ref-TS.23060>] [TS.23401<http://tools.ietf.org/html/draft-ietf-v6ops-mobile-device-profile-18#ref-TS.23401>] [TS.24008<http://tools.ietf.org/html/draft-ietf-v6ops-mobile-device-profile-18#ref-TS.24008>] for requesting a PDP-
             Context type.  In particular, the cellular host must
             request by default an IPv6 PDP-Context if the cellular host
             is IPv6-only and request an IPv4v6 PDP-Context if the
             cellular host is dual-stack or when the cellular host is
             not aware of connectivity types requested by devices
             connected to it (e.g., cellular host with LAN capabilities
             as discussed in Section 3<http://tools.ietf.org/html/draft-ietf-v6ops-mobile-device-profile-18#section-3>):

             *  If the requested IPv4v6 PDP-Context is not supported by
                the network, but IPv4 and IPv6 PDP types are allowed,
                then the cellular host will be configured with an IPv4
                address or an IPv6 prefix by the network.  It must
                initiate another PDP-Context activation in addition to
                the one already activated for a given APN (Access Point
                Name).

             *  If the subscription data or network configuration allows
                only one IP address family (IPv4 or IPv6), the cellular
                host must not request a second PDP-Context to the same
                APN for the other IP address family.

             The text above focuses on the specification part which
             explains the behavior for requesting IPv6-related PDP-
             Context(s).  Understanding this behavior is important to
             avoid having broken IPv6 implementations in cellular
             devices.


   C_REC#3:  The cellular host must support the PCO (Protocol
             Configuration Options) [TS.24008<http://tools.ietf.org/html/draft-ietf-v6ops-mobile-device-profile-18#ref-TS.24008>] to retrieve the IPv6
             address(es) of the Recursive DNS server(s).

                In-band signaling is a convenient method to inform the
                cellular host about various services, including DNS
                server information.  It does not require any specific
                protocol to be supported and it is already deployed in
                IPv4 cellular networks to convey such DNS information.

   C_REC#4:  The cellular host must support IPv6 aware Traffic Flow
             Templates (TFT) [TS.24008<http://tools.ietf.org/html/draft-ietf-v6ops-mobile-device-profile-18#ref-TS.24008>].

                Traffic Flow Templates are employing a packet filter to
                couple an IP traffic with a PDP-Context.  Thus a
                dedicated PDP-Context and radio resources can be
                provided by the cellular network for certain IP traffic.


2. Support 464xlat.
[Med] “464xlat” is meaningless for the device;-) but I got your point. This is covered by the following two items:


   C_REC#8:  In order to ensure IPv4 service continuity in an IPv6-only

             deployment context, 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

                [RFC7225<http://tools.ietf.org/html/rfc7225>] 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

                [RFC7050<http://tools.ietf.org/html/rfc7050>] to retrieve the PREFIX64.



   C_REC#9:  In order to ensure IPv4 service continuity in an IPv6-only

             deployment context, the cellular host should implement the

             Customer Side Translator (CLAT, [RFC6877<http://tools.ietf.org/html/rfc6877>]) function in

             compliance with [RFC6052<http://tools.ietf.org/html/rfc6052>][RFC6145][RFC6146<http://tools.ietf.org/html/rfc6146>].



                CLAT function in the cellular host allows for IPv4-only

                application and IPv4-referals to work on an IPv6-only

                connectivity.  The more applications are address family

                independent, the less CLAT function is solicited.  CLAT

                function requires a NAT64 capability [RFC6146<http://tools.ietf.org/html/rfc6146>] in the

                network.



                The cellular host should only invoke the CLAT in the

                absence of the IPv4 connectivity on the cellular side,

                i.e., when the network does not assign an IPv4 address

                on the cellular interface.  Note, NAT64 assumes an

                IPv6-only mode [RFC6146<http://tools.ietf.org/html/rfc6146>].



                The IPv4 Service Continuity Prefix used by CLAT is

                defined in [RFC7335<http://tools.ietf.org/html/rfc7335>].



                CLAT and/or NAT64 do not interfere with native IPv6

                communications.







________________________________
This communication is confidential. We only send and receive email on the basis of the terms set out at www.rogers.com/web/content/emailnotice<http://www.rogers.com/web/content/emailnotice>



Ce message est confidentiel. Notre transmission et réception de courriels se fait strictement suivant les modalités énoncées dans l’avis publié à www.rogers.com/aviscourriel <http://www.rogers.com/aviscourriel>
________________________________