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

From: Pekka Savola <[email-masked]>
Date: Thu, 18 Sep 2003 11:44:37 +0300 (EEST)

Hi,

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

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

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

 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.

.. which is IMO clearer about the non-need for tunneling at the UE.  The
simpler fix could have been to just add "instead" after "tunneling in the
network", but IMO that would not have been as good.

    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.

...

    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.

    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)

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

-- 
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: <[email-masked]>
Date: Mon, 22 Sep 2003 14:14:19 +0300

Hi,

comments (JW) below:

-----Original Message-----
From: ext Pekka Savola [mailto:[email-masked]]
Sent: 18 September, 2003 11:45

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

 2.1 Dual Stack

 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.

 JW: Can be removed.

 JW: Sounds good.

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

                                               If IPv6 PDP contexts are

 JW: This sounds rational.

 JW: I don't have any complaints.

...

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

 JW: Yep.

 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-

---

From: <[email-masked]>
Date: Wed, 24 Sep 2003 18:07:23 +0300

Hi, Karim and Pekka!

I think we are pretty close resolving also this issue...  Minor comments (JW) below:

-----Original Message-----
From: ext Pekka Savola [mailto:[email-masked]]
Sent: 22 September, 2003 18:55

> The meaning I infer is that if the v4 address is not public and you need
> to talk v4 hosts outside your private domain then you go through one or
> more NATs. NAT is considered an "additional translator" above.

Right.. I didn't think of NAT as an additional translator.  In any case, a 
clarification will be needed.

 JW: That is a good point, because NAT *is* a translator (NAT-PT is not the 
only evil translator :), I will modify text according to this comment and also 
mention the peer-to-peer / node reachability case I already commented 
above.

> This changes the meaning of the text so I don't agree.
> It is meant to say that using IPv6 is preferred (to IPv4
> through NATs), be it native connectivity or tunneled.

Yep, that's intentional.  However, the only change of substance here is 
that the "tunneled IPv6 from the UE" has been pretty much killed from the 
document already.

So, I think my text is better.  One could of course just say "As a general 
guideline, IPv6 communication ....", i.e., kill "native" by making it a 
bit more general while not pointing out the not-so-relevant details.

 JW: 
      => can we agree on Pekka's suggestion and just remove
      "native" from Pekka's text?

Cheers,
	-Juha-

---

From: <[email-masked]>
Date: Wed, 24 Sep 2003 18:12:17 +0300

Hi, Karim and Pekka!

-----Original Message-----
From: ext Pekka Savola [mailto:[email-masked]]
Sent: 22 September, 2003 18:55

 JW: 

Cheers,
	-Juha-