November 2013 archive
If you can’t get a native IPv6 connection for your network from your local Internet Service Provider (ISP), what kind of “tunneling” mechanism can you use to get IPv6 connectivity for your network? Today a new Informational (non-standard) RFC 7059, A Comparison of IPv6-over-IPv4 Tunnel Mechanisms, was published that explores exactly these issues. It walks through a wide range of available IPv6 tunneling mechanisms and explains the merits (or not) of the various mechanisms, while also providing plenty of links for people to learn more. The list of tunneling mechanisms includes:
- Configured Tunnels (Manual Tunnels / 6in4)
- Automatic Tunneling
- IPv6 over IPv4 without Explicit Tunnels (6over4)
- Generic Routing Encapsulation (GRE)
- Connection of IPv6 Domains via IPv4 Clouds (6to4)
- Anything In Anything (AYIYA)
- Intra-Site Automatic Tunnel Addressing (ISATAP)
- Tunneling IPv6 over UDP through NATs (Teredo)
- IPv6 Rapid Deployment (6rd)
- Native IPv6 behind NAT44 CPEs (6a44)
- Locator/ID Separation Protocol (LISP)
- Subnetwork Encapsulation and Adaptation Layer (SEAL)
- Peer-to-Peer IPv6 on Any Internetwork (6bed4)
If you are frustrated with being unable to obtain native IPv6 connectivity for your network, this RFC may provide a good place to start to learn more about how you can use one of these transition mechanisms to connect your network to the rest of the IPv6-enabled Internet!
Operate an Internet Router? Join our “Router Resilience Survey” To Help Make The Internet More Secure
Do you operate a router connecting your network to the rest of the Internet? Would you like to help us understanding how resilient and secure the Internet’s routing infrastructure is? If so, please visit our new “Routing Resiliency Survey” at:
and read more about the new project at:
The cool thing is that as a participant in the project you’ll receive a basic level of performance monitoring from BGPmon who is partnering with the Internet Society on this survey. You’ll also receive the report when the 6-month survey is complete and you’ll help gain insight into questions such as:
- What happens with the prefixes your routers announce elsewhere in the global Internet?
- How will your network be impacted by routing misconfigurations?
- How safe and resilient is the overall global routing infrastructure?
Participating in this survey will greatly help us – and the rest of the Internet community – understand better exactly what kind of threats and attacks are being seen out within the Internet’s routing infrastructure. As you can read on the RRS page, the time commitment should be minimal and all data will be anonymized – plus, as mentioned above, you’ll get to see reports related to your own routers.
Please do check it out and help us if you can! (Thanks!)
Have you watched curling on TV during the Olympics and thought it looked fun? Would you like to try it out? Would you like to see the sport of curling available in the Keene / Monadnock region?
If so, here are three quick ways you can help us bring curling to Keene and the greater Monadnock region. Our greatest need at the moment is to build a community of people interested in the sport of curling and be able to show that support to others in the region:
1. Connect with us on social media – Help us show that people are interested in curling in the region by:
- Following @MonadnockCurl on Twitter
- Like our MonadnockCurling Facebook Page
- Add our Google+ Page to a circle AND give it a “+1″
2. SPREAD THE WORD! Please share those pages and accounts to your own social circles – and please share/retweet/+1 any updates we post. Tell people about the website. Mention “monadnockcurling.org” to friends. Write up an article for the newspaper or some other printed publication. Post a notice on a community bulletin board… help us let people know!
3. Please fill out our form to let us know your interest and experience (and you don’t need ANY experience – just a desire to see curling available in the Keene area).
Together we can bring the sport of curling to the Monadnock region! We need YOUR help to spread the word! Thank you!
CONGRATULATIONS to the team at Keene Ice for the unanimous vote of the Keene City Council to proceed with executing the development and operations agreements between the City of Keene and the Keene Ice organization! This is a huge step forward and means that if the fund-raising all works out we should see a brand new ice arena here in Keene opening as soon as next September – awesome news for those of us who love winter sports!
I was there at the meeting and was delighted to hear Councilor Mitch Greenwald mention during his report about the previous week’s Finance Committee meeting something along the lines of:
“…there was even a guy there from a curling organization… that’s something even we could do [pointing to another councilor] given that we can’t skate…”
Curling is a sport that is accessible to all ages… young, old, and everywhere in between. And while you obviously may play better if you are in athletic condition, you certainly don’t need to be. I’ve played on teams with people of all ages and physical conditions. If you can’t bend your knees you can deliver rocks with a special stick. There are even leagues of wheelchair curlers. Pretty much anyone can play curling!
That’s why we want to bring a dedicated curling facility to the Keene region – to provide another winter sport option and to make Keene a true center for winter sports activity!
WILL YOU JOIN WITH US and help us spread the word about bringing curling to the Monadnock region?
P.S. And yes, we are talking to the Keene Ice folks because there does appear to be a place in their plans where they might be able to add a couple of sheets of curling ice! Stay tuned……..
Are there large-scale attacks happening against VoIP and videoconferencing systems today? Or is it limited to one particular system? In a posting this morning to the VoiceOps mailing list, J. Oquendo wrote:
We have seen a larger than normal, if not, one of the largest attacks against some of our VoIP and video conferencing systems today. Initially, we fielded a report of a “system gone bad” followed by another, then another, and another. This has now carried on into some of our videoconference units (LifeSize).
Because our goal is to get telephony up and running, there was not much we could do via incident response, so I have little to add on attack vectors however, I will state that PBXNSIP has been the primary target, with about a dozen of these being hit pretty hard to the point I’ve had to block all, stop the software and re-start it.
Given that J. Oquendo has been around VoIP security circles for quite a few years now and worked on a number of different projects, I’m inclined to believe his account. Are any of you seeing increased attacks? If so, I think he’d certainly like to hear from you. If you’re not a member of the VoiceOps list, you might also want to join that list as it’s become quite a good resource for people involved in the operations of VoIP systems.
Thirty years ago this month, in November 1983, two RFCs were published that defined the critical Internet service that we now take for granted and use every day – the Domain Name System or more generally just “DNS”. Those two RFCs, authored by Paul Mockapetris, were:
- RFC 882: Domain Names – Concepts and Facilities
- RFC 883: Domain Names – Implementation and Specification
These two RFCs formed the basis for what was to become the DNS system we use today. There was a great amount of discussion in the early 1980′s around how to move beyond the flat naming convention used in the early “ARPA Internet”. Several proposals were out there that make for interesting reading today, including RFC 799, RFC 819 and RFC 830. As Paul Mockapetris relays in a video for the Internet Hall of Fame (IHOF) Internet timeline, his boss at the time, Jon Postel, asked Paul to look at the various ideas and come up with a proposal of his own for how it should work. The result was RFCs 882 and 883.
Four years later, in November 1987, these two original RFCs (882 and 883) were then “obsoleted” by RFC 1034 and RFC 1035 in which Paul updated and expanded the original RFCs based on the experience of those four years in actually implementing DNS. These newer RFCs 1034 and 1035 are still the basis of DNS today, although they have been “updated” many times since, including by the addition of DNSSEC in RFCs 4033, 4034 and 4035.
Today the DNS is a critical part of our Internet infrastructure and is the service guiding us in connecting to all the other services we use across the Internet. We all use DNS all the time every day even though, as Paul Mockapetris wrote earlier this year, we may not even be aware that we are using DNS.
Here at the Deploy360 Programme we are focused on how we collectively can make the DNS more secure using DNS Security Extensions (DNSSEC) and through that how we can make the overall Internet safer and more secure. But as we do that, we do also need to step back and just think about how amazing the overall DNS system is – and how incredibly critical it has become!
Happy 30th anniversary to the DNS! It will be fascinating to see where it goes next!
UPDATE: Our colleague Andrei Robachevsky also provided some commentary in a post, Happy 30th Birthday, DNS!, where he points to some other briefing papers, studies and reports around DNS, and also touches on issues relating to the abuse of DNS.
An audio commentary on this topic is also available: