Subject: Feedback from 3GPP about draft-wasserman

From: Juan-Antonio Ibanez <[email-masked]>
Date: Thu, 06 Dec 2001 20:10:43 +0100

Hello all,

Last week (26-30 November) took place the 3GPP SA2 #21 meeting in
Cancun. At this occasion I presented a discussion paper introducing
draft-wasserman-3gpp-advice-00.txt to the 3GPP community. This
Internet-draft was generally well received, however 3GPP SA2 will wait
until the IPng WG has endorsed it before deciding whether to follow any
of the recommendations and introduce any changes in the 3GPP standards.

Following this presentation, and to keep up the co-operation between
IETF and 3GPP, we set up a small drafting group of interested people
with the objective of putting forward a number of suggestions for
improvement, as well as some questions about this draft, to the IPng
working group. These comments are included below. (Sorry for the long
email)

Let me take this opportunity to congratulate the members of the IPng
design team for their good and constructive job in producing this
Internet-draft and also stress that a quick resolution on the acceptance
of this I-D by the IPng WG is required in order to get a chance to have
any necessary changes (if accepted by 3GPP) introduced in the next 3GPP
release, i.e. R5, which is due for completion in March 2002 and is a
major milestone for IPv6 in 3GPP.

Regards,
Juan

General comments:
----------------

1) It would be useful to include some description/guidelines about how
IPv6 address blocks should be allocated to 3G mobile operators (i.e.
what size, possibility to get additional address blocks if needed and
how, etc.), in particular considering that in some countries operators
with more than 100 millions subscribers, possibly using multiple
"primary" PDP contexts, are foreseeable.
It is probably not IPng's task to define these policies, however some
hints or references to other RFCs might reveal useful for telecom
operators that do not necessarily read all these RFCs.

2) Would the /64 prefix allocation preclude the use of the 6to4
transition mechanism in 3GPP?
6to4 relies on a /48 prefix, meaning that only 64k mobile nodes (or
rather "primary" PDP contexts) would be allowed on a given APN that
supports 6to4.

Detailed comments:
-----------------

3) Section 6.5 applies to 3GPP Release 99; this should be explicitly
stated, as in later releases (i.e. in Release 5) the architecture is
further evolved, for instance by introducing the IP multimedia subsystem
or other changes to existing procedures.

4) The APN concept is missing in section 6.5 (but is mentioned in the
Appendix). "APN = Access Point Name" should also be added to the 3GPP
terminology section.

Suggested text:
"The APN is a logical name referring to a GGSN. The APN also identifies
an external network. The syntax of the APN corresponds to a fully
qualified name. At PDP context activation, the SGSN performs a DNS query
to find out the GGSN(s) serving the APN requested by the terminal. The
DNS response contains a list of GGSN addresses from which the SGSN
selects one (in a round-robin fashion)."

5) Section 6.5.2 says: "There are two kinds of PDP Contexts -- primary,
and secondary". There seems to be a slight misunderstanding of the
concept of multiple PDP contexts, i.e. once activated, all PDP contexts
associated with the same IP address are conceptually equal; the MS can
delete a "primary" PDP context and keep the "secondary" ones. But since
the idea of  "primary" and "secondary" PDP context provides an easy
understanding of the problem it is probably good to keep this
terminology.

However, for a better clarity, here is some suggested rewording:
In 6.5.2, "In addition, one or more secondary PDP Contexts can be added
to a primary PDP Context <and share the same IP address>."
Also add at the end of 3rd paragraph of 6.5.2 "Once activated, all PDP
contexts have equal status, meaning that a primary PDP context can be
deleted while keeping the link between the UE and the GGSN, as long as
there are other (secondary) PDP contexts active for the same IP
address."
Still in 6.5.2 the description of Deactivate PDP Context should read
"Deactivates a PDP Context. If a primary PDP Context <and all secondary
PDP contexts associated with it are> deleted, a link between the UE and
the GGSN is removed."

6) In section 6.5.3 (and other places), the last paragraph says that the
IP address of the MS is used in the SGSN to identify the PDP context
associated with each packet; this is not correct.
Packets are tunnelled in GTP between the RNC, SGSN and GGSN and are
routed based on the TEID. The IP address is only used by the GGSN to
identify the PDP context; in the SGSN, the IP address can be used for
charging (or legal interception) purposes.

Suggested text:
Add "GTP-U = GPRS Tunnelling Protocol - User plane" to the 3GPP
terminology.
In 6.5.1 add "GTP-U is a simple tunnelling protocol running over UDP/IP
and used to route packets between RNC, SGSN and GGSN within the same, or
between different, UMTS backbone(s). A GTP-U tunnel is identified at
each end by a Tunnel Endpoint Identifier (TEID)."
In 6.5.3, last paragraph, reword as "... so that the SGSN can know the
single address of each 3GPP node (e.g. for charging purposes). This
address is used <in the GGSN> to identify ..."

7) Section 7.3, second paragraph:
In the second paragraph, what was the intention of "or more"?
It should be clearer that the recommendation to allocate a /64 prefix to
each primary PDP context is independent of whether one or multiple
prefixes are allowed per PDP context (indeed, due to time constraints
3GPP might not be able to support multiple prefixes per PDP context in
the coming 3GPP release, but could at least support prefix allocation).
Perhaps "or more" should be put in parenthesis.

8) Section 7.3.2 also states that SGSN uses the IP address to identify
the PDP contexts (see comment #6 above). The corresponding sentence
should simply be removed.
Also in the next to last paragraph of 10.1, the last sentence should
rather read "By assigning a given prefix to only one primary PDP
context, the SGSN can <associate this prefix list with> the PDP
contexts."

9)	Section 10.1, last paragraph:
It is stated that the devices behind the MT can activate their own
primary PDP contexts. Without entering into details, it is not the
device behind the MT that activates a PDP context, but the MT itself on
request from the device (or by some automatic means).

Suggested text:
"However this is not necessary if each device behind the MT is connected
to a separate primary PDP Context ..."
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Thomas Narten <[email-masked]>
Date: Fri, 07 Dec 2001 12:34:48 -0500

> operators that do not necessarily read all these RFCs.

My initial reaction is that this may well not be this WG's job. Could
you clarify a bit in terms of what you want advice on?

Note that you should in any case be also having discussions with the
appropriate Regional Internet Registries (RIRs) (i.e., ARIN, APNIC, or
RIPE). They may well be able to give you the info you are looking for
as they have policies in place that describe the procedures for
obtaining IPv6 address space. Consult their web pages for more info
and specifics.

Finally, note that the RIR IPv6 policy is currently under revision, so
now would be a particularly good time to discuss with the RIRs any
issues you might have, in case they need to be considered in the
updated IPv6 policy.

I've appended a somewhat-related note I recently sent to V6 WG in ARIN
on this topic.

Thomas

From: Thomas Narten <[email-masked]>
To: [email-masked]
cc: [email-masked], [email-masked]
Date: Fri, 30 Nov 2001 15:09:47 -0500
Subject: IPv6 Policy Proposal discussion

As reported at the Miami meeting, a new mailing list, global-v6, has
been set up to discuss IPv6 address policy issues. Previously, each
RIR (ARIN, APNIC, and RIPE) had been discussing the same general topic
but on their own mailing lists.  The goal of having all related
discussion take place on a single list is to have APNIC, ARIN, and
RIPE develop mutually agreeable policies that all three RIRs can adopt
as their own.

It is expected that much of the discussion that has previously been
taking place on the [email-masked] mailing list will instead take place
on the global list.  The v6wg list will remain in place, however, for
discussion of topics more specific to ARIN.

You MUST subscribe to the list individually; those of you subscribed
to the v6wg list will NOT automatically be added to the global-v6
list.

List details:

   To post: <[email-masked]>.
   To subscribe:  http://www.apnic.net/net_comm/lists/
   Archives: http://www.apnic.net/mailing-lists/global-v6

Finally, an updated IPv6 policy document will be made available
shortly. It contains more details and takes into account discussions
at the recent RIR meetings. The document will be posted to the
global-v6 list and we hope to have some good discussions there.

Thomas

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 10 Dec 2001 19:47:17 +0100

Juan-Antonio Ibanez wrote:
...
> rather "primary" PDP contexts) would be allowed on a given APN that

Are you assuming that the APN has exactly one globally routable IPv4
address? If so, it can only own one 6to4 /48 prefix, i.e. 64k /64s
as you say. But if the APN has 2 IPv4 addresses, it can have two
6to4 prefixes, etc. 

What is the realistic requirement for the number of primary PDP
contexts per APN? 

   Brian

---

From: Juan-Antonio Ibanez <[email-masked]>
Date: Mon, 10 Dec 2001 21:00:58 +0100

Hi Thomas,

Actually there are two reasons behind this comment.

One is that the draft provides some argumentation on why allocating /64
prefixes is not a risk for the address space and that's fine, but
another question that I hear quite often is whether Internet registries
will accept to give out huge blocks of addresses to each and every
cellular operator. Therefore some hints that this is not an issue either
would be valuable.

The other reason is that no action will be undertaken by 3GPP to ensure
appropriate allocation policies until the /64 allocation principle is
formally approved by 3GPP, but the decision to approve it or not will
only be taken once the draft has become a WG document and the
discussions will then mostly be based on this draft. Therefore, to
reassure those who are afraid that 3G operators might have difficulties
getting the necessary address space, some pointers to documents like
e.g. RFC 3177 would be helpful when we come to deciding on this matter
in 3GPP.

Perhaps the comment was not so clear in that it is not really "how" an
operator can request address space which matters here, but rather "what
kind of" address blocks an operator will need and highlight that it
won't be a problem to get it.

BR,
Juan

---

From: Juan-Antonio Ibanez <[email-masked]>
Date: Mon, 10 Dec 2001 23:50:13 +0100

Well, all terminals attached to a given APN will receive the same router
advertisements from the GGSN, so having two IPv4 global addresses per
APN would simply mean that each primary PDP context would get two 6to4
addresses, but the limit will still be 64k primary PDP contexts per APN.

As for your question, to say a number, 500k primary PDP contexts on a
single APN seems quite realistic (assuming a GGSN supporting 1 million
PDP contexts).

/Juan

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 11 Dec 2001 15:17:35 -0500

>addresses, but the limit will still be 64k primary PDP contexts per APN.

Why would all terminals attached to a given APN receive the same router
advertisements?  Won't there be multiple PDP contexts associated with
a given APN?  If so, the GGSN should be sending different router 
advertisements for each PDP context, each containing the prefix(es) 
assigned to that particular PDP context.

Since each prefix will be assigned to one (and only one) PDP context, I
think that you will have the possibility of assigning 64K 6to4 addresses
per PDP context, not per APN.

Am I misunderstanding something?

Margaret