Hoi, ik ben Iljitsch van Beijnum. Op deze pagina staan alle posts over alle onderwerpen.
If you want to use the BGP routing protocol, you need an Autonomous System number. These AS numbers were 16 bits in size until now, allowing for around 64000 ASes, and more than half of those have been given out already. To avoid problems when we run out of AS numbers, the IETF came up with modifications to BGP to allow for 32-bit AS numbers, as I explained in a posting about a year ago.
Obviously, at some point someone has to bite the bullet and start using one of these new AS numbers. This bullet biting may happen fairly soon, as the five Regional Internet Registries have all adopted, or are in the process of adopting, the following policy:
So what does this mean for people who run BGP today? Not all that much, really, because the changes to BGP to support the longer AS numbers are completely backward compatible. The only change is that you'll see the AS number 23456 appear in more and more places. In routers that don't yet support 32-bit ASes, the special 16-bit AS number 23456 shows up as a placeholder in places where a 32-bit AS is supposed to appear.
If you have scripts that perform AS-related operations on the Routing Registries (such as the RIPE database), you'll have to adjust your software to parse the new format for 32-bit AS numbers. They are written down as <16bits>.<16bits>, for instance, 3.1099 is a new 32-bit AS number and 0.23456 is the 32-bit version of AS 23456. However, this format isn't standardized so 32-bit AS numbers may show up differently in your router. Have a look at the RIPE announcement.
As soon as the first 32-bit AS number appears in the wild I'll report it here so you can check whether it shows up in its full 32-bit glory or as 23456. In the mean time, you may want to ask your router vendor for 32-bit AS support. At least one of the big vendors isn't implementing it in all of their lines just yet because they claim there is no customer demand for it.
Permalink - posted 2006-12-29
The other day, I was sitting in a hotel lobby waiting for some people, working on my laptop. There I had the following conversation:
“Hey, is there a wireless network here?”
“No.”
“Then how are you working?”
“I’m working offline.”
<gasp>
In this age of AJAX, webmail, instant messaging and YouTube videos working offline seems so 1980s. I guess this means I’m getting old, because I’m much more comfortable having my stuff (or at least, copies of my stuff) on local storage, so I have access to it regardless of my connectivity, and there is at least a fighting chance that an application that works today still works tomorrow.
Interestingly, Microsoft, a company that makes billions selling software that makes computers useful whether or not they’re connected (Office), has jumped on the web-based applications bandwagon. Apparently they don’t see that web-based applications make Microsoft obsolete: all you need to run them is Linux and Firefox.
Apple on the other hand, seems to focus on applications that work best locally. Long after the majority of Office users have switched to free or cheap web-based alternatives, possibly discarding Windows in the process, creative professionals (and hobbyists) will still be buying Apple hard- and software to do their audio, video and image editing.
(Originally published on the Apress blog, which is now gone.)
posted 2006-11-06
Image link - posted 2006-10-29 in
The BGP TCP MD5 password mechanism (RFC 2385) is very useful to protect BGP sessions from attempts at unpleasantness by third parties. However, it is rather simplistic. One of the flaws is that there are no provisions for changing the password. In the old days, setting a new password for a neighbor would cause Cisco routers to tear down and reestablish the BGP session. Today, the session survives if the password or key is changed at more or less the same time at both ends. This requires a good deal of coordination. I must say that I can't remember anyone asking me to change an existing BGP password. But the security people insist that it's important to do this regularly, for instance, when employees leave. I think they have a different appreciation of the sensitivity of this key than those of us working in operations.
Anyway, Steve Bellovin, a well-known member of the IETF, has written this "internet draft" and submitted it for publication as an RFC:
http://www.ietf.org/internet-drafts/draft-bellovin-keyroll2385-03.txt (will be deleted after 6 months)
What he proposes is that a router can have more than one active key so it's possible for one end to change keys and the other end to go along with this without the need to coordinate the password change very closely. Unfortunately, it's still possible to configure the wrong key, or forget to change the key after agreeing to do so, and then the BGP session will go down at some point, probably conveniently in the middle of the night. See my posting to the IETF discussion list for details.
Well, progress isn't always progress, I guess. If you have any opinions on the matter, email me.
Permalink - posted 2006-09-30
Iljitsch van Beijnum
The Internet Protocol Journal, Vol. 9, no. 3, pp. 16-29, September
Last week, ARIN, the organization in charge of distributing IP addresses in North America, changed its IPv6 address policy so it's now possible to get Provider Independent (PI) IPv6 address space.
According to the ARIN Number Resource Policy Manual:
This is both good news, and bad news. The good news is that if (in the ARIN region) you are currently connected to two or more ISPs for IPv4, you can now do this in much the same way with IPv6. Since IPv6 routing is almost identical to IPv4 routing, all of this should be fairly easy.
However, since both the routing protocols (including BGP) and the rules for getting address space are now mostly the same, this means that in the future, IPv6 routing will suffer from the same problems that have been plaguing IPv4 inter-domain routing: a "global routing table" that is much larger than necessary, requiring network operators to invest in bigger routers and causing unnecessary instability. It also means that multihoming (the practice of connecting to two or more ISPs) will never be possible for truly large numbers of internet users.
The Internet Engineering Task Force has been working on alternative ways to gain multihoming benefits in the multi6 and shim6 working groups. But the ARIN constituents decided not to wait for the completion of this work, which will likely have the effect that the shim6 mechanisms won't be adopted widely or quickly when they become available. One reason cited for moving ahead with a known problematic solution for multihoming was the statement by some organizations that they wouldn't adopt IPv6 in the absence of a multihoming solution. Prediction: they won't implement IPv6 with multihoming anytime soon either.
And unfortunately ARIN (and the other RIRs) still claim that you can filter out any IPv6 prefixes longer than /32 even though they give out micro allocations and now PI blocks that are longer than that, mostly /48. See my article from nearly three years ago.
Permalink - posted 2006-09-05