Skip to main content

Analysis on IPv6 Transition in Third Generation Partnership Project (3GPP) Networks
RFC 4215

Revision differences

Document history

Date Rev. By Action
2018-12-20
11 (System)
Received changes through RFC Editor sync (changed abstract to 'This document analyzes the transition to IPv6 in Third Generation Partnership Project (3GPP) packet networks. These …
Received changes through RFC Editor sync (changed abstract to 'This document analyzes the transition to IPv6 in Third Generation Partnership Project (3GPP) packet networks. These networks are based on General Packet Radio Service (GPRS) technology, and the radio network architecture is based on Global System for Mobile Communications (GSM) or Universal Mobile Telecommunications System (UMTS)/Wideband Code Division Multiple Access (WCDMA) technology.

The focus is on analyzing different transition scenarios and applicable transition mechanisms and finding solutions for those transition scenarios. In these scenarios, the User Equipment (UE) connects to other nodes, e.g., in the Internet, and IPv6/IPv4 transition mechanisms are needed. This memo provides information for the Internet community.')
2012-08-22
11 (System) post-migration administrative database adjustment to the No Objection position for Scott Hollenbeck
2012-08-22
11 (System) post-migration administrative database adjustment to the No Objection position for Allison Mankin
2012-08-22
11 (System) post-migration administrative database adjustment to the No Objection position for Steven Bellovin
2012-08-22
11 (System) post-migration administrative database adjustment to the No Objection position for Ted Hardie
2012-08-22
11 (System) post-migration administrative database adjustment to the No Objection position for Russ Housley
2005-10-18
11 Amy Vezza State Changes to RFC Published from RFC Ed Queue by Amy Vezza
2005-10-18
11 Amy Vezza [Note]: 'RFC 4215' added by Amy Vezza
2005-10-14
11 (System) RFC published
2004-11-30
11 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2004-11-29
11 Amy Vezza IESG state changed to Approved-announcement sent
2004-11-29
11 Amy Vezza IESG has approved the document
2004-11-29
11 Amy Vezza Closed "Approve" ballot
2004-11-24
11 David Kessens State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by David Kessens
2004-11-23
11 Allison Mankin
[Ballot comment]
Gonzalo Camarillo worked with me to revise the discussion of the issues for SIP - the revision
indicates need for rapid work in …
[Ballot comment]
Gonzalo Camarillo worked with me to revise the discussion of the issues for SIP - the revision
indicates need for rapid work in SIPPING, but points to directions that make sense both for
SIP people and v6ops people.  (The new text was reviewed by v6ops - did not have a broad
SIPPING working group review yet, but did have review by a number of SIP expert readers besides
Gonzalo.
2004-11-23
11 Allison Mankin [Ballot Position Update] Position for Allison Mankin has been changed to No Objection from Discuss by Allison Mankin
2004-10-27
11 (System) New version available: draft-ietf-v6ops-3gpp-analysis-11.txt
2004-07-09
11 (System) Removed from agenda for telechat - 2004-07-08
2004-07-08
11 Allison Mankin
[Ballot discuss]
My understanding is that this analysis is for 3GPP, rather than reflecting an existing
fully-formed 3GPP analysis, so that we influence what 3GPP …
[Ballot discuss]
My understanding is that this analysis is for 3GPP, rather than reflecting an existing
fully-formed 3GPP analysis, so that we influence what 3GPP thinks.

3GPP desperately needs to grapple with a robust model for IMS systems when
they communication with IPv4 only hosts.  (They also needs a model for those
systems to deal with expressing a preference for IPv6 usage should vendors
provide IPv4 IMS capability). 

The document wisely says that the SIP WG can do a good job of providing this
model, but then unwisely both describes a model and references a more
detailed draft.  Both models are not good cross-area products, since they
design a SIP ALG and a NAT-PT structure for SIP's SDP. 

Since SIP terminates the connection endpoints at proxies, it can change
the Internet protocol at those points, therefore, it would be possible to
provide a reverse NAT for IPv4 addresses and route them to translating
proxies at a boundary point where the IMS system had dual stack
capability (this is just one idea).  The media situation is harder, but
the review of this needs to consider capabilities such as terminating
the media at a mixer and changing the Internet protocol there (SDP
rewriting is not OK), using only DNS names by policy, so both ends
of the media user could use a generic transition mechanism not
specialized into 3GPP.

My recommendation is that this section only contain a strong referral
with a deadline for the SIP/SDP community to do this work, rather
than sketching problematic approaches.

--------

New Discuss text 20040708

I had sent text and they incorporated in -10.  But there's a bit of a problem with my text and
here's what I've now sent in email:

I showed the text that you adopted from me to Gonzalo Camarillo and we
discussed it.  He thought the text did not give a clear message to avoid
SDP re-writing, as it should (and I meant).  Gonzalo is co-chair of SIPPING,
author of a recent book on IMS, and is co-authoring the transition i-d.
(And he agreed to take a speeded-up action on that i-d).

So here is a replacement for one paragraph in section 4.1.  With this
replacement I would remove my Discuss.

NEW:
    In an ALG approach, this edge would change the IP addresses
    transported in the SIP messages and the SDP payload of
    those messages to the appropriate version. The SDP rewriting
    in this approach would have many drawbacks and would violate
    the protocol design of RFC 3261.  Moreover, this approach would not
    take advantage of SIP's ability to use proxy routing, nor of SDP's
    ability to carry multiple alternative addresses. These intrinsic
    features of SIP and SDP require a more detailed analysis, but they
    will yield benefits. In addition, any SIP/SDP ALG approach would require
    NAT-PT (with the issues described in Appendix A), because the IMS-side
    IPv6addresses must be assigned IPv4 addresses for reachability from the
    legacy IPv4 side shown in Figure 1. The approach based on intrinsic
    SIP proxy routing would not require assignment of temporary IPv4
    addresses to the IPv6 IMS endpoints; instead they would be reached
    via an IPv4-side address of a SIP proxy acting for them. This SIP
    proxy would be doing normal SIP processing.

OLD:
  In a possible approach, this edge could contain a SIP ALG, which
    would change the IP addresses transported in the SIP messages and
    the SDP payload of those messages to the appropriate  version. This
    approach would have the drawback (like other SDP rewriting
    solutions) of impacting authentication mechanisms that may be
    needed for other purposes. Moreover, this approach would not take
    advantage of SIP's ability to use proxy routing, nor of SDP's
    ability to carry multiple alternative addresses. These intrinsic
    features of SIP and SDP require a more detailed analysis, but they
    could yield benefits. The SIP ALG approach requires NAT-PT (with
    the issues described in Appendix A), because the IMS-side IPv6
    addresses must be assigned IPv4 addresses for reachability from the
    legacy IPv4 side shown in Figure 1. The approach based on intrinsic
    SIP proxy routing would not require assignment of temporary IPv4
    addresses to the IPv6 IMS endpoints; instead they would be reached
    via an IPv4-side address of a SIP proxy acting for them. This SIP
    proxy would be doing normal SIP processing.

(My other text changes were fine:  strong recc. for SIP WGs to do the work, whic
is being done in a now-good elmalki draft, and a good paragraph on media changing
by routing to a transcoder).
2004-07-08
11 Margaret Cullen [Ballot Position Update] Position for Margaret Wasserman has been changed to Recuse from No Objection by Margaret Wasserman
2004-07-08
11 Margaret Cullen [Ballot Position Update] Position for Margaret Wasserman has been changed to No Objection from Recuse by Margaret Wasserman
2004-07-06
11 Steven Bellovin [Ballot Position Update] Position for Steve Bellovin has been changed to No Objection from Discuss by Steve Bellovin
2004-07-06
11 Alex Zinin
[Ballot comment]
Draft: draft-ietf-v6ops-3gpp-analysis-10.txt
Reviewer: Brian Carpenter
Date: 5 July 2004

The document is still very useful and still ready to publish.

I fully support …
[Ballot comment]
Draft: draft-ietf-v6ops-3gpp-analysis-10.txt
Reviewer: Brian Carpenter
Date: 5 July 2004

The document is still very useful and still ready to publish.

I fully support the change to Informational.
2004-06-30
11 David Kessens Placed on agenda for telechat - 2004-07-08 by David Kessens
2004-06-30
11 David Kessens Intended Status has been changed to Informational from BCP
2004-06-01
11 Ted Hardie [Ballot Position Update] Position for Ted Hardie has been changed to No Objection from Discuss by Ted Hardie
2004-05-26
11 Scott Hollenbeck [Ballot comment]
The new text in the Security Considerations addresses my comment, so I've cleared my discuss.
2004-05-26
11 Scott Hollenbeck [Ballot Position Update] Position for Scott Hollenbeck has been changed to No Objection from Discuss by Scott Hollenbeck
2004-05-25
11 (System) Sub state has been changed to AD Follow up from New Id Needed
2004-05-25
10 (System) New version available: draft-ietf-v6ops-3gpp-analysis-10.txt
2004-05-05
11 Russ Housley [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss by Russ Housley
2004-04-15
11 Amy Vezza State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation - Defer by Amy Vezza
2004-04-15
11 Allison Mankin
[Ballot discuss]
My understanding is that this analysis is for 3GPP, rather than reflecting an existing
fully-formed 3GPP analysis, so that we influence what 3GPP …
[Ballot discuss]
My understanding is that this analysis is for 3GPP, rather than reflecting an existing
fully-formed 3GPP analysis, so that we influence what 3GPP thinks.

3GPP desperately needs to grapple with a robust model for IMS systems when
they communication with IPv4 only hosts.  (They also needs a model for those
systems to deal with expressing a preference for IPv6 usage should vendors
provide IPv4 IMS capability). 

The document wisely says that the SIP WG can do a good job of providing this
model, but then unwisely both describes a model and references a more
detailed draft.  Both models are not good cross-area products, since they
design a SIP ALG and a NAT-PT structure for SIP's SDP. 

Since SIP terminates the connection endpoints at proxies, it can change
the Internet protocol at those points, therefore, it would be possible to
provide a reverse NAT for IPv4 addresses and route them to translating
proxies at a boundary point where the IMS system had dual stack
capability (this is just one idea).  The media situation is harder, but
the review of this needs to consider capabilities such as terminating
the media at a mixer and changing the Internet protocol there (SDP
rewriting is not OK), using only DNS names by policy, so both ends
of the media user could use a generic transition mechanism not
specialized into 3GPP.

My recommendation is that this section only contain a strong referral
with a deadline for the SIP/SDP community to do this work, rather
than sketching problematic approaches.
2004-04-15
11 Thomas Narten [Ballot comment]
>    plane mechanism). Same kind of mechanism is also available for

s/Same/The same/
2004-04-15
11 Thomas Narten [Ballot Position Update] New position, No Objection, has been recorded for Thomas Narten by Thomas Narten
2004-04-15
11 Allison Mankin [Ballot Position Update] Position for Allison Mankin has been changed to Discuss from Abstain by Allison Mankin
2004-04-15
11 Allison Mankin [Ballot Position Update] Position for Allison Mankin has been changed to Abstain from Undefined by Allison Mankin
2004-04-14
11 Harald Alvestrand
[Ballot comment]
Reviewed by John Loughney and Brian Carpenter, Gen-ART
Brian's comment on the status of this document:

I've looked at this a number of …
[Ballot comment]
Reviewed by John Loughney and Brian Carpenter, Gen-ART
Brian's comment on the status of this document:

I've looked at this a number of times within v6ops. I am a little
surprised that it is proposed for BCP; and when thinking about that,
consider the rather strange first sentence in the Scope section:

>    The scope of this Best Current Practices document is to analyze and
>    solve the possible transition scenarios in the 3GPP defined GPRS
>    network

Scenarios aren't things you *solve*; they are things you *describe*. I
would see no objection to this as an Informational, but I think it
(and its future companion documents from v6ops) are hardly BCPs. There
is surely no current practice on which to base the assertion that this
draft describes the Best.

Apart from that I think the document is very useful and ready to publish.
2004-04-02
11 Bert Wijnen [Ballot Position Update] Position for Bert Wijnen has been changed to No Objection from Undefined by Bert Wijnen
2004-04-02
11 Bert Wijnen
[Ballot comment]
sect 1.1 says:
  The scope of this Best Current Practices document

Is that appropriate text to state in the doc itself?
I …
[Ballot comment]
sect 1.1 says:
  The scope of this Best Current Practices document

Is that appropriate text to state in the doc itself?
I thought BCP is an external label only?
2004-04-02
11 Bert Wijnen [Ballot Position Update] New position, Undefined, has been recorded for Bert Wijnen by Bert Wijnen
2004-04-02
11 Alex Zinin [Ballot Position Update] New position, No Objection, has been recorded for Alex Zinin by Alex Zinin
2004-04-02
11 Bill Fenner [Ballot Position Update] New position, No Objection, has been recorded for Bill Fenner by Bill Fenner
2004-04-02
11 Allison Mankin
[Ballot comment]
Sorry for deferring - I needed more time than was possible with this heavy
agenda to write cross-area perspective on SIP and SDP …
[Ballot comment]
Sorry for deferring - I needed more time than was possible with this heavy
agenda to write cross-area perspective on SIP and SDP not being best
served by either ALG or NAT-PT here.  Pekka actually wrote me to take a
Discuss here and that will follow.
2004-04-02
11 Allison Mankin [Ballot Position Update] New position, Undefined, has been recorded for Allison Mankin by Allison Mankin
2004-04-02
11 Allison Mankin State Changes to IESG Evaluation - Defer from IESG Evaluation by Allison Mankin
2004-04-02
11 Jon Peterson [Ballot Position Update] Position for Jon Peterson has been changed to No Objection from Undefined by Jon Peterson
2004-04-02
11 Jon Peterson
[Ballot comment]
The use of SIP ALGs has security implications - namely, it precludes certain security mechanisms (namely S/MIME) described in RFC3261 which mightprotect the …
[Ballot comment]
The use of SIP ALGs has security implications - namely, it precludes certain security mechanisms (namely S/MIME) described in RFC3261 which mightprotect the integrity or confidentiality of SDP, or even SIP headers in some instances. While this document does suggest that more work needs to be done in the SIPpish WGs to address the SIP 6-to-4 problem, it describes no other solution than the use of SIP ALGs. Accordingly, a mention of the effects of ALGs on SIP security in the Security Considerations is probably warranted.
2004-04-02
11 Jon Peterson [Ballot Position Update] New position, Undefined, has been recorded for Jon Peterson by Jon Peterson
2004-04-01
11 Harald Alvestrand [Ballot comment]
Reviewed by John Loughney, Gen-ART
2004-04-01
11 Harald Alvestrand [Ballot Position Update] New position, No Objection, has been recorded for Harald Alvestrand by Harald Alvestrand
2004-03-30
11 Scott Hollenbeck
[Ballot discuss]
I agree with the other DISCUSS comments focused on the Security Considerations.  If there's text that says "There are some generic security considerations …
[Ballot discuss]
I agree with the other DISCUSS comments focused on the Security Considerations.  If there's text that says "There are some generic security considerations when moving to dual-stack IPv4/IPv6 deployment", the considerations need to be analyzed.  The doc shouldn't duck these issues with "which are not analyzed at length here".
2004-03-30
11 Scott Hollenbeck [Ballot Position Update] Position for Scott Hollenbeck has been changed to Discuss from Undefined by Scott Hollenbeck
2004-03-30
11 Russ Housley
[Ballot discuss]
I am not comfortable with a BCP saying that if the "need for a new
  mechanism is found, that will be reported …
[Ballot discuss]
I am not comfortable with a BCP saying that if the "need for a new
  mechanism is found, that will be reported to the IETF v6ops Working
  Group."  That working group will not be around as long as the BCP.
2004-03-30
11 Russ Housley [Ballot Position Update] New position, Discuss, has been recorded for Russ Housley by Russ Housley
2004-03-29
11 Ted Hardie
[Ballot discuss]
In the security considerations section, this text:

    In particular, this memo does not recommend the following technique
    which has …
[Ballot discuss]
In the security considerations section, this text:

    In particular, this memo does not recommend the following technique
    which has security issues, not further analyzed here:
   
      - NAT-PT or other translator as a generic-purpose transition
          mechanism

seems to need amplification, since they did recommend
reusing many of the same ideas in the SIP/IMS context
(see section 4.1).  True, that is not a generic-purpose
transition mechanism, but knowing which bits of the NAT-PT problem
do an don't apply when doing it for a specific applications
needs a bit more explanation.
2004-03-29
11 Ted Hardie [Ballot Position Update] Position for Ted Hardie has been changed to Discuss from Undefined by Ted Hardie
2004-03-29
11 Ted Hardie
[Ballot comment]
In section 3.1, this statement seems odd:

That also makes
    it possible to burden the transition effects in the network and …
[Ballot comment]
In section 3.1, this statement seems odd:

That also makes
    it possible to burden the transition effects in the network and
    make the 3GPP UEs simpler.

Perhaps they mean "lessen the transition effects"?

In section 3.2, this statement:

  If the 3GPP operator has
    deployed IPv6 in its backbone, but the upstream ISP does not
    provide IPv6 connectivity to the Internet, the encapsulating node
    can be the edge router.

left me wondering about the topology. There are cases where
I think they would mean what is typically called a border router,
and there may also be cases where they mean the upstream
ISP's edge router.  Would "If the 3GPP operator has deployed IPv6
in its backbone but the upstream ISP has not, the encapsulating
node may be the router handing the traffic off to the upstream
ISP." be any clearer?

Section 3.5 seems to imply that v4 UEs and v6 UEs would never
trade traffic directly; there are no applications in which they
are not talking through an app server.  If this is correct, it
might be useful to make that explicit.

For this text:

Active IETF work on DNS discovery mechanisms is
    ongoing and might result in other mechanisms becoming available
    over time. The DNS server addresses can also be received over the
    air (using SMS), or typed in manually in the UE.
   
A pointer to which work they're talking about in the IETF would
be valuable; if the SMS message is a 3gpp-defined protocol,
a pointer would also be valuable.  If it's a text message which
is then typed/pasted in, then no pointer would be required.
2004-03-29
11 Ted Hardie
[Ballot comment]
In section 3.1, this statement seems odd:

That also makes
    it possible to burden the transition effects in the network and …
[Ballot comment]
In section 3.1, this statement seems odd:

That also makes
    it possible to burden the transition effects in the network and
    make the 3GPP UEs simpler.

Perhaps they mean "lessen the transition effects"?

In section 3.2, this statement:

  If the 3GPP operator has
    deployed IPv6 in its backbone, but the upstream ISP does not
    provide IPv6 connectivity to the Internet, the encapsulating node
    can be the edge router.

left me wondering about the topology. There are cases where
I think they would mean what is typically called a border router,
and there may also be cases where they mean the upstream
ISP's edge router.  Would "If the 3GPP operator has deployed IPv6
in its backbone but the upstream ISP has not, the encapsulating
node may be the router handing the traffic off to the upstream
ISP." be any clearer?

Section 3.5 seems to imply that v4 UEs and v6 UEs would never
trade traffic directly; there are no applications in which they
are not talking through an app server.  If this is correct, it
might be useful to make that explicit.
2004-03-29
11 Ted Hardie [Ballot Position Update] New position, Undefined, has been recorded for Ted Hardie by Ted Hardie
2004-03-26
11 Margaret Cullen [Ballot Position Update] New position, Recuse, has been recorded for Margaret Wasserman by Margaret Wasserman
2004-03-26
11 Steven Bellovin
[Ballot discuss]
(26 March 2004)
The security considerations section is inadequate.  It says, in effect, "we talk about lots of things that have security considerations", …
[Ballot discuss]
(26 March 2004)
The security considerations section is inadequate.  It says, in effect, "we talk about lots of things that have security considerations", but doesn't explain them or point to where they are explained.
2004-03-26
11 Steven Bellovin
[Ballot discuss]
The security considerations section is inadequate.  It says, in effect, "we talk about lots of things that have security considerations", but doesn't explain …
[Ballot discuss]
The security considerations section is inadequate.  It says, in effect, "we talk about lots of things that have security considerations", but doesn't explain them or point to where they are explained.
2004-03-26
11 Steven Bellovin [Ballot Position Update] New position, Discuss, has been recorded for Steve Bellovin by Steve Bellovin
2004-03-25
11 Scott Hollenbeck [Ballot comment]
This ballot is for -09, but the most recent document appears to be -08.
2004-03-25
11 Scott Hollenbeck [Ballot Position Update] New position, Undefined, has been recorded for Scott Hollenbeck by Scott Hollenbeck
2004-03-25
11 David Kessens [Ballot Position Update] New position, Yes, has been recorded for David Kessens
2004-03-25
11 David Kessens Ballot has been issued by David Kessens
2004-03-25
11 David Kessens Created "Approve" ballot
2004-03-25
11 David Kessens Placed on agenda for telechat - 2004-04-02 by David Kessens
2004-03-25
11 David Kessens State Changes to IESG Evaluation from Waiting for AD Go-Ahead by David Kessens
2004-03-25
09 (System) New version available: draft-ietf-v6ops-3gpp-analysis-09.txt
2004-03-23
11 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2004-02-16
11 Amy Vezza Last call sent
2004-02-16
11 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2004-02-13
11 David Kessens Last Call was requested by David Kessens
2004-02-13
11 David Kessens State Changes to Last Call Requested from AD Evaluation by David Kessens
2004-02-13
11 (System) Ballot writeup text was added
2004-02-13
11 (System) Last call text was added
2004-02-13
11 (System) Ballot approval text was added
2004-02-13
11 David Kessens State Changes to AD Evaluation from Publication Requested by David Kessens
2004-02-13
11 David Kessens Shepherding AD has been changed to David Kessens from Bert Wijnen
2004-01-29
11 Dinara Suleymanova Draft Added by Dinara Suleymanova
2004-01-29
08 (System) New version available: draft-ietf-v6ops-3gpp-analysis-08.txt
2003-10-28
07 (System) New version available: draft-ietf-v6ops-3gpp-analysis-07.txt
2003-09-29
06 (System) New version available: draft-ietf-v6ops-3gpp-analysis-06.txt
2003-09-10
05 (System) New version available: draft-ietf-v6ops-3gpp-analysis-05.txt
2003-06-13
04 (System) New version available: draft-ietf-v6ops-3gpp-analysis-04.txt
2003-03-31
03 (System) New version available: draft-ietf-v6ops-3gpp-analysis-03.txt
2003-03-05
02 (System) New version available: draft-ietf-v6ops-3gpp-analysis-02.txt
2003-01-22
01 (System) New version available: draft-ietf-v6ops-3gpp-analysis-01.txt
2002-12-09
00 (System) New version available: draft-ietf-v6ops-3gpp-analysis-00.txt