Another LTE network turns up as IPv4-only squat space + NAT

FYI http://www.dslreports.com/forum/r27324698-LTE-access-early-

So much for next generation technology ...

CB

No IPv6, and using duplicate IPv4 space. #sigh #fail

/TJ

Short-sighted and foolish. Shame on you, Sprint.

jms

So some "comments" on the intertubes claim that DoD ok'd use of it's
unadvertized space on private networks. Is there any official reference
that may support this statement that anyone of you have seen out there?

--Andrey

Even if they did OK it (which i doubt), actually using it - especially in a
public/customer facing / visible deployment - is a Bad Idea.
*Traceability fail and possibly creating unreachable networks out there ...*

/TJ

I am on sprint and my ip is always in the 20. net even though my wan up is
totally different.

Grant

I disagree. I see it as an extra layer of security. If DOD had a network
with address space 'X', obviously it's not advertised to the outside. It
never interacts with public network. Having it duplicated on the outside
world adds an extra layer of complexity to a hacker trying to access it.
It's not a be-all/end-all, but it's a plus. A hacker who's partially in the
network may try to access network 'X', but it routes to the outside world,
tripping IDSs...

Chuck

I disagree. I see it as an extra layer of security. If DOD had a network
with address space 'X', obviously it's not advertised to the outside. It
never interacts with public network. Having it duplicated on the outside
world adds an extra layer of complexity to a hacker trying to access it.
It's not a be-all/end-all, but it's a plus. A hacker who's partially in the
network may try to access network 'X', but it routes to the outside world,
tripping IDSs...

Then DoD should go for using something like the v6 documentation prefix
or similar. It both is in many peoples filters and (as referenced here
recently) is being used for stuff that "never" (promise! or at least not
until we change our minds) is going to need connectivity.

I do not see DoD handing back its allocations in the name of promoting
unreachability by swapping it for reusable space.. It probably values
the uniqueness property of allocated space too much. And rightly so.

No, reusing somebody's prefix is A Very Bad Idea. I'm having a very hard
time believing the alleged "ok" is anything but cheap talk.

So some "comments" on the intertubes claim that DoD ok'd use of it's
unadvertized space on private networks. Is there any official reference
that may support this statement that anyone of you have seen out there?

The arpanet prefix(10/8) was returned to IANA circa 1990 it's now RFC 1918. everything else is urban myth.

Concur 100%. There is no security value to doing this whatsoever - quite the opposite, given the possible negative consequences to reachability and, thus, availability.

It is not about security. It is about finding enough bits to service 7 digits number of subs.

yi

It is not about security. It is about finding enough bits to service 7 digits number of subs.

IPv6 takes care of that problem quite effectively :slight_smile:

If there is a major amount of gear in the network that will not support IPv6 (apply bat to vendor as appropriate), then I can understand going down the road of IPv4 + CGN, but I would consider that to be an absolute last resort. Not much upside, lots of downside.

jms

* Cameron Byrne

FYI LTE access early? - Sprint | DSLReports Forums

So much for next generation technology ...

Yesterday, Telenor launched LTE.

So. With a green-field deployment, in their home market (supposed to be
the first of their tree-digit million subscribers world-wide to get all
the cool new tech), built on 3GPP specs that fully supports IPv6,
already proven to work by other pioneers (^5 VzW), for which there
are plenty of compatible devices (again, ^5 VzW), and plenty of
compatible content (^5 ISOC, et al.), four months after World IPv6
Launch (in which they participated), and one month after their RIR ran
out of IPv4 addresses...launching without IPv6 support was a perfectly
natural and sensible thing for them to do, it seems.

*sigh*

The problem I have seen is not to get IPv6/dual stack in LTE (this worked from day one), it's to get dual stack working in all the cases with bearer establishment and handover between 2G/3G and 4G.

2G/3G is "fully integrated" with each other, but LTE is still kind of separate, vendors are just now getting around to producing mobile core nodes that support all of them with a single node for each function.

Would you want to get IPv6 when you're in the LTE network but lose it when you were handed over to 2G/3G. My guess is not, so I believe providers will wait until that is really done.

https://intelligence.businessinsider.com/facebook-is-adding-over-25000-mobile-users-an-hour-2012-10

dream big....

/bill

* Mikael Abrahamsson

Would you want to get IPv6 when you're in the LTE network but lose it
when you were handed over to 2G/3G.

Absolutely.

That some features are available only on the most advanced access
technology is perfectly reasonable and to be expected, IMHO. If not,
what's the point of upgrading at all?

I lose my YouTube streams when I get handed over from 3G to 2G, too, for
example. I can live with that. I much prefer it to YouTube not working
3G as well, even though that might very well be considered a more
"consistent" user experience.

That some features are available only on the most advanced access technology is perfectly reasonable and to be expected, IMHO. If not, what's the point of upgrading at all?

Uh, whut? I expect my ssh sessions to survive a 4G->3G handover, and if they happen to go over IPv6, I want them to survive.

The important reason to upgrade is to get higher speeds, not to get access to new L3 tech.

I lose my YouTube streams when I get handed over from 3G to 2G, too, for example. I can live with that. I much prefer it to YouTube not working 3G as well, even though that might very well be considered a more "consistent" user experience.

I don't agree with you at all. I don't believe I would lose the stream when doing that handoff in our network, it might buffer some more (because EDGE is slower than HSDPA), but you wouldn't lose the stream.

Consistent behaviour (apart from speed) on all networks is really important for me, and I'd imagine it is for most users as well.

That some features are available only on the most advanced access technology is perfectly reasonable and to be expected, IMHO. If not, what's the point of upgrading at all?

Uh, whut? I expect my ssh sessions to survive a 4G->3G handover, and if they happen to go over IPv6, I want them to survive.

If your SSH sessions could survive a change in address assignment (which often happens in a handover), they could survive a change in address family assignment as well.

Unfortunately, TCP - upon which ssh is built - uses the routing identifiers as the host identifiers, and so this doesn't work.

The important reason to upgrade is to get higher speeds, not to get access to new L3 tech.

I lose my YouTube streams when I get handed over from 3G to 2G, too, for example. I can live with that. I much prefer it to YouTube not working 3G as well, even though that might very well be considered a more "consistent" user experience.

I don't agree with you at all. I don't believe I would lose the stream when doing that handoff in our network, it might buffer some more (because EDGE is slower than HSDPA), but you wouldn't lose the stream.

But the stream would almost certainly be coming to a newly assigned IP address (and once you're doing that, who cares if the family changes too?)

Consistent behaviour (apart from speed) on all networks is really important for me, and I'd imagine it is for most users as well.

The *only* inconsistency would be when you're accessing the IPv6-only part of the Internet, of which there's currently none that consumers care about.

Matthew Kaufman

If your SSH sessions could survive a change in address assignment (which often happens in a handover), they could survive a change in address family assignment as well.

Why would there be an address change in a handover? That is definitely not expected behaviour.

But the stream would almost certainly be coming to a newly assigned IP address?

Why do you believe that address changes in handover? It's an integral part of 3GPP standard that your existing bearer is used for handover, so your address shouldn't change. If it changes then it means the handover didn't work as designed, probably due to some radio related problem. If the address changed, then it means the bearer was torn down and a new bearer was initiated. This is definitely not expected behaviour. We have plenty of customers with bearers that are up for tens of days in a row.

The *only* inconsistency would be when you're accessing the IPv6-only part of the Internet, of which there's currently none that consumers care about.

If a user is accessing a stream from an IPv6 enabled CDN that stream shouldn't be reset just because a handover happened.