Subject: [3gv6] draft on reducing net10 usage

From: Jari Arkko <[email-masked]>
Date: Tue, 09 Feb 2010 19:29:38 +0200

I wanted to advertise a draft that we published today. It discusses the 
use of per-interface NAT bindings that can significantly reduce the 
amount of private address space usage in many deployments -- possibly 
including 3GPP networks. There's no magic here, its all old stuff that 
has existed in, say, dual stack lite for a long time. However, our draft 
explains how this can be done on any device without additional tunnels 
or setup protocols. The algorithm is entirely an implementation matter 
internal to the NAT or the gateway in common cases, such as on a 3G GGSN.

This work is useful for situations where RFC 1918 space is becoming 
insufficient. It fits well together with a Dual Stack & NAT44 
deployment. But it is not a solution to world hunger; its one technique 
that may be useful, either on its own or together with some other tools.

Here's the draft:

  http://tools.ietf.org/html/draft-arkko-dual-stack-extra-lite

  "Scalable Operation of Address Translators with Per-Interface Bindings"

  "This document explains how to employ address translation in networks
   that serve a large number of individual customers without requiring a
   correspondingly large amount of private IPv4 address space."

Comments are welcome.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Thu, 25 Feb 2010 02:46:52 +0200

李振强,

> It is a clever technique to be clarified in your draft.

Thanks. Its an old technique though, not my idea.

> In 3GPP network, it is a point-to-point link between UE and GGSN( or 
> PDN gateway).

Yes.

> A distinct TEID is used for each PDN connection, which can be used to 
> complete the mapping in GGSN(or PDN gateway).

Yes.

> Thus same IPv4 address or same IPv6 prefix can be assigned to 
> different UEs.

Yes for IPv4. For IPv6 there does not appear to be any reason for doing so.

> I do not know whether it is sufficient or not to adopt this technique 
> in GGSN(or PDN gateway). Is there any impact on other network 
> entities(SGSN, UE, HLR etc) to be further evaluated?

AFAIK, there should not be any effects to other parts of the mobile 
network. Current networks appear to be able to handle overlapping 
private address space for private APNs just fine, for instance. If there 
were problems in accounting systems, for instance, we would probably 
have seen them already. The draft just describes a more uniform or 
extreme form of this overlap.

However, there is of course one obvious effect of using overlapping 
address space: host-to-host communications require more effort from the 
applications. The effect is similar to having each separate GGSN employ 
its own net10 space. This is an issue that can really only be solved 
elegantly with IPv6. And that is what I would recommend for massive 
deployments of operator services that require host to host 
communications. Such as IMS.  (What Section 5 tries to say is that even 
if you use IPv6, it still makes sense to support dual stack and use 
per-interface NAT on the IPv4 side. Given the technique in this draft, 
lack of addresses is not a reason to disable IPv4; you can still let all 
devices reach the IPv4 Internet through NAT44.)

Jari

---

From: "Laganier, Julien" <[email-masked]>
Date: Wed, 24 Feb 2010 18:48:54 -0800

Jari,

Jari Arkko wrote:
> [...]
> 李振强 wrote:
> private address space for private APNs just fine, for instance. If
> there were problems in accounting systems, for instance, we would probably
> probably have seen them already. The draft just describes a more uniform
> or extreme form of this overlap.

There might be an impact on the Policy and Charging Control (PCC) that we haven't seen yet because PCC hasn't been deployed in NATed mobile core so far. In particular it seems there might be an impact on the interactions between the Application Function (AF), the Policy and Charging Rules Function (PCRF), and the Policy and Charging Enforcement Function (PCEF.)

The AF is pushing to the PCRF which pushes to the PCEF IP filter information used to identify the service data flow for policy control and/or differentiated charging.

Because the AF may be a third party application server located beyond the NAT44, the IP filter information generated by the AF will be based on the UE address seen after NATing occurred, i.e., a public IPv4 address. 

Since the public IP address is in fact in use by many UEs in a NATed environment, if the IP filter does not include port numbers, the Policy and Charging Enforcement Function (PCEF) might not be able to distinguish packets sent by / bound to the UE using the AF from packets sent by / bound to UEs NATed to the same public IP address. 

Even if the IP filter does include port numbers, the correct mapping by the PCC architecture can only occur if the PCRF or the PCEF have access to the NAT bindings. That requires the NAT44 to be interfaced with either of the PCRF or the PCEF...

--julien

---

From: Jari Arkko <[email-masked]>
Date: Thu, 25 Feb 2010 08:36:32 +0200

Julien,

> Even if the IP filter does include port numbers, the correct mapping by the PCC architecture can only occur if the PCRF or the PCEF have access to the NAT bindings. That requires the NAT44 to be in…

Yes -- I agree these are potential impacts. But are they impacts due to 
per-interface NAT bindings, or impacts simply through the use of NAT? 
Again, the only real solution that I can see to avoiding NAT impacts is 
to move the applications in question to IPv6...

Jari

---

From: "Laganier, Julien" <[email-masked]>
Date: Thu, 25 Feb 2010 07:26:36 -0800

Jari,

> > There might be an impact on the Policy and Charging Control (PCC)
> > that we haven't seen yet because PCC hasn't been deployed in NATed
> > mobile core so far. In particular it seems there might be an impact on
> > the interactions between the Application Function (AF), the Policy and
> > Charging Rules Function (PCRF), and the Policy and Charging Enforcement
> > Function (PCEF.)
> >
> > The AF is pushing to the PCRF which pushes to the PCEF IP filter
> > information used to identify the service data flow for policy control
> > and/or differentiated charging.
> >
> > Because the AF may be a third party application server located beyond
> > the NAT44, the IP filter information generated by the AF will be based
> > on the UE address seen after NATing occurred, i.e., a public IPv4
> > address.
> >
> > Since the public IP address is in fact in use by many UEs in a NATed
> > environment, if the IP filter does not include port numbers, the Policy
> > and Charging Enforcement Function (PCEF) might not be able to
> > distinguish packets sent by / bound to the UE using the AF from packets
> > sent by / bound to UEs NATed to the same public IP address.
> >
> > Even if the IP filter does include port numbers, the correct mapping
> > by the PCC architecture can only occur if the PCRF or the PCEF have
> > access to the NAT bindings. That requires the NAT44 to be interfaced
> > with either of the PCRF or the PCEF...
> 

In general there is impact through the use of NAT.
 
> to move the applications in question to IPv6...

I would agree. 

Moreover, if my understanding that PCC hasn't been widely deployed yet is correct, one can conjecture that it is because no application functions requiring PCC (e.g. IMS) is widely deployed yet either. 

In such a case we have a better outlook that moving existing applications to IPv6: We can simply deploy new applications on IPv6.

--julien

---

From: jouni korhonen <[email-masked]>
Date: Mon, 1 Mar 2010 01:52:20 +0200

Hi Julien,

Just few comments below.

> In general there is impact through the use of NAT.

I agree that there may be issues when NAT is involved. However, the placement of NATs also matter here. If AFs in a PDN see private addressed traffic and NATing is only done when traffic exists certain PDN to e.g. Internet, this should not have any PCC impact. One can always break things or avoid breaking things with deployment decisions.. 

>> to move the applications in question to IPv6...

+1

- Jouni

> _______________________________________________
> 3gv6 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/3gv6

---

From: Sri Gundavelli <[email-masked]>
Date: Sun, 28 Feb 2010 20:39:38 -0800

Hi Jari,

Thanks for sharing the draft.

Agree with this mechanism, the use of interface-id as the distinguishing
element for sharing the address space. Agree with many of the considerations
in the spec. Its well written and a very useful tool in the transition tool
kit.

Regards
Sri