RE: 3gpp-analysis-05: miscellaneous non-critical issues

[<juha.wiljakka@nokia.com>]

Hi,

comments (JW) below:

-----Original Message-----
From: ext Pekka Savola [mailto:pekkas@netcore.fi]
Sent: 18 September, 2003 11:45

The second set of comments.  All of these seem rather straightforward, and 
there should relatively easy fixes to the problems.

semi-substantial:
-----------------

 2.1 Dual Stack

    The dual IPv4/IPv6 stack is specified in [RFC2893]. If we consider
    the 3GPP GPRS core network, dual stack implementation in the GGSN
    enables support for IPv4 and IPv6 PDP contexts. UEs with dual stack
    and public (global) IP addresses can often access both IPv4 and
    IPv6 services without additional translators in the network.

==> I fail to see why public (global) IP addresses are a requirement here? 
Can't one with a private address also access IPv4 services, possibly with
some difficulties, yes, but still in principle..

 JW: Maybe public/global addresses need not be mentioned here. I just
wrote it because the ideal case would be to have public/global addresses.
I could add a sentence clarifying that if UEs need to be contacted (e.g. 
thinking peer-to-peer services), public/global addresses would be needed /
preferred.

    A translator can be defined as an intermediate component between a
    native IPv4 node and a native IPv6 node to enable direct
    communication between them without requiring any modifications to
    the end nodes.

==> "native" in the above seem unnecessary?

 JW: Can be removed.

==> I'm not sure if "without requiring any modifications" is a strict goal
here, for protocol translator to be valid.  Suggest rewording to something
like:

    A translator can be defined as an intermediate component between an
    IPv4(-only) node and an IPv6(-only) node to enable direct
    communication between them without requiring to enable dual-stack
    connectivity in either, with minimal, if any, modifications to
    the end nodes.

 JW: Sounds good.

 2.4 DNS Guidelines for IPv4/IPv6 Transition

==> this is referred often from the GPRS transition scenarios and from the
IMS scenario.  However, it is may not be entirely apparent how exactly that
applies there -- i.e., how we recommend the DNS services be deployed (or how
we recommend they NOT be deployed) in the different 3GPP scenarios.

That is, are there any 3GPP-specific (or -related) guidelines to the DNS
deployment to add either here or under the GPRS/IMS sections, in addition to
the generic guidelines of [DNStrans] ?

 JW: I will think about it and return, if I can find some specific requirements.

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

==> the last sentence sounds a bit funny, consider rewording to something
like:

                                               If IPv6 PDP contexts are
    available, it is recommended to activate the IPv6 PDP context instead of
    just enabling an IPv4 PDP context and performing IPv6-in-IPv4 tunneling
    in the UE.  This case is described in more detail in section 3.2.

 JW: This sounds rational.

    As a general guideline, IPv6 communication (native or tunneled from
    the UE) is preferred to IPv4 communication going through IPv4 NATs
    to the same dual stack peer node.

==> I think this is in conflict with the text already written earlier in
this section.  I suggest:

    As a general guideline, native IPv6 communication
    is preferred to IPv4 communication going through IPv4 NATs
    to the same dual stack peer node.

 JW: I don't have any complaints.

...

    When analyzing a dual stack UE behavior, an application running on
    a UE can identify whether the endpoint required is an IPv4 or IPv6
    capable node by examining the address to discover what address
    family it falls into. 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. Since the UE is capable of native communication with both
    protocols, 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 was a bit confused when I read this (long) paragraph.  It didn't
strike clearly to me what is the purpose or the intent of this paragraph. 
Perhaps this should be considered and reworded so that the goal of the
paragraph is clearer.

 JW: Yes...this is quite long and not so clear paragraph; I will shorten it
and make some rewording.

    network to the correct translator, there has to be an IPv4 address
    allocated for the duration of the session from the user traffic
    translator. The allocation of this address from the user traffic

==> s/allocated/allocated at least/ (this would allow more or less 
permanent allocation of IPv4 addresses, with less need for dynamicity)

 JW: Yep.

    server addresses. The authors note that the general IPv6 DNS      
    discovery problem is being solved by the IETF dnsop Working Group.

==> It is unclear whether (and to what extent) that will be "solved", so I'd
just replace "solved by" with "discussed at" so we're very close to the
mark. :-)

 JW: Well...finding a solution might be a long process. I could use "discussed
at" or "...dnsop is working on the DNS disc..."

Cheers,
	 -Juha-