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/IP traffic. And that's what those IP addresses
are -- IP addresses. You can establish TCP connections.

TCP/IP is actually two protocols. IP is 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 of IP, 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 over IP. 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 gateway address will be the address of the gateway server, but
your IP address will be your IP address that your server uses to send
traffic to you.

I don't know the current state of the art for how stable your phone's
IP address will be. I can tell you that my phone switches cell sites
surprisingly often, but I've not watched the IP addresses
simultaneously.

But you don't switch IP addresses when you move from Access Point to
Access Point on the same WiFi network. In theory, you could retain the
same IP address for 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 IPv4 address space. 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 those IP addresses
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.

The IP address assigned to the phone will be an address specific to
the link between you and the next piece of equipment that actually
treats your data as TCP/IP traffic. My iPhone reports it as
10.135.130.117; I've never seen it other than a 10.0.0.0/8 non-
routable private address. This is translated via NAT further upstream,
so servers on the other end see a routable IP address; 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 synthetic IP address
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 new IP address.

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 <michael.mo...@navteq.com> wrote:
> The simple answer is that cell networks don't use TCP/IP.  What you
> see is the IP address of 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 <c...@eascorp.org> wrote:
>
>
>
> > Hello,
>
> > I have an app which performs some online functions to a web server
> > farm we operate using URLConnection.  I'm finding that the client IP
> > address of the phone seems to change after a fairly brief period of
> > inactivity.
>
> > For example, please see these timestamps and the corresponding client
> > IP addresses:
>
> > 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

-- 
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

Reply via email to