& cplSiteName &

European IPv6 Plan Comes Under Fire

Light Reading
News Analysis
Light Reading
3/7/2002
50%
50%

A bit of a tiff has broken out in Europe over whether there’s any urgency to upgrade telecom infrastructure so that it supports Internet Protocol (IP) version 6, an improved version of IPv4, the current protocol used across the vast majority of the Internet.

The row centers over a "Communication" from the European Commission (EC) a couple of weeks ago (Feb 21), which urges early adoption of IPv6. It warns that IPv4 addresses will be in increasingly short supply by 2005 and says governments and industry need to head off this problem now by encouraging the adoption of IPv6, which can support vastly more addresses.

Getting on with IPv6 deployment now will avoid "rushed and therefore risky and more expensive implementations later," the EC paper says. A "concerted effort" to adopt IPv6 is called for, on the grounds that it will strengthen the competitiveness of not just European fixed and mobile service providers but also a "wide range" of other industries producing goods with embedded Internet access, such as automobiles and consumer electronics.

Pretty much everybody agrees that IPv6 will be needed one day, but there's disagreement over when that day will be. The protocol has been in existence for several years and has often been touted as the solution to an impending IP address crisis -- a crisis that so far has failed to happen.

Questions have been raised over whether it really makes sense for service providers to invest in IPv6 technology now, when they're so short of cash and when there are plenty of other things they need to fix -- including their billing systems -- to prepare for next-generation Internet services.

This discussion heated up yesterday when Paul Francis, chief scientist at Tahoe Networks, a startup developing "mobile Internet edge" infrastructure solutions, claimed that the EC report was "misleading."

Francis agrees with the general conclusion of the report -- that operators will eventually have to move to IPv6. However, where the EC suggests that carriers should migrate to IPv6 as soon as they can, Francis believes IPv4 combined with the Network Address Translation (NAT) standard should be able to cater to operators’ needs for years to come.

Francis invented NAT, which is now an Internet standard. It provides a way for many users on a LAN to share a single IPv4 address, thereby reducing overall address requirements. Francis believes that client-server applications like Web browsing, email, WAP (wireless access protocol), and streaming media do not require IPv6. These applications have worked for years through NAT, he contends, and can safely continue to do so for the time being.

Francis disputes, as well, an assertion in the EC paper that NAT cannot be used for peer-to-peer, "always-on" devices and applications. He acknowledges that IPv6 will do a better job of handling such applications but says the combination of IPv4 and NAT will still do the job adequately while carriers get their acts together on more pressing matters.

The precise wording of the EC paper is as follows: “While a user behind a NAT device can communicate out to servers on the Internet… the same user cannot be guaranteed to be accessible when external devices wish to establish a connection (as typified by the ‘peer-to-peer’ communication model)."

“What does ‘cannot be guaranteed’ mean?,” asks Francis. “A mobile wireless user today cannot be guaranteed to get wireless access at all times -- but usually they can, and this is good enough to make the technology useful and successful.”

According to Francis, using the TCP (transmission control protocol) and UDP (user datagram protocol) port numbers to make clients visible behind NAT boxes effectively increases the size of the IP address from 32 to 48 bits. This is enough, he asserts, to give each human on the planet 250 or more permanent, unique address/port combinations. Assuming the truth of that assertion implies that client-server, push, and to some extent peer-to-peer applications can be made to work through NAT.

All of this talk, however, as someone nearly said, may be akin to two bald men fighting over a comb. Both the EC report and Francis are correct. Carriers understand the need to move to IPv6, but they are unlikely to have vast amounts of ready cash to spend on making that transition at the moment.

“To be honest, I don’t think anyone’s got a lot of money to spend on upgrades… People are trying to squeeze as much as possible out of what they already have installed or in the ground,” says Richard Webb, European market analyst at Infonetics Research Inc. “A wholesale migration to IPv6 may be a nice endgame, but its going to be a piecemeal process.”

What's really driving European carriers to adopt IPv6 is that the use of the protocol is mandated in release 5 of the UMTS (universal mobile telecommunications system) standard from the 3rd Generation Partnership Project (3GPP), a consortium of standards bodies trying to establish worlwide specs for mobile networks.

In addition, Nokia Corp. (NYSE: NOK) has said that it wants to have all IP mobile phone network kit using IPv6 available by 2004, although actual rollouts could take years after that. Companies as diverse as Cisco Systems Inc. (Nasdaq: CSCO), Microsoft Corp. (Nasdaq: MSFT), and Symbian Ltd. are all supporting IPv6.

In fact, Webb reckons the EC is actually playing catchup with the industry, producing a report that echoes what some tech soothsayers have been insisting on for years. The EC report is unlikely to convince carriers that they should move to the new protocol, because they knew they had to do that anyway. It is just another signpost along the long road to Ipv6.

— Dan Jones, Senior Editor, Unstrung
http://www.unstrung.com

(27)  | 
Comment  | 
Print  | 
Newest First  |  Oldest First  |  Threaded View        ADD A COMMENT
Page 1 / 3   >   >>
WizzKid
50%
50%
WizzKid,
User Rank: Light Beer
12/4/2012 | 11:49:54 PM
re: European IPv6 Plan Comes Under Fire
Oh well, IPv5 was exactly IPv4 with just 3 changes added in for an extremely easy migration to a bigger address space with absolutely no other modifications to the base IPv4 protocol.

1. The 4-bit Version field became 5 (from 4)
2. Both Src and Dst Address fields became 64 bit (from 32 bit)
3. All other header fields along with their semantics remained the same, for easy adoption of IPv5 across all routing software on the Internet.

Simple and easy, but then people got excited about larger address-space (why not go straight to 128 bit in 1 shot, instead of in 2 stages). Some felt now that we are modifying the IP header, why not fix all IPv4 problems in 1 shot (again, instead of doing it in 2 stages). To do that, they had to move the version number also from 5 to 6, which obviously makes sense.

So everything is fine with IPv6 except that if the internet had transitioned to IPv5 first, there would not have been this level of urgency to move onto IPv6 (or live with the crappy work-arounds like NAT).

Anyway, sometimes people like to jump steps, and that has lead to such slow adoption of IPv6, because it is no longer an incremental or evolutionary sequence of 2 steps, but rather a revolutionary 1 step.

Folks, now that it has happened let's live with it, since we would have eventually evolved to the same situation anyway (only over a longer period of time).

WizzKid.



prcenter
50%
50%
prcenter,
User Rank: Light Beer
12/4/2012 | 11:48:02 PM
re: European IPv6 Plan Comes Under Fire
One thing that concerns me about IPv6 is the absence of a checksum or any other en route error detection and/or correction.

Could this result in extraneous traffic as routers forward useless packets all the way to the end systems to be discarded by TCP (on the receiving host(s)) rather than being discarded en route.

For example if there were a glitch or malfunction of CRC at the link level. (Network interfaces sometimes go haywire causing 'broadcast storms' etc. shutting down entire networks). IPv6 would have no means of detecting or cross checking the error(s) which might then be propogated throughout the internet.

I'm sure better (and better informed and/or more experienced) minds are convinced that this could never happen or would not be a problem if it did. so someone convince me.
Tony Li
50%
50%
Tony Li,
User Rank: Light Beer
12/4/2012 | 11:48:01 PM
re: European IPv6 Plan Comes Under Fire

PR,

Let's first be clear that we're only talking about the header checksum. The TCP checksum that covers actual user data is the same in both IPv4 and IPv6. Let's not get into the robustness (or lack thereof) of the TCP checksum.

Errors in the IP header can and do happen. With IPv6, they imply that the packet will be delivered to the wrong destination. If the error is not momentary, the assumption is that traceroute will show the problem.

Net: I don't think the lack of a header checksum is that bad from a user perspective.

Tony
Mark Seery
50%
50%
Mark Seery,
User Rank: Light Beer
12/4/2012 | 11:48:00 PM
re: European IPv6 Plan Comes Under Fire
Tony,

Maybe I misread what u said. but it would seem to be a staple of the CO vs CNLS debates that packets being misdelivered is a security issue. So without opening up the debate about the various ways this might happen in each model, not sure that all would agree that misrouted packets is not something to be worried about.

Mark
Tony Li
50%
50%
Tony Li,
User Rank: Light Beer
12/4/2012 | 11:48:00 PM
re: European IPv6 Plan Comes Under Fire

Mark,

I think you read something between the lines that wasn't there. If someone wants security on the Internet, then they MUST encrypt the packet. There have been numerous security breaches over the years where routers and LANs have been compromised. We have to assume that the black hats get to read every packet.

Given this threat, I don't see misdelivery as even a minor issue. Either it's encrypted and you don't care, or it's not encrypted and you didn't care.

Yes, this flies in the face of what many folks have touted for years about VPNs, but it is the reality of the situation.

Tony
prcenter
50%
50%
prcenter,
User Rank: Light Beer
12/4/2012 | 11:47:58 PM
re: European IPv6 Plan Comes Under Fire
"If the error is not momentary, the assumption is that traceroute will show the problem."

Hmmm...

Currently, I believe, traceroute uses ICMP and ICMP error messages are carried inside IP packets as well (along with ping ICMP messages, some congestion control messages, telnet, FTP and HTTP error messages. ICMP is used by hosts, routers, gateways etc. to communicate various network control and error information to each other using IP.

In other words IP transports data that will never be turned over to TCP for error detection.

The headder checksum may not be much but I believe that in some single bit ICMP messages the IP header itself would constitute the bulk of the data being transported.

At any rate it seems like a lot of critical control and error detection information (including traceroute) currently depends, to some degree, on the IP header checksum for its own error control. Removing that, not entirely redundant layer of error detection seems just a bit risky.
prcenter
50%
50%
prcenter,
User Rank: Light Beer
12/4/2012 | 11:47:56 PM
re: European IPv6 Plan Comes Under Fire
To reply to my own question, and reveal my ignorance in regard to these issues... The IPv6 version of ICMP does include its own checksum as noted for example:

"this is a change from the IPv4 version of
ICMP... The
reason for the change is to protect ICMP from misdelivery or
corruption of those fields of the IPv6 header on which it depends,
which, unlike IPv4, are not covered by an internet-layer checksum."

http://www.sikurezza.org/devel...

my apologies for bringing up an issue that has already been addressed.
Mark Seery
50%
50%
Mark Seery,
User Rank: Light Beer
12/4/2012 | 11:47:42 PM
re: European IPv6 Plan Comes Under Fire
Hi Tony,

>> If someone wants security on the Internet, then they MUST encrypt the packet. There have been numerous security breaches over the years where routers and LANs have been compromised. We have to assume that the black hats get to read every packet.

Given this threat, I don't see misdelivery as even a minor issue. Either it's encrypted and you don't care, or it's not encrypted and you didn't care.

Yes, this flies in the face of what many folks have touted for years about VPNs, but it is the reality of the situation.<<

I essentially agree with you, especially as related to public CNLS networks, with two caveats: 1) Perception is also reality, and 2) ultimately no network-based security mechanism (that I am aware of) has proven to be unhackable, so in the end we are talking about levels of security, or perceptions of security. IPSEC etc. provides one level/perception of security, and so to do dedicated circuits.

In the context of any-to-any, rapid changing destinations, among a broad spectrum of public subscribers, your comments seem the most true.

Mark
Tony Li
50%
50%
Tony Li,
User Rank: Light Beer
12/4/2012 | 11:47:40 PM
re: European IPv6 Plan Comes Under Fire

Mark,

Do you seriously see CO style packets traversing the exact same infrastructure as having any significantly different properties? The entire network can be and has been hacked. CO packets can certainly be sniffed. What was even slightly different here?

It's true that the CO packets are less at the whims of the routing protocols and thus are less susceptible to attacks via the protocols, but frankly the protocols are NOT where systems are being penetrated.

I grant you that perception does seem to color people's reality, but over time, the ugly face of reality is eventually accepted. Those that accept it first are frequently those who profit the most. Or are hurt the least.

Regards,
Tony
Mark Seery
50%
50%
Mark Seery,
User Rank: Light Beer
12/4/2012 | 11:47:15 PM
re: European IPv6 Plan Comes Under Fire
prcenter,

>> One thing that concerns me about IPv6 is the absence of a checksum or any other en route error detection and/or correction. <<

So I have asked some brighter minds than mine about this issue, and one of the interesting response goes kind of as follows:

1) An IP network of this nature should, and probaly is running over a transmission layer that is catching basic transmission corruption

2) If errors are still occuring, the chances of corruption causing repeated misrouting to the same destination are small

3) This is different than a CO network where a configuration error can cause repeated misrouting.

Hope this helps,
Mark
Page 1 / 3   >   >>
Featured Video
Flash Poll
Upcoming Live Events
March 12-14, 2019, Denver, Colorado
April 2, 2019, New York, New York
April 8, 2019, Las Vegas, Nevada
May 6, 2019, Denver, Colorado
May 6-8, 2019, Denver, Colorado
May 21, 2019, Nice, France
September 17-19, 2019, Dallas, Texas
October 1, 2019, New Orleans, Louisiana
October 10, 2019, New York, New York
November 5, 2019, London, England
December 3, 2019, New York, New York
December 5-3, 2019, Viena, Austria
All Upcoming Live Events