gogoNET

IPv6 & Networking the Internet of Things

Although they may be temporary, it looks like large scale NATs will be
deployed as a bridge between v4 and v6 in ISP and mobile networks. What
are your thoughts, opinions and advice for operators contemplating
their deployment?

Views: 1250

Reply to This

Replies to This Discussion

"You don't need to be an expert to get such metrics. The fact that there's a DHCP or NAT router on the tower does not hide the other fact that we constantly get the same few IPs being used on the Internet, and being trackable to a single tower, independantly of the user connected to it with its smartphone."

I never said there was DHCP or NAT at the tower. I had said it's further back in the network. Please explain how an IP address is traceable to a single tower, when the equipment to provide an address doesn't exist there. As I mentioned in another note, the company I work for (I'm the operations manager there) is working on a LTE roll out for a major carrier. At the cell sites, there is the incoming fibre, or in some cases microwave, that connects to an Ethernet switch and then to the radio base station. There is no other equipment that might affect the data connection. A cell tower, with respect to IP data, is essentially equivalent to a big WiFi hotspot. It simply bridges the data to the internal network, with routing, DHCP, NAT etc. performed elsewhere. The only IP addresses at the cell sites are those used for management of the equipment. If they did otherwise, with NAT, routing etc. at the cell site, it would be very difficult to move the phone while using IP, as the web site etc., that you're connected to would see different IP addresses as you moved, and think it's an entirely different connection.

As an experiment, connect to a site such as www.grc.com*, which displays the IP address that it sees, which would be the public address you NAT to and see if it changes as you move around town.

*You have to run the ShieldsUp! port scan. There are other sites that will display your IP address as well.

There are tons of sites that will report you the public IPv4 address they see when you connect to them. Not a big deal. Personnally I will prefer getting this info from a known secure site rather than an unmanaged site or a commercial site that wants to sell you their security solution (using sometimes fake reports...)

Anyway, the "ShieldsUp!" port scan finds nothing on my PC, except its public IPv4 address, and it does not test the IPv6 address through which the test could be reached (does grc.com have an IPv6 address that I can connect to?).

Most personal firewalls today don't handle the IPv6 trafic, and won't block the IPv6 traffic, so port scans via IPv6 used by malwares may still find many more vulnerable clients than with IPv4. With the growing number of Internet users that have an IPv6 connection (even through a tunnel), this may be a concern.

 

Sometimes, some ISPs did not inform their customers before activating the IPv6 connectivity, this is the case of my ISP, and I noticed it working through a new tunnel only weeks after the change of its router firmware. How lame they can be ! Thanks I was not attacked, because I had previously already used some third-party Teredo tunnels, and preconfigured and checked my security, but may be the Teredo tunnel broker was implementing the firewall itself, but not my ISP.

 

So I had to check this again to see if I was vulnerable through this new unnoticed tunnel; it looks like my ISP filters (on its Cisco L2TPv2 tunnel) only a few wellknown ports used by Windows file/printer sharing, and outgoing SMTP connections, but nothing else (and there's no IPv6-to-IPv6 NAT: this is a lame bridge sharing data between distinct customers connected to the same L2TPv2 tunnel-broker, which also has severe bugs such as loosing essential IPv6 routing options needed for IPSEC, no longer working; my ISP has now suspended its experimentation and no longer adds new customers; Cisco will have to rework its bogous solution, or my ISP may use another technology for its final deployment)...

Sorry, I posted the wrong address from memory. The actual site is http://whatismyipaddress.com, as copied from my browser.

I can't edit or delete it, as we're only allowed 15 minutes to do so.  Perhaps one of the moderators could do it.

 

I've deleted it.

tnx

 

"Anyway, the "ShieldsUp!" port scan finds nothing on my PC, except its public IPv4 address, and it does not test the IPv6 address through which the test could be reached (does grc.com have an IPv6 address that I can connect to?)."

It shows the IPv4 address that you get through what the ISPs provide. At home & office, it shows the firewall address and not the local address. On smart phones, it shows the public address that's used for the various wireless devices. A few minutes ago, I got back from conducting my experiment to verify what I had said. I went to 3 nearby cell sites that are in a bent line. The approximate distances between sites are A-B 1 Km, A-C 2.3 Km and B-C 1.6 Km. At each site, I was no more than 50 m from the base of the site (tower or building and could look up at the antennas. I had with a Blackberry (work phone) and my own Android phone. The Android phone shows a public address that's assigned to my carrier. The Blackberry shows one for RIM, even though it's on the same carrier as my own phone. With both phones, I connected to that IP address site. On my Android phone, I also ran a utility called "G Tech Net Tools", which displays both the public and local IP addresses. As I went to the different sites, the Android always showed the exact same local and public addresses. The Blackberry would always get one of two sequential addresses and might change each time I refreshed the page. I always got the same two addresses at all three sites. This proves, at least on my carrier, that the phone's IP address is not dependent on the cell site, contrary to what you claim.

"Sometimes, some ISPs did not inform their customers before activating the IPv6 connectivity"

I thought we were discussing NAT and how each tower supposedly has only 1-3 public IPv4 addresses.

Remember this comment? "Typically, on a mobile cell, you just have a 1-3 IPv4 per cell" I'd like to know where you got that idea, which is incorrect.
May be your ISP uses adifferent strategy. Here I consistantly get the same few IPv4 addresses that almost never change, even when I'm connected with a different mobile phone (using a separate SIM card and distinct subscriber account from the same mobile carrier). The IPv4 address only changes when I move to another cell area (and it changes the same way on every phones). This means that there's no DHCP effectively giving a user-specific IPv4 address independantly of its cell position. The assignement of IPv4 addresses is geographically determined (the user access is checked by the GSM/UMTS/HSDPA network, but the IP routing, after untunnelling the authorized mobile transport is the same, we connect then to the same local proxy, which uses a private local IPv4 address; we don't have any public IPv4 address on the mobile device itself, the use of the proxy is mandatory, and it is used also to restrict the usable protocols to only HTTP, and HTTPS, and may be FTP but I never tested it; this proxy does not allow tunneling ICMP or UDP to/from the internet, except DNS only on the local link through a private local-DNS relay accessible with a static local-link IPv4 address).
Since the carriers use NAT for IPv4, I'd expect all the phones in an area to get similar public addresses (my Blackberry always got one of 2).  Now what are you referring to by cell area?  A single cell?  An area of a city?  Different city?  If the local or public IP addresses (or ports) changed as you moved, it would be impossible to maintian a TCP connection for any significant period of time.  It would also mess up many UDP services that are expecting to send the traffic to a specific address.  That said, if you travel far enough, you may get a different address, simply because you've moved from one segment of the carriers network to another.  Mobile IPv6 wll take care of that situation, as will some VPNs.
A cell is a cell: the area around a mobile network antenna (I know where they are located, their average radius is about 2 km large in my area). I don't speak about a city. Mobile networks absolutely don't care about city borders. You may even find embedded areas covered by a local cell (of just a few hundreds meters), where the larger cell creates a white zone. Here we also have "nanocells" created by home relays connected by a small USB key on DSL, fiber or cable routers (my mobile carrier is selling those small devices that can be connected on any Internet router from any ISP; it can be used by up to 5 mobile devices with a SIM card from the same mobile carrier; there's no additional usage cost than the purchase of the device; it is basically sold to extend the coverage of the mobile network within buildings, except that it does not use the mobile network infrastructure, but any available Internet infrastructure, on which it connects to the mobile carrier backbone via a VPN; the device can provide connectivity to any GSM or UMTS or HSDPA mobile device, within a very limited area and effectively creates another cell; as long as the device remains connected via Internet, its assigned IPv4 address over the VPN almost never changes). Other ISPs that also operate mobile networks are starting to bundle such device in their DLS boxes, and provide it with no additional cost (just like my ISP also integrates a firmware support in their "box" router to create an open Wifi hotspot accessible to every subscribers of FON in a perimeter of about 50 meters; at home I can detect about a dozen of those open Wifi nano-hotspots from various ISPs: although they are open, using it first requires logging with the ISP or with FON, in on a standard webpage relayed by the hotpsot which first appers before reaching any other website, or using a credit card to pay for one hour or one day; this hotspot is fully tunneled, secured, and has no access to the private LAN of the DSL/cable/fiber subscriber). There's probably similar services in other countries than France (notably with FON: my ISP subscription includes free access to all FON hotspots worldwide).

I think one thing that a lot of people are over looking is the fact the NAT meant loss of performance. Every packet exiting a NATted network must be translated on its way out, and returning packets must be translated on their way back in. 

This is going to need a lot of hardware and cpu/ram time, and lets not forget that some protocols cannot be NATted at all.

These protocols that can't be Nated include for example; IPSec’s AH sub-protocol.

Also NAT obscures matters when troubleshooting, because the  addresses are  routinely reused by NAT.

There are going to be more things to worry about! i agree that there are not enough IPv4 address, but you don't hear many people discussing the issue of protocols that can't be Nated, and the ultimate cost it is going to incur, to do all of the Nating??

We are all to blame, well most of us, this entire issue should have been dealt with back in the mid 90's when we had already started to run out of addresses, and then we all jumped on the Nat bandwagon.

I will tell you something, i think there is a lot of money to made in the cross over to IPv6, just as there was with Y2K..

It's true that NAT s*cks !

Not just because this means that a few microseconds wil be added in translating the addresses, but because it requires complex changes in protocols.

For this reasn, most protocols of the internet are now tunneled via HTTP, because HTTP can maintain sessions and offer security and transparent proxying. But here the cost in terms of protocols are much worse than NAT. The tunnel is inefficient, but at least it works though wide ranges of devices, thanks to the fact that HTTP does not need to bind the client and the server addresses directly.

HTTP passes very well through NAT, but it is definitely not good for interactive and very dynamic data: the TCP window is a problem (most implementations of HTTP are over TCP, implementations of HTTP over UDP are rare and do not work through NAT without having to use *also* UPnP, and UPnP port mappings are very unstable and require verbose pinging od the network to maintain it live).

But even with HTTPS for using secure channels, it is impossible to resume a session that would be broken. On the opposite IPSEC can maintain a relationship for long and is not restricted to TCP.

But the most important problem with NAT is the rapid exhaustion of port numbers on the shared Internet side, if there are many proxied hosts on the private side of the NAT. With the rapid explosion of connected deviced even at home, it will soon not be rare to have hundreds of devices in our LANs that need to have some connectivity with the Internet. The NAT router will not be able to route them all via NAT, or will have to sacrifice the session lengths (as can be seen in Europe on mobile Internet networks that are extremely unreliable to keep sessions for more than a few minutes).

NAT is effectively unworkable on mobile networks. With the 4G/LTE coming, users will want to have routers in their home using it and double NAT (on the mobile access etwork and on the hme router) will fail (or the performance will be dramatically slow).

We do need IPv6 now because of 4G/LTE and because of connected appliances everywhere. And we don't want IPv6 relyed over an IPv4 tunnel (like it is currently deployed by European ISPs: this is extremey slow, and such tunnels require a proxying server hosted by the ISP itself, and we all know that these servers can't cope wit hthe traffic and don't scale.

We want IPv6 directly in the routing layer, not via a presentation protocol such as proxied tunnels. 6to5 and Teredo are just transition mechanisms not designed to be used for long, and certainly not for use by modern demanding applications such as HDTV, VOD, and VOIP, which have strong requirements in terms of performance (not just in terms of average bandwidh, but also in realtime adaptation of the trafic and good response time).

Suppose you have an media broadcast: the broadcaster cannort support many connections from clients. They want a single point of inlection to broadcast most of thee trafic needed, even if there's a separate low-volume channel for the nteraction (such as querying back the missing data and returning this data over this secondary channel to clients.

But note that this secondary channel should often have higher QoS priority to ver delivered to the client. But what will happen on the client side if all its channels are routed via the same NAT router ? IT will be impossible to manage QoS correctly. Note that broadcast (or subscribed multicasts) do not work over HTTP or any other protocol based on TCP, they need UDP.

"We do need IPv6 now because of 4G/LTE and because of connected appliances everywhere."

One other aspect of 4G that demands IPv6 is Voice over IP.  With 4G, voice calls are supposed to be carried via VoIP.  With VoIP, you're supposed to have end to end IP connectivity between phones.  There are nowhere near enough public IPv4 addresses for this to happen.  If the carriers don't provide IPv6, then they'll have to provided gateways to convert NAT to some shared address and go from there.

RSS

Training

IoT & IPv6 Networking Conference

Product Information

Fill out my online form.

© 2014   Created by gogo6.

Badges  |  Report an Issue  |  Terms of Service