That Packet Has More IP Addresses Than I Can Count – Almost

How many IP addresses does an IP packet have when it is sent between two devices? In a simple world only two, i.e. one for the destination and one of the source. The fun thing is how often that changes between source and destination due to all the tunneling and NATing applied. Let me give you an example of a typical setup of mine, a netbook connected via a Wifi / 3G bridge with a VPN tunnel established:

Leg 1: Netbook – WiFi / 3G bridge

As the VPN is established an IP packet is tunneled over IP. Thus there are 2 IP addresses to identify me as the source and two IP addresses for the destination:

  • IP-1: IP address given by the Wifi bridge to the netbook
  • IP-2: IP address of the VPN remote endpoint

    Inside the VPN tunnel:

  • IP-3: IP address given by the VPN service to the tunnel end point (i.e. netbook)
  • IP-4: IP address of the destination (e.g. the web server)

Leg 2: Wi-Fi / 3G bridge to Mobile Network Gateway (GGSN)

  • IP-5: IP address given to the WiFi bridge from the GGSN (NAT)
  • IP-2: -unchanged-

    Inside the VPN tunnel:

  • IP-3: -unchanged-
  • IP-4: -unchanged-

Leg 3: GGSN to VPN remote endpoint

  • IP-6: IP address of the GGSN after NAT translation
  • IP-2: -unchanged-

    Inside the VPN tunnel:

  • IP-3: -unchanged-
  • IP-4: -unchanged-

Leg 4: VPN remote end point to web server

  • IP-7: IP address of the VPN remote endpoint after NAT translation
  • IP-2: -unchanged-

    Inside the VPN tunnel:

  • IP-3: -unchanged-
  • IP-4: -unchanged-

Leg 1 to 4 are not the full story, there's also tunneling performed in the wireless network:

Tunneling between SGSN and GGSN

User data packets are tunneld over IP in the wireless core network. Here the packet looks like this:

  • IP-7 SGSN network internal IP address
  • IP-8 GGSN network internal IP address

    User data packet:

  • IP-5: -unchanged-
  • IP-2: -unchanged-

    Inside the VPN tunnel:

  • IP-3: -unchanged-
  • IP-4: -unchanged-

Base Station to RNC

While in the past the 3G radio access network was based on ATM, it is more and more replaced with Ethernet and IP for routing. This gives the packet another two IP addresses in this part of the network:

  • IP-9 Base station network internal IP address
  • IP-10 RNC network internal IP address

    User data packet:

  • IP-5: -unchanged-
  • IP-2: -unchanged-

    Inside the VPN tunnel:

  • IP-3: -unchanged-
  • IP-4: -unchanged-

RNC to core network IP address

No, we are not finished yet, the interface between RNC and SGSN is also based on IP these days and again tunneling is applied:

  • IP-11 RNC network internal IP address on core network bound interface
  • IP-12 SGSN network internal IP address on RAN bound interface

    User data packet:

  • IP-5: -unchanged-
  • IP-2: -unchanged-

    Inside the VPN tunnel:

  • IP-3: -unchanged-
  • IP-4: -unchanged-

12 different IP addresses are used in the course of transfering a packet between source and destination! WOW!

4 thoughts on “That Packet Has More IP Addresses Than I Can Count – Almost”

  1. This is pure nitpicking, but isn’t Direct Tunnel more commonly used nowdays? That would reduce the RNC-SGSN-GGSN to RNC-GGSN. In other words, saving two addresses (the SGSN addresses).

    It can be reduced a bit further with I-HSPA-type configurations, but they are not very prolific at the moment.

    But yes, quite a few addresses there. Luckily most of the addresses are from the private address space and used by multiple users so that it doesn’t deplete IPv4 address space.

    I guess only two of the addresses are mobile specific and two more from the public address space (GGSNRNC)

  2. Outside of being the one responsible for tracing and troubleshooting traffic shows in the carrier’s network, I have no problem with this other than the NAT.

    ugg, the NAT. Other than possible MTU issues the IP endpoints have no reason to care about tunneling.

    Alas I do not expect to see significant wireless carrier adoption of IPv6 in the next few years.

Comments are closed.