Indeed, interesting stuff. Thanks for the reference to PDP; it
explained a few of the lower-level things that have been puzzling me.
However, it's still misleading, because you are focusing on the
transport layer, and NOT on the TCP/IP layer.
It is not correct that "TCP/IP begins and ends at the edge of the cell
network, on the network provider's Internet gateway" -- UNLESS you
would choose to describe your typical home network with NAT router
that way.
The usual way to describe this situation is, "You have TCP/IP
connectivity to the internet, but sit behind a firewall".
Indeed, you can't build IP connections to your phone via the cellular
path. (Except maybe you can reply with an FTP data connection --
dunno, haven't tried it. That would be up to the gateway to allow or
not -- and the only way it would allow it would be based on having an
outgoing FTP control connection, and doing the reverse translation
when the connection comes back. I can think of several good reasons
NOT to support this.)
However, the connection by which I will post this, from my laptop, is
generally considered to be a TCP/IP connection. From *MY* side, I
really can't tell that there's any NAT going on. My browser will do a
DNS lookup (which will be handled by my router), giving me a routable
IP address for Google's groups.google.com server. My laptop happens to
be hardwired at the moment, so it'll go directly to Ethernet, after
first wrapping the TCP/IP packets in ethernet headers. At my network's
edge, the ethernet headers will be stripped, and the IP headers will
be stripped and new ones created. My private IP address will be
replaced with one that Comcast has assigned me. Comcast could do the
same trick, of giving me a private IP address and using NAT at their
edge, but they don't. (The economics are different -- the amount of
bandwidth involved is hugely more).
My router will then put on new ethernet headers, to transmit to my
cable modem, which will strip them off, update the hop count in the IP
headers, and wrap them in DOCSIS headers for transmission on the cable
modem. The cable head will strip the DOCSIS headers, and forward the
TCP/IP payload to the next hop, after incrementing the hop count.
At any point along the way, these packets may be split up into smaller
packets.
Google will see, not the IP address of my laptop, but the IP address
assigned by Comcast. This address is shared by all the devices on my
home network, including my phones. Well, except for my digital Comcast
phone, and my cable box, each of which has its own IP address!
PDP is no different from any of this transport layer stuff. It is
basically a frame relay system, according to your reference -- and I
was running TCP/IP over frame relay in 1995.
So why does all this matter? It's best to look at it functionally:
Here's what's in it for us, at the level of TCP/IP:
* We can open TCP/IP connections normally.
* Our IP address, when communicating over the cellular network will
not be the one that the server sees. The source port may be different,
too.
* We cannot get incoming TCP/IP requests from the cellular network.
* This is no different from being behind a NAT firewall, except no
possibility of the admin opening up an incoming port forwarding for
you.
* Traceroute will show you the hops that the IP traffic takes, but not
show you any internal structure those hops may have. You only see the
IP routers along the way.
* You can't even tell that any of this is going on -- except by the
incoming silence, or sites that explicitly report back to you what IP
address they see.
To illustrate this, here's my phone's current state (I just turned off
the wifi):
rmnet0 Link encap:Ethernet HWaddr EE:B1:E9:38:05:3D
inet addr:25.128.179.204 Bcast:25.128.179.207 Mask:
255.255.255.252
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:21853 errors:0 dropped:0 overruns:0 frame:0
TX packets:21170 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:7958701 (7.5 MiB) TX bytes:2785940 (2.6 MiB)
# /system/xbin/bb/route
/system/xbin/bb/route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref
Use Iface
10.165.17.242 * 255.255.255.255 UH 0 0
0 rmnet0
10.177.0.34 * 255.255.255.255 UH 0 0
0 rmnet0
25.128.179.204 * 255.255.255.252 U 0 0
0 rmnet0
default 25.128.179.205 0.0.0.0 UG 0 0
0 rmnet0
The 25.128.179.204/30 subnet is a point-to-point link, consuming 4 IP
addresses, but those IP addresses only mean anything to the two
partners.
All traffic goes to that 25.128.168.205 on the other end of the radio
link. It's not processed as TCP/IP until it reaches there -- until
then, it's just travelling a virtual circuit, taking all net traffic
from my phone to that destination.
Eventually, my IP address in the source address header fields is
swapped out for a public one:. 208.54.14.97 at the moment.
The 10.* addresses in the routing table are interesting. They appear
to be DNS servers, with their own redundant routing table entries. I'm
not sure why that's done -- perhaps to minimize the risk of having
some additional connection, say a VPN, conflict? These DNS servers are
using private IP addresses -- they, too, are not reachable from the
outside. For DNS servers to operate, they need access to the internet.
So clearly, there is at least one level of NAT translation that is
happening further out than the cellular component. The traceroute
below makes it clear that for T-Mobile, the final public IP is not
assigned until we get to their edge at Level3.
(ATT is similar, but uses the 172.0.0.0/12 block of private
addresses.)
traceroute to google.com (74.125.53.106), 30 hops max, 38 byte packets
1 10.176.80.136 (10.176.80.136) 2904.633 ms 79.284 ms 90.241 ms
2 * 10.176.80.181 (10.176.80.181) 164.367 ms 10.176.80.133
(10.176.80.133) 211.121 ms
3 10.176.80.129 (10.176.80.129) 247.650 ms 209.778 ms 240.052 ms
4 10.176.6.165 (10.176.6.165) 229.767 ms 10.176.6.169
(10.176.6.169) 249.786 ms 211.975 ms
5 10.176.6.177 (10.176.6.177) 247.773 ms 206.909 ms 10.176.6.181
(10.176.6.181) 250.091 ms
6 10.176.96.209 (10.176.96.209) 212.005 ms 249.786 ms
10.176.96.193 (10.176.96.193) 199.982 ms
7 10.176.96.220 (10.176.96.220) 199.677 ms 209.869 ms 252.411 ms
8 10.176.0.25 (10.176.0.25) 200.226 ms 199.799 ms 199.859 ms
9 ge-6-24.car2.Seattle1.Level3.net (4.79.106.37) 209.930 ms
278.015 ms ae-1-51.edge1.Seattle3.Level3.net (4.68.105.12) 239.960
ms
10 GOOGLE-INC.edge1.Seattle3.Level3.net (4.59.232.34) 230.927 ms
209.656 ms ae-2-52.edge1.Seattle3.Level3.net (4.68.105.44) 219.940
ms
11 209.85.249.34 (209.85.249.34) 217.712 ms 209.85.249.32
(209.85.249.32) 210.205 ms GOOGLE-INC.edge1.Seattle3.Level3.net
(4.59.232.34) 219.666
ms
12 209.85.249.32 (209.85.249.32) 249.695 ms 209.85.249.34
(209.85.249.34) 219.818 ms 210.113 ms
13 209.85.250.144 (209.85.250.144) 259.704 ms 216.239.46.212
(216.239.46.212) 216.553 ms 209.85.250.126 (209.85.250.126) 236.145
ms
14 216.239.48.165 (216.239.48.165) 217.347 ms 209.85.250.146
(209.85.250.146) 231.872 ms 64.233.174.131 (64.233.174.131) 351.989
ms
15 * * 72.14.232.6 (72.14.232.6) 641.358 ms
16 pw-in-f106.1e100.net (74.125.53.106) 179.932 ms 72.14.232.6
(72.14.232.6) 101.441 ms pw-in-f106.1e100.net (74.125.53.106)
99.853 ms
>From the TCP/IP standpoint, each of these is a hop, and it doesn't
matter whether there's any encapsulation, encoding, recoding, etc. End-
to-end, it behaves as a IP path, capable of transporting TCP.
On another (related) topic:
So why does my iPhone sometimes get two PDP connections, with two IP
addresses? Is this a part of normal handoff? Initial cell selection?
Does my Nexus do it, too, and I just haven't caught it in the act yet?
On Feb 4, 1:55 am, Mike <[email protected]> wrote:
> Hi,
>
> My answer wasn't incorrect... you are simply misunderstanding what
> "end-to-end" means in this context. This is getting a bit off topic,
> but it's interesting stuff.
>
> TCP/IP begins and ends at the edge of the cell network, on the network
> providers Internet gateway. Between the gateway and the phone itself
> there is no TCP/IP. This is the exact reason why you CANNOT build TCP/
> IP connections from a server to a phone. You can ONLY build
> connections from a phone to a server.
>
> For further clarification
> seehttp://en.wikipedia.org/wiki/Packet_Data_Protocol#PDP_Context
>
> When the gateway receives the outgoing request from the phone, the
> gateway assigns its own IP address and a port number to the request
> and puts it on to the Internet as a standard TCP/IP data packet. This
> context may exist for some time on the gateway, or it may be flushed
> very quickly, there is no way to predict. It's not even possible for
> the application on the phone to know what IP address is being used on
> its behalf.
>
> The packet coming back to the phone is stripped of its TCP/IP envelope
> at the gateway and then put on the cell network using whatever packet
> technology the cell network uses. This is the very meaning of the
> word "gateway"... it is a gateway between two completely different
> networks that work in completely different ways, it is a protocol
> converter.
>
> - Mike
> NAVTEQ Network for Developershttp://NN4D.com
>
> Disclaimer: I work for NAVTEQ and these are my personal opinions which
> do not necessarily reflect NAVTEQ’s views
>
> On 4 Feb, 07:13, Bob Kerns <[email protected]> wrote:
>
>
>
> > This isn't correct, or is misleading. It's kind of like saying
> > "ethernet doesn't use TCP/IP" or "WiFi doesn't use TCP/IP" or "dialup
> > modems don't use TCP/IP" or "DSL doesn't use TCP/IP" or "Cable doesn't
> > use TCP/IP".
>
> > If you drop below the level of TCP/IP, to how the data is physically
> > moved, then yes, you are below TCP/IP, and in that sense, cell
> > networks don't use TCP/IP.
>
> > However, they CARRY TCP/IPtraffic. And that's what thoseIPaddresses
> > are --IPaddresses. You can establish TCP connections.
>
> > TCP/IPis actually two protocols.IPis the lower-level of the two,
> > handling addressing and routing. It is completely agnostic as to how
> > the packets are transported. You could use carrier pigeons. Really!
>
> >http://www.rfc-editor.org/rfc/rfc1149.txt
>
> > I don't know if anybody's done it -- but it wouldn't surprise me.
>
> > TCP is on top ofIP, and gives you reliable transmission and end-to-
> > end connection semantics.
>
> > Now, perhaps you meant to contrast the situation with VOIP, where
> > voice is carried overIP. Indeed, voice data is not (normally) carried
> > over cell networks as TCP/IP, though it's possible. (Not necessarily
> > acceptable, but possible).
>
> > But every phone with a data plan is using the cell networks to carry
> > TCP/IP.
>
> > Your gatewayaddresswill be theaddressof the gateway server, but
> > yourIPaddresswill be yourIPaddressthat your server uses to send
> > traffic to you.
>
> > I don't know the current state of the art for how stable your
> > phone'sIPaddresswill be. I can tell you that my phone switches cell sites
> > surprisingly often, but I've not watched theIPaddresses
> > simultaneously.
>
> > But you don't switchIPaddresses when you move from Access Point to
> > Access Point on the same WiFi network. In theory, you could retain the
> > sameIPaddressfor the life of your phone, with a sufficiently clever
> > and powerful cell network.
>
> > In practice, however, that's unreasonable. But perhaps someone can
> > tell me just when it changes. And why, after rebooting, I have TWO?
> > One for each tower? We're at the limits of my networking knowledge
> > when we come to the specifics of how it's layered on top of the
> > cellular network.
>
> > BTW, Vertifi, this "Class B/Class C" terminology is long obsolete;
> > addresses have not been allocated by that scheme for many years. It
> > consumed too much IPv4addressspace. Instead, the number of prefix
> > bits is specified, like 192.168.0.0/24 -- where 24 is not necessarily
> > a multiple of 8. I don't know if your server farm people are expecting
> > "Class C" to refer to distinct networks, or simply using the term as a
> > holdover, but treating it as the arbitrary distinction that it is. But
> > certainly we should not import any significance to thoseIPaddresses
> > being allocated from some larger block than /24. They could all be
> > from the same subnet, so far as the cellular network is concerned.
> > This would be some network in some bunker somewhere, with a bunch of
> > NAT servers, with multiple hot connections to various pieces of the
> > backbone.
>
> > TheIPaddressassigned to the phone will be anaddressspecific to
> > the link between you and the next piece of equipment that actually
> > treats your data as TCP/IPtraffic. My iPhone reports it as
> > 10.135.130.117; I've never seen it other than a 10.0.0.0/8 non-
> > routable privateaddress. This is translated via NAT further upstream,
> > so servers on the other end see a routableIPaddress; at the moment,
> > mine is 98.210.255.162.
>
> > In theory, this can be different for every TCP connection! But there
> > are a few things that care about connections with the same originating
> > system -- active FTP being one. So normally, this syntheticIPaddress
> > doesn't change, so long as you have one active TCP or recent
> > connection, or recent UDP traffic, but after you've been idle or a
> > bit, it purges its mapping tables, and on your next connection, you
> > appear to come from a newIPaddress.
>
> > This is really no different than any large enterprise NAT networking
> > environment. Just bigger.
>
> > Anyway -- while there are holes in my explanation, I don't think
> > there's anything inaccurate. But I hate being wrong, so please jump
> > in with any corrections or additions!
>
> > On Feb 3, 7:38 am, Mike <[email protected]> wrote:
>
> > > The simple answer is that cell networks don't use TCP/IP. What you
> > > see is theIPaddressof the gateway server that happens to have
> > > generated the request. This could change on every request and is not
> > > time based.
>
> > > Hope it helps.
>
> > > - Mike
> > > NAVTEQ Network for Developershttp://NN4D.com
>
> > > On 3 Feb, 15:35, Vertifi <[email protected]> wrote:
>
> > > > Hello,
>
> > > > I have an app which performs some online functions to a web server
> > > > farm we operate using URLConnection. I'm finding that theclientIP
> > > >addressof the phone seems to change after a fairly brief period of
> > > > inactivity.
>
> > > > For example, please see these timestamps and the correspondingclient
> > > >IPaddresses:
>
> > > > 2010-02-03 09:46:47 / 32.152.30.98
> > > > 2010-02-03 09:47:05 / 32.152.30.98
> > > > 2010-02-03 09:57:21 / 32.152.218.197
> > > > 2010-02-03 09:59:53 / 32.152.23.19
>
> > > > This is sitting in a stationary location (on an AT&T EDGE network) in
> > > > my office. Is there some reason for this behavior?
>
> > > > Any advice would be greatly appreciated
>
> > > > Regards,
> > > > Chris @ Vertifi- Hide quoted text -
>
> > - Show quoted text -
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
