Internet Protocol Forum

To what extent is the IPv6 Internet polluted by “background radiation”?

(more…)

After many years, the root of the DNS is evidently going to be signed in the coming weeks using DNSSEC with a verifiable root key, or at least that’s the plan if the National Telecommunications and Information Administration of the United States Federal Department of Commerce follow through with their proposed actions that have been foreshadowed in the Federal Register of the United States bureaucracy of Wednesday, 9 June 2010. It will all happen by July 15 2010, if all happens in accordance with the plans outlined in that notice, and on that date we should have a DNSSEC-signed root of the DNS. Given that this is an event that has taken more than fifteen years to come to fruition, I thought it might to useful to have another look at DNSSEC to mark this long anticipated milestone.

(more…)

It seems that the imminent prospect of IPv4 address exhaustion has managed to generate a renewed interest in IPv6. A number of the conversations I have had lately have been about setting up dual stack servers, and there is a widespread concern that if you convert a server from single stack IPv4 to dual stack then some clients will have problems in accessing your site. The same concern has been voiced with converting a mail server from single stack to dual stack.

Here are two very simple hints may be of assistance to you:

(more…)

Further studies on the amount of end-to-end IPv6 capability in today’s Internet reveals that the extent of full end-to-end IPv6 capability in today’s Internet is now at a level of 5% of all end systems, at least within the scope of the systems studied here. This number is now at a level where the level of IPv6 deployment is now passing from mere statistical interest to mainstream commercial importance. (more…)

Background

The address plan for IPv4 has a reservation for “Private Use” address space. This reservation, comprising three distinct address blocks, namely 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16, is intended for use in private contexts where networked devices do not have any requirement to be visible to the public Internet. However, it has long been recognised that other addresses have also been used in private contexts. Some of these uses are entirely informal and remain entirely within a particular private network, while other uses have been a little more systematic. One recent study of this form of address use noted that the address block of network 1, or 1.0.0.0/8, was “widely used as private address space in large organizations whose needs exceed those provided for by RFC 1918″ [1]. (more…)

It is considered good security practice to treat cryptographic keys with a healthy level of respect. The conventional wisdom appears to be that the more material you sign with a given private key the more clues you are leaving behind that could enable some form of effective key guessing. As RFC4641 states: “the longer a key is in use, the greater the probability that it will have been compromised through carelessness, accident, espionage, or cryptanalysis.” Even though the risk is considered slight if you have chosen to use a decent key length, RFC 4641 recommends, as good operational practice, that you should “roll” your key at regular intervals. Evidently it’s a popular view that fresh keys are better keys! (more…)

Here in my part of the world the season has well and truly turned from summer to autumn, which means that another year has come and gone. I thought that it might be time to give MTU examination a rest for a month or more and instead review the last 12 months in BGP-land and see what’s been happening there. (more…)

“Conventional beliefs” always intrigue me, in that while sometimes these beliefs do express basic constraints and truths, at other times they are misleading and just plain wrong. So the question I’d like to look at in this article is: Is a small MTU setting “crippling” to a network and its clients? What is the relationship between internet performance and the maximum packet size, as set by the MTU setting? More particularly, how bad is an MTU setting of 1280, as compared to an MTU setting of 1500? What performance differential can one expect and why? (more…)

I have seen a number of commentaries and presentations in recent times that claim that IPv6 is identical to IPv4 in every respect except one: namely more addresses. Of course that’s not just “more” addresses in the sense that 128 addresses are “more” than 32 addresses, but that’s 2 to the power 96 times “more” addresses. Here we’re talking massively, unimaginably massively, “more” addresses in IPv6! I must admit to some sympathy for such a claim given that I find the assertions that IPv6 provides superior QoS capability, better, security, improved mobility support or better anything else, as compared to IPv4, to be an expression of largely wishful thinking. There have been some minor tweaks in IPv6 in this respect, but nothing very major. (more…)

This is a collection of papers and articles that are not well suited to publish in a print format, but are considered to be of interest to readers of the Internet Protocol Journal.

The Internet Protocol Forum is not intended to promote any specific products or services, but rather is intended to serve as an informational and educational resource for engineering professionals involved in the design, development, and operation of public and private internets and intranets. It provides readers with technology and standardization updates for all levels of the protocol stack and serves as a forum for discussion of all aspects of internetworking.

Topics include, but are not limited to:

• Access and infrastructure technologies such as: ISDN, Gigabit Ethernet, SONET, ATM, xDSL, cable, fiber optics, satellite, wireless, and dial systems
• Transport and interconnection functions such as: switching, routing, tunneling, protocol transition, multicast, and performance
• Network management, administration, and security issues, including: authentication, privacy, encryption, monitoring, firewalls, trouble-shooting, and mapping
• Value-added systems and services such as: Virtual Private Networks, resource location, caching, client/server systems, distributed systems, network computing, and Quality of Service
• Application and end-user issues such as: e-mail, Web authoring, server technologies and systems, electronic commerce, and application management
• Legal, policy, and regulatory topics such as: copyright, content control, content liability, settlement charges, “modem tax,” and trademark disputes in the context of internetworking

Please send any contributions to the Forum’s editorial team, Geoff Huston gih@potaroo.net and Ole Jacobsen ole@cisco.com.