RE: 3gpp-analysis-07: (semi-)editorial issues

[<juha.wiljakka@nokia.com>]

Hi, Pekka and others!

Thanks for these comments, Pekka! Finally starting to go through the rest of the comments:

-----Original Message-----
From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On
Behalf Of ext Pekka Savola

semi-substantial
----------------

 3.1 Dual Stack UE Connecting to IPv4 and IPv6 Nodes

    In this scenario, the dual stack UE is capable of communicating
    with both IPv4 and IPv6 nodes. It is recommended to activate an
    IPv6 PDP context when communicating with an IPv6 peer node and an
    IPv4 PDP context when communicating with an IPv4 peer node. If the
    3GPP network supports both IPv4 and IPv6 PDP contexts, the UE
    activates the appropriate PDP context depending on the type of
    application it has started or depending on the address of the peer
    host it needs to communicate with.

==> I think it would be useful to state that (because PDP context activation
is a time-consuming process) it might make sense to activate both PDP
context in advance, just in case they're used, as long as there are any
applications for the opened PDP context?  Maybe reword the last sentence and
add a bit:

                                                              If the
    3GPP network supports both IPv4 and IPv6 PDP contexts, the UE may
    activate the appropriate PDP context depending on the type of
    application it has started; it may also make sense to open both PDP
    contexts in advance, before they are used, because the activation of
    a context may take a relatively long time.

.. somehow I don't think activating PDP context based on the peer address is
a realistic option right?

JW: in later discussion (Karim, Pekka, et co), this was the text suggested: 

    "If the 3GPP network supports both IPv4 and IPv6 PDP contexts, the UE may
    activate the appropriate PDP context depending on the type of
    application it has started; it may also make sense to open both PDP
    contexts in advance, before they are used, because the activation of
    a context may take a relatively long time.  However, if 
    the appropriate PDP context has not been activated before trying to 
    communicate with a peer, the application may trigger the activation of 
    the required PDP context type."

Only thing that somehow worries me is activating PDP contexts that may not be needed, i.e. extra usage of network resources. Should we add some note on that, e.g. draft-elmalki-sipping... states that

" Another important requirement is to minimize the number of active PDP
   Contexts a host has on any given time. A reason for this is that
   there are practical constraints on the number of PDP Contexts which a
   3GPP host may establish. If a host uses many PDP Contexts it consumes
   extra resources in the 3GPP network. That is because each PDP Context
   requires a state to be maintained in the 3GPP network. In addition,
   each PDP Context would normally require radio signaling and a new
   radio channel to be established to the 3GPP host. Therefore each
   additional PDP Context also consumes extra radio resources required
   to establish the radio channel. For these reasons, any transition
   solution should support the case where a 3GPP host utilises only one
   IPv6 PDP Context, without the need to activate additional IPv4 PDP
   Contexts."


                                             If IPv6 PDP contexts are
    available and IPv6-in-IPv4 tunneling is needed, it is recommended
    to activate an IPv6 PDP context and perform tunneling in the
    network. This case is described in more detail in section 3.2.

==> I don't understand this at all.  If IPv6 PDP context is available, it is
available natively.  The UE doesn't know about v6-in-v4 tunneling in the
first place.  So, isn't there some confusion here?  Or did the text mean to
say something like, "If both v6 or v4 can be used, v6 should be preferred"? 
Not sure if that's needed, but if so, consider e.g.:

    If an application can use both IPv4 and IPv6, and IPv6 PDP contexts are
    available, it is preferable to try IPv6 communication first.

... but this is already stated in the "As a general guideline..."
-paragraph, so seems redundant?

JW: The current text is just saying that if IPv6 PDP contexts are available and IPv6-in-IPv4 tunneling is still needed somewhere between the UE and its peer node, it is better to activate IPv6 PDP context and do the tunneling in the network (instead of activating IPv4 PDP context and making tunneling in the UE). Anyway, the suggested way to go is not visible to the terminal at all, and communciation looks like native IPv6 communication to it.


    An application running on a UE can identify whether the endpoint is
    an IPv4 or IPv6 capable node by examining the destination address.
    Alternatively, if a user supplies a name to be resolved, the DNS
    may contain records sufficient to identify which protocol should be
    used to initiate the connection with the endpoint. In dual stack
    networks, one of the main concerns of an operator is the correct
    address space and routing management. The operator must maintain
    address spaces for both protocols. Public IPv4 addresses are often
    a scarce resource for the operator and typically it is not possible
    for a UE to have a globally unique IPv4 address (continuously)
    allocated for its use. Use of private IPv4 addresses means use of
    NATs when communicating with a peer node outside the operator's
    network. In large networks, NAT systems can become very complex,
    expensive and difficult to maintain.

==> I don't see a direct relation of this paragraph to the recommendations
in this document: the first part describes (incorrectly) how to get the
address of the peer; the second part describes dual-stack considerations;
the last part describes IPv4 NAT's. I suggest removing it.  The one thing
that may make to preserve in some form is that the 3GPP operators typically
use the private IPv4 addresses.

JW: Yep, rewording and text removal looks necessary. The first part can be removed, but I would like to retain some description on private address spaces and NAT. That should be described in our document (at least as a motivation to start to use IPv6).

semi-editorial
--------------

    can typically access both IPv4 and IPv6 services without additional
    translators in the network. However, it is good to remember that
    public IPv4 addresses are a scarce resource and in many cases IPv4
    NATs are deployed. Public/global IP addresses are also needed for
    peer-to-peer services: the node needs a public/global IP address

==> s/a scarce resource/hard to come by/
(they aren't really scarce as such, but it takes just a huge amount of
paperwork etc. to get them..)

JW: No problems with that kind of wording, but I still would like to keep "scarce resource" term there. If you think about the growth rate of mobile phones, it is an impossible task to get a public IPv4 address for all of them. If not today, after some time it certainly will be impossible...

 Note that this scenario is
    comparable to 6bone [6BONE] network operation.

==> remove this; 6bone is being run down for good, and no other alternative
reference is out there.  We can live without it..

JW: Ack.

 11. Changes from draft-ietf-v6ops-3gpp-analysis-06.txt

==> add here something like:

  [[ RFC-editor note: remove the section prior to publication ]]

JW: Roger.

editorial
---------

   IMS scenarios are the following:
       - UE connecting to a node in an IPv4 network through IMS
       - Two IMS islands connected via IPv4 network

==> s/via/via an/

JW: Yep.

    "In order to preserve name space continuity, the following
    administrative policies are RECOMMENDED:
      -        every recursive DNS server SHOULD be either IPv4-only or dual
         stack,
      -        every single DNS zone SHOULD be served by at least one IPv4

==> here there seem to be some odd extra spaces etc. -- cut'n'paste error?

JW: Hmm, seems to be... will fix that.

    In a 3GPP network, one IPv6 island can contain the GGSN while
    another island can contain the operator's IPv6 application servers.

==> s/can/may/ (twice) ?

JW: OK.

 As a general guideline,
    IPv6-only UEs are not recommended in the early phases of transition
    until the IPv6 deployment has become so prevalent that direct    

==> split to a new paragraph, starting from "As a gene..."

JW: OK.

    On the user data transport level, the translation is IPv4-IPv6 
    protocol translation, where the user data traffic transported is 
    translated from IPv6 to IPv4, and vice versa. 

==> there should have been an empty line before this paragraph, missing
somewhere?

JW: An editing problem, will fix that.


  Thanks,
	   -Juha-