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

From: Pekka Savola <[email-masked]>
Date: Sat, 15 Nov 2003 14:32:21 +0200 (EET)

Hi,

Trying to give a final polish to the 3gpp analysis document, here are the 
editorial-ish modifications I wrote up.

I don't think there should be too many objections to these, so I didn't
bother to separate them out individually. More substantive ones coming..

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?

                                             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?

    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.

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..)

 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..

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

==> add here something like:

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

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/

    "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?

    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) ?

 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..."

    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?

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Jasminko Mulahusic <[email-masked]>
Date: Mon, 17 Nov 2003 10:58:56 +0100

>     available, it is preferable to try IPv6 communication first.

i don't like this 'try ipv6' paradigm. either ipv6 is there and is 
working without i need to try it, or it is not there and is not working. 
how many times do i have to try it before i will think it stinks and 
will stop trying and simply disable it and stick to ipv4?

jasminko

---

From: Pekka Savola <[email-masked]>
Date: Mon, 17 Nov 2003 12:27:59 +0200 (EET)

> will stop trying and simply disable it and stick to ipv4?

While I mostly agree with you say, could you reprase this in the sense 
that makes it clearer what you'd like to see in the document in this 
regard?

---

From: Jasminko Mulahusic <[email-masked]>
Date: Mon, 17 Nov 2003 13:47:14 +0100

> that makes it clearer what you'd like to see in the document in this 

do we have to say anything? as i see it, this is nothing special to this 
document.

if you still want something in the doc... i believe when both v4 and v6 
are available, it is up to the application to decide which one to use.

--------
If an application can use both IPv4 and IPv6, and both IPv4 and IPv6 PDP 
contexts are available, it is up to the application to make the decision 
which protocol it will use.
--------

jasminko