Mobile Networks Considerations for IPv6 Deployment
draft-ietf-v6ops-v6-in-mobile-networks-05

[Ballot discuss]
I would make the following change in Section 3.1:

  Even though some MNs, especially the
  SmartPhones, in use today may have IPv6 stack, such a capability is
  not tested for compliance and deployment in operational networks.
  Without compliance to network requirements, providers cannot reliably
  provision services.  Given these considerations, it is reasonable to
  expect that the providers can offer connectivity and services based
  on IPv6 in the MNs which are not already in use today.  And, such
  newer MNs still need to be able to access the predominantly IPv4
  Internet.

to

  Even though some MNs, especially the SmartPhones, in use today may
  have IPv6 stack, there are two remaining problems. First, there is little
  operational experience about using these stacks, and as a result, it
  is expected that their use in large deployments may uncover software
  errors and interoperability problems. Second, only a fraction of current
  phones have such a stack. As a result, a lot of work remains for the
  industry to test, deploy and implement IPv6 functionality on the handsets.

Section 3.2:

  An obvious advantage of centralizing the NAT and using
  overlapped private IPv4 addressing is that a large number of mobile
  subscribers can be supported with a common limited pool at the BR.

I do not want to give the wrong impression here. Its true that we need a solution for private address overlap in the centralized case, but it is not true that public address sharing efficiency gains are significant. I would change this as follows:

  In the centralized model, it is obvious that some solution is required to allow
  overlapping private IPv4 addressing.

I would personally even add (but not requiring you to):

  It is expected that public IPv4 address sharing efficiency is not significantly
  impacted, however.

Section 3.4:

      o Encapsulation-based mechanisms such as 6rd [RFC5969] are
      feasible where a residential gateway can become a tunnel end-point
      for connecting subscribers to IPv6-only networks, whereas
      translation is perhaps necessary for IPv6-only mobile networks.

This seems problematic for many reasons. 6rd is not about IPv6-only networking, the usefulness of 6rd depends on the need to do something else than native, etc. I would rewrite this as follows:

      o Encapsulation-based mechanisms such as 6rd [RFC5969] are
      useful where the operator is unable to provide native or direct
      IPv6 connectivity and a residential gateway can become a tunnel
      end-point for providing this service. In mobile networks the operator
      would have the option of providing connectivity over the existing
      mobility service, without introducing another layer of tunnels.

[Ballot discuss]
I would make the following change in Section 3.1:

  Even though some MNs, especially the
  SmartPhones, in use today may have IPv6 stack, such a capability is
  not tested for compliance and deployment in operational networks.
  Without compliance to network requirements, providers cannot reliably
  provision services.  Given these considerations, it is reasonable to
  expect that the providers can offer connectivity and services based
  on IPv6 in the MNs which are not already in use today.  And, such
  newer MNs still need to be able to access the predominantly IPv4
  Internet.

to

  Even though some MNs, especially the SmartPhones, in use today may
  have IPv6 stack, there are two remaining problems. First, there is little
  operational experience about using these stacks, and as a result, it
  is expected that their use in large deployments may uncover software
  errors and interoperability problems. Second, only a fraction of current
  phones have such a stack. As a result, a lot of work remains for the
  industry to test, deploy and implement IPv6 functionality on the handsets.

Section 3.2:

  An obvious advantage of centralizing the NAT and using
  overlapped private IPv4 addressing is that a large number of mobile
  subscribers can be supported with a common limited pool at the BR.

I do not want to give the wrong impression here. Its true that we need a solution for private address overlap in the centralized case, but it is not true that public address sharing efficiency gains are significant. I would change this as follows:

  In the centralized model, it is obvious that some solution is required to allow
  overlapping private IPv4 addressing.

I would personally even add (but not requiring you to):

  It is expected that public IPv4 address sharing efficiency is not significantly
  impacted, however.

Section 3.4:

      o Encapsulation-based mechanisms such as 6rd [RFC5969] are
      feasible where a residential gateway can become a tunnel end-point
      for connecting subscribers to IPv6-only networks, whereas
      translation is perhaps necessary for IPv6-only mobile networks.

This seems problematic for many reasons. 6rd is not about IPv6-only networking, the usefulness of 6rd depends on the need to do something else than native, etc. I would rewrite this as follows:

      o Encapsulation-based mechanisms such as 6rd [RFC5969] are
      useful where the operator is unable to provide native or direct
      IPv6 connectivity and a residential gateway can become a tunnel
      end-point for providing this service. In mobile networks the operator
      would have the option of providing connectivity over the existing
      mobility service, without introducing another layer of tunnels.

[Ballot discuss]
Apologies for a quickly written note below, due to a timezone mixup I needed to finish this sooner than I thought.

In Section 3.1, the "delaying exhaustion" approach has in my opinion been described in the wrong way. Obviously, the exhaustion has at a global level already happened. In addition, private-address space usage for end users is already relatively common practice in mobile networks even prior to exhaustion. I would rephrase this part of the document as something that conserves address resources the operator has to dedicate to these networks. The last part of Section 3.1 concludes that support for NAT44 and private addresses is required. I would rephrase this as something that has already been going on, and is a natural deployment model for the operators today.

Then the document goes on to discuss the dynamic allocation of IPv4 addresses. While this has been extensively discussed in the industry, I think it is largely a fantasy. The reasons are pretty well covered in the document, but the document should make it clearer that this is not a real option.

Section 3.1 also makes the argument that IPv6 functionality is not tested or deployed at all in the existing handsets and therefore only new handsets can really be used for IPv6. I do not buy this argument for several reasons. First of all, some handsets are known to work with IPv6. And those new handsets won't be tested and deployed either. Third, I think it is basically wrong to advice waiting for new features as opposed to starting to actually do something with the functionality that exists. Finally,  the argument is made in the context of improving IPv4 address usage efficiency, and this is technically independent of any IPv6 deployment.

I like the conclusions at the end of Section 3.1, but based on the above I'd change the private address phrasing, and I would remove the "investigate on-demand addressing" suggestion.

Section 3.2:

  An obvious advantage of centralizing the NAT and using
  overlapped private IPv4 addressing is that a large number of mobile
  subscribers can be supported with a common limited pool at the BR.

I don't think this is obvious at all. Once you have, say, a million subscribers on a box, you already achieve extremely high address sharing efficiencies, the additional benefit from centralizing further seem marginal at best. There are also very obvious disadvantages to running large networks with a central choke point (say, route all traffic in the United States to a single device so that we can NAT the traffic).

Section 3.3:

  Even though there are no
  requirements for the transport network to be IPv6, an operational
  IPv6 network can be deployed with configured tunneling between the
  network nodes with IPv4-only transport.  Hence a service provider may
  choose to enforce IPv6-only PDN and address assignment for their own
  subscribers in their Home Networks, see Figure 1.

This seems incorrect. Mobile networks are already tunneling no matter what, so no configured tunneling is required. In fact, there is plenty of evidence that IPv6 roaming works, and the challenges are more in the area of accounting, filtering and other services than actual connectivity.

Section 3.4:

  Similarly, encapsulation-based mechanisms such as 6rd [RFC5969] are
  feasible where a residential gateway can become a tunnel end-point
  for connecting subscribers to IPv6-only networks, whereas translation
  is perhaps necessary for IPv6-only mobile networks.

Not sure I understand what the above is saying. 6rd is for providing IPv6 connectivity when dual stack is not available, but the operator is interested in providing IPv6 connectivity.

Second, 6rd does not appear to be a useful technology in mobile networks, because if the operators are interested in providing IPv6 connectivity then they already have the tunnels (GTP tunnels) to make it happen.

Section 4: I think some of the conclusions are debatable, e.g.:

      And, roaming, which is unique to mobile
      networks, requires that a provider support IPv4 connectivity when
      their (outbound) users roam into a mobile network that is not
      IPv6-enabled. [it seems to work in most cases, on ipv6 regardless of
      what local operator supports]
      ....
      Similarly, a provider needs to support IPv4
      connectivity for (inbound) users whose MNs are not IPv6-capable.
      [But the architecture already supports providing connectivity
      to any network offered by the home network, so its not clear that
      anything special is needed here. APN and home operator concepts
      work this way already. Mobile is very different from fixed in this
      sense, all traffic is actually carried in tunnels.]
      ...
      The centralized
      model also achieves private IPv4 address re-use...
      [and the benefits are marginal]

Summary:

But my biggest concern with the document is that it spends quite a lot of time explaining the on-demand model and the IPv6-only model (and the latter should be explained, I agree) but spends almost no time explaining the issues and deployment advice for the primary recommended model, dual stack. In particular, the document should probably explain how to deploy NAT44 and IPv6 together, how the gradual increase of traffic on IPv6 side of dual stack (e.g., akamai, google) will help reduce required NAT44 resources, etc.

My other concern is that it suggests new work for on-demand addressing and centralized NATs, and omits operational advice that in my opinion would be more relevant, such as what the impacts are for accounting, billing, user provisioning, etc.

[Ballot discuss]
In Section 3.1, the "delaying exhaustion" approach has in my opinion been described in the wrong way. Obviously, the exhaustion has at a global level already happened. In addition, private-address space usage for end users is already relatively common practice in mobile networks even prior to exhaustion. I would rephrase this part of the document as something that conserves address resources the operator has to dedicate to these networks. The last part of Section 3.1 concludes that support for NAT44 and private addresses is required. I would rephrase this as something that has already been going on, and is a natural deployment model for the operators today.

Then the document goes on to discuss the dynamic allocation of IPv4 addresses. While this has been extensively discussed in the industry, I think it is largely a fantasy. The reasons are pretty well covered in the document, but the document should make it clearer that this is not a real option.

Section 3.1 also makes the argument that IPv6 functionality is not tested or deployed at all in the existing handsets and therefore only new handsets can really be used for IPv6. I do not buy this argument for several reasons. First of all, some handsets are known to work with IPv6. And those new handsets won't be tested and deployed either. Third, I think it is basically wrong to advice waiting for new features as opposed to starting to actually do something with the functionality that exists. Finally,  the argument is made in the context of improving IPv4 address usage efficiency, and this is technically independent of any IPv6 deployment.

I like the conclusions at the end of Section 3.1, but based on the above I'd change the private address phrasing, and I would remove the "investigate on-demand addressing" suggestion.

Section 3.2:

  An obvious advantage of centralizing the NAT and using
  overlapped private IPv4 addressing is that a large number of mobile
  subscribers can be supported with a common limited pool at the BR.

I don't think this is obvious at all. Once you have, say, a million subscribers on a box, you already achieve extremely high address sharing efficiencies, the additional benefit from centralizing further seem marginal at best. There are also very obvious disadvantages to running large networks with a central choke point (say, route all traffic in the United States to a single device so that we can NAT the traffic).

Section 3.3:

  Even though there are no
  requirements for the transport network to be IPv6, an operational
  IPv6 network can be deployed with configured tunneling between the
  network nodes with IPv4-only transport.  Hence a service provider may
  choose to enforce IPv6-only PDN and address assignment for their own
  subscribers in their Home Networks, see Figure 1.

This seems incorrect. Mobile networks are already tunneling no matter what, so no configured tunneling is required. In fact, there is plenty of evidence that IPv6 roaming works, and the challenges are more in the area of accounting, filtering and other services than actual connectivity.

But my biggest concern with the document is that it spends quite a lot of time explaining the on-demand model and the IPv6-only model (and the latter should be explained, I agree) but spends almost no time explaining the issues and deployment advice for the primary recommended model, dual stack. In particular, the document should probably explain how to deploy NAT44 and IPv6 together, how the gradual increase of traffic on IPv6 side of dual stack (e.g., akamai, google) will help reduce required NAT44 resources, etc.

[Ballot discuss]
In Section 3.1, the "delaying exhaustion" approach has in my opinion been described in the wrong way. Obviously, the exhaustion has at a global level already happened. In addition, private-address space usage for end users is already relatively common practice in mobile networks even prior to exhaustion. I would rephrase this part of the document as something that conserves address resources the operator has to dedicate to these networks. The last part of Section 3.1 concludes that support for NAT44 and private addresses is required. I would rephrase this as something that has already been going on, and is a natural deployment model for the operators today.

Then the document goes on to discuss the dynamic allocation of IPv4 addresses. While this has been extensively discussed in the industry, I think it is largely a fantasy. The reasons are pretty well covered in the document, but the document should make it clearer that this is not a real option.

Section 3.1 also makes the argument that IPv6 functionality is not tested or deployed at all in the existing handsets and therefore only new handsets can really be used for IPv6. I do not buy this argument for several reasons. First of all, some handsets are known to work with IPv6. And those new handsets won't be tested and deployed either. Third, I think it is basically wrong to advice waiting for new features as opposed to starting to actually do something with the functionality that exists. Finally,  the argument is made in the context of improving IPv4 address usage efficiency, and this is technically independent of any IPv6 deployment.

I like the conclusions at the end of Section 3.1, but based on the above I'd change the private address phrasing, and I would remove the "investigate on-demand addressing" suggestion.

Section 3.2:

  An obvious advantage of centralizing the NAT and using
  overlapped private IPv4 addressing is that a large number of mobile
  subscribers can be supported with a common limited pool at the BR.

I don't think this is obvious at all. Once you have, say, a million subscribers on a box, you already achieve extremely high address sharing efficiencies, the additional benefit from centralizing further seem marginal at best. There are also very obvious disadvantages to running large networks with a central choke point (say, route all traffic in the United States to a single device so that we can NAT the traffic).

[Ballot comment]
Seems like any statements like the following predicting the final
allocation of IPv4 addresses are likely to be out-of-date or
inaccurate.  I suggest eliding text like the following from section 3.1:

  The '/8' IANA blocks for Regional Internet
  Registries (RIRs) are projected to 'run-out' soon.  Subsequently, the
  addressing pool available to RIRs for assignment to Internet Service
  Providers is anticipated to run-out in the following 2-3 years.

[Ballot comment]
Following the Gen-ART Review by Kathleen Moriarty on 21-Feb-2011,
  several changes were agreed.  However, a revised document has not
  been posted yet.  Please make sure the revisions get included.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Mobile Networks Considerations for IPv6 Deployment) to Informational RFC


The IESG has received a request from the IPv6 Operations WG (v6ops) to
consider the following document:
- 'Mobile Networks Considerations for IPv6 Deployment'
  as an Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-02-21. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-v6ops-v6-in-mobile-networks/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-v6ops-v6-in-mobile-networks/

Abstract

  Mobile Internet access from smartphones and other mobile devices is
  accelerating the exhaustion of IPv4 addresses.  IPv6 is widely seen
  as crucial for the continued operation and growth of the Internet,
  and in particular, it is critical in mobile networks.  This document
  discusses the issues that arise when deploying IPv6 in mobile
  networks.  Hence, this document can be a useful reference for service
  providers and network designers.

State changed to AD Evaluation::Revised ID Needed from Publication Requested.
Folks,

I have reviewed this draft and believe that it is almost ready for publication. However, I would like you to take one more look at Figure 1 to make sure that it matches the text below. For example:

- you never tell the reader what a BS is
- the diagram says that the MNG is part of the visitor network

I will put the document in AD Evaluation:Revised ID Needed. As soon as you correct these small issues, I will send the document for full IETF review.

                                                Happy Holidays,
                                                  Ron

> (1.a) Who is the Document Shepherd for this document? Has the
> Document Shepherd personally reviewed this version of the
> document and, in particular, does he or she believe this
> version is ready for forwarding to the IESG for publication?

The document shepherd is Fred Baker. Yes, I believe that it is ready for IESG consideration.

> (1.b) Has the document had adequate review both from key WG members
> and from key non-WG members? Does the Document Shepherd have
> any concerns about the depth or breadth of the reviews that
> have been performed?

The document has been reviewed in v6ops working group meetings and on the v6ops mailing list. There acknowledgements section lists multiple reviewers, several of which are mobile operators or makers of mobile equipment. I would not object to further reviews, but I don't consider them necessary.

> (1.c) Does the Document Shepherd have concerns that the document
> needs more review from a particular or broader perspective,
> e.g., security, operational complexity, someone familiar with
> AAA, internationalization or XML?

no

> (1.d) Does the Document Shepherd have any specific concerns or
> issues with this document that the Responsible Area Director
> and/or the IESG should be aware of? For example, perhaps he
> or she is uncomfortable with certain parts of the document, or
> has concerns whether there really is a need for it. In any
> event, if the WG has discussed those issues and has indicated
> that it still wishes to advance the document, detail those
> concerns here. Has an IPR disclosure related to this document
> been filed? If so, please include a reference to the
> disclosure and summarize the WG discussion and conclusion on
> this issue.

I am not aware of an IPR disclosure. While some of the recommendations in the document are unusual in current networks, such as assigning an IPv4 address to a device only when it needs one, it is not out of bounds as a procedure that operators may choose to adopt.

> (1.e) How solid is the WG consensus behind this document? Does it
> represent the strong concurrence of a few individuals, with
> others being silent, or does the WG as a whole understand and
> agree with it?

The draft has largely been driven by its author, but has support from operators in the community. As is often the case in v6ops, the number of people commenting has been limited, but I think it reflects adequate support.

> (1.f) Has anyone threatened an appeal or otherwise indicated extreme
> discontent? If so, please summarise the areas of conflict in
> separate email messages to the Responsible Area Director. (It
> should be in a separate email because this questionnaire is
> entered into the ID Tracker.)

no

> (1.g) Has the Document Shepherd personally verified that the
> document satisfies all ID nits? (See the
> Internet-Drafts Checklist
> and
> http://tools.ietf.org/tools/idnits/
> ). Boilerplate checks are
> not enough; this check needs to be thorough. Has the document
> met all formal review criteria it needs to, such as the MIB
> Doctor, media type and URI type reviews?

The document shepherd has indeed done so. There are four very minor issues that the analysis raised:

1) the idnits tool complained about the us of an RFC 1918 address in the document. The actual text is:

3.2. NAT Placement in the mobile networks

In the previous section, we observed that the NAT44 functionality is
needed in order to conserve the available pool, and delay public IPv4
address exhaustion. However, the available private IPv4 pool itself
is not abundant for large networks such as mobile networks. For
instance, the so-called NET10 block [RFC1918] has approximately 16.7
million private IPv4 addresses starting with 10.0.0.0. A large
mobile service provider network can easily have more than 16.7
million subscribers attached to the network at a given time. Hence,
the private IPv4 address pool management and the placement of NAT44
functionality becomes important.

In that context, I consider it vey appropriate to reference the specific prefix.

2) the idnits tool complained about three unspecified references: [IPv4], [IPv6], and [IPv4v6]. The actual text is:

3.3. IPv6-only Deployment Considerations
...
There are three dimensions to IPv6-only deployments: the network
itself, the mobile nodes and the applications, represented by the
tuple [nw, mn, ap]. The goal is to reach the co-ordinate [IPv6,
IPv6, IPv6] from [IPv4, IPv4, IPv4]. ...

It is normal for IETF Last Call, AD Review, or IESG review to come up with issues requiring an updated draft. I have asked the author to fix this by using () or {} should such a draft be required. Alternatively, the change could be sent in an RFC Editor note

> (1.h) Has the document split its references into normative and
> informative?

It lists them all as informative. There are five, two from 3GPP, one from 3GPP2, and two RFCs, that could be considered normative. However, they are used in an informative way - "networks that conform to [] would be examples of networks this consideration would apply to, but there are other examples as well." So to me, it's not really worth arguing about.

> Are there normative references to documents that
> are not ready for advancement or are otherwise in an unclear
> state? If such normative references exist, what is the
> strategy for their completion? Are there normative references
> that are downward references, as described in [RFC3967]? If
> so, list these downward references to support the Area
> Director in the Last Call procedure for them [RFC3967].

There are no normative references.

> (1.i) Has the Document Shepherd verified that the document IANA
> consideration section exists and is consistent with the body
> of the document?

Yes.

> (1.j) Has the Document Shepherd verified that sections of the
> document that are written in a formal language, such as XML
> code, BNF rules, MIB definitions, etc., validate correctly in
> an automated checker?

The document contains no formal language sections.

> (1.k) The IESG approval announcement includes a Document
> Announcement Write-Up. Please provide such a Document
> Announcement Write-Up? Recent examples can be found in the
> "Action" announcements for approved documents. The approval
> announcement contains the following sections:

Technical Summary

Mobile Internet access from smartphones and other mobile devices is
accelerating the exhaustion of IPv4 addresses. IPv6 is widely seen
as crucial for the continued operation and growth of the Internet,
and in particular, it is critical in mobile networks. This document
discusses the issues that arise when deploying IPv6 in mobile
networks. Hence, this document can be a useful reference for service
providers and network designers.

Working Group Summary

The IPv6 Operations Working Group discussed this document at IETF-77 and IETF-78 and in an email Working Group last Call. There were comments made, and the commentators stated that they were comfortable with the resolution in the final document.

Document Quality

We are starting to see operational mobile networks with the set of problems the document addresses and considering similar solutions. Comments from the working group suggested that the writeup was useful to them.