March 2014 archive

New RFC 7157 Out About IPv6 Multihoming Without NAT

IETF LogoWhat are the challenges with connecting a small network or device to multiple ”upstream” IPv6 networks? How can you set up such a network while avoiding the Network Address Translation (NAT) required in IPv4?  To address these questions and provide useful guidance, a group of engineers wrote a document that was just published as RFC 7157, “IPv6 Multihoming without Network Address Translation that is available at:

The document has an abstract of:

Network Address and Port Translation (NAPT) works well for conserving global addresses and addressing multihoming requirements because an IPv4 NAPT router implements three functions: source address selection, next-hop resolution, and (optionally) DNS resolution. For IPv6 hosts, one approach could be the use of IPv6-to-IPv6 Network Prefix Translation (NPTv6). However, NAT and NPTv6 should be avoided, if at all possible, to permit transparent end-to-end connectivity. In this document, we analyze the use cases of multihoming. We also describe functional requirements and possible solutions for multihoming without the use of NAT in IPv6 for hosts and small IPv6 networks that would otherwise be unable to meet minimum IPv6-allocation criteria. We conclude that DHCPv6-based solutions are suitable to solve the multihoming issues described in this document, but NPTv6 may be required as an intermediate solution.

The document goes into quite some detail for both multihomed hosts (individual computers or servers) and multihomed networks and provides many good points to consider in considering how to set up multihomed environments.  It also includes many links for those interested in learning more.  Definitely worth reading for anyone looking to configure IPv6 to work with multiple Internet connections.

TDYR #143 – Of Flooding And Basement Drainage Systems

TDYR #143 - Of Flooding And Basement Drainage Systems by Dan York

Congrats to Aruba for Signing .AW with DNSSEC

dnssecIt was great to see that Aruba is the latest country-code top-level domain (ccTLD) to join the 298 TLDs that have signed their TLD with DNSSEC. With the .AW TLD signed, the first barrier is removed for companies and organizations seeking to sign their .AW domains and achieve the higher level of security possible with DNSSEC. At some point soon the registry for .AW should be able to start accepting DS records and the global chain of trust can then extend down to all signed .AW domains.

If your domain is in one of the other 297 signed TLDs, what are you doing to secure your domain? Have you signed your domain with DNSSEC yet? If not, how can we help you get to that point?

P.S. Aruba will now show up in the DNSSEC deployment maps and CSV files that we publish every Monday. If you are interested in receiving those maps each week via email, please visit the page and sign up.

Want To Attend IETF 90 In Toronto? Apply For An IETF Fellowship

IETF LogoAre you interested in attending the next meeting of the Internet Engineering Task Force (IETF) in Toronto in July 2014? Have you never been to an IETF meeting but would like to participate in the face-to-face aspect of the open standards process of the IETF?

If so, our colleagues who operate the “Internet Society Fellowship to the Internet Engineering Task Force (IETF) Programme” have alerted us that the next application window is open and applications will be accepted until April 11, 2014.  This “Fellows” program is open to men and women from developing and emerging economies who might not otherwise be able to attend an IETF meeting.  The goal is to help bring in more people from various regions of the world so that more voices are heard within the IETF discussions.

The most recent group of Fellows to IETF 89 in London included people from Venezuela, India, Morocco, Argentina, Tuvulu, Ecuador and Ethiopia.  At past IETF meetings I’ve had the opportunity to record video interviews with some of the Fellows and it has been amazing and inspiring to learn their stories.

If you are interested to learn more and apply, I would suggest starting with reading through the selection criteria and then down the main page on the Fellows program.  The links to apply as well as additional material can be found at the bottom of that main page.  As I noted above, the application window closes on April 11 for this upcoming IETF 90 in Toronto.  (It will then open up again a few months later for IETF 91 in November.)

If you’re interested in IPv6, DNSSEC, securing BGP… or, well, really any topic covered by the IETF, we’d encourage you to apply!  And we look forward to meeting up with some of you at future IETF meetings!

TDYR #142 – Slow Down, You Move Too Fast

TDYR #142 - Slow Down, You Move Too Fast by Dan York

TDYR #141 – Impressed So Far With Duolingo For Learning French

TDYR #141 - Impressed So Far With Duolingo For Learning French by Dan York

Next DNS-OARC Meeting May 10-11, 2014, Before RIPE68 in Warsaw

dns-oarcIf you are interested in all matters related to DNS, including DNSSEC, the next meeting of the DNS Operations Analysis and Research Center (DNS-OARC) will take place May 10-11, 2014, in Warsaw, Poland.  Sponsored this time by Microsoft, the “OARC 2014 Spring Workshop” is immediately before the RIPE 68 meeting taking place in the same location.

The agenda for the OARC 2014 Spring Workshop is still evolving but already includes a range of what look like excellent presentations related to DNSSEC and other similar topics.  The attendee list, too, is also filling up with many people with deep experience from across the industry.

It should be an excellent event for those interested in DNS and DNSSEC!

Meeting registration is free if you can get to Warsaw.  If you were already planning to go to the RIPE 68 meeting why not go a couple of days earlier and immerse yourself in DNS? :-)

TDYR #140 – Travelogue: The Long Journey Home From Singapore

TDYR #140 - Travelogue: The Long Journey Home From Singapore by Dan York

New IETF Mailing List To Discuss Privacy and Confidentiality of DNS

IETF LogoHow can we better protect the privacy and confidentiality of DNS queries? While DNSSEC protects the integrity of answers coming back from DNS (i.e. ensuring they aren’t modified in transit), what can be done to protect the confidentiality and privacy of information retrieved from DNS?  Particularly against the kind of pervasive monitoring and large-scale network sniffing we’ve become aware of?

We mentioned previously that at IETF 89 this month in London there was the “Encryption of DNS requests for confidentiality” (DNSE) BOF looking at these topics.  There was vigorous discussion during that BOF and then at the DNSOP working group meeting.  That large amount of interest has now sparked the creation of a new mailing list for all those interested in participating.  This “dns-privacy” list is public and open to anyone to subscribe:

List address:
To subscribe:

As you can see from the mailing list archive, there is already some discussion underway.  If you want some background the Internet drafts draft-bortzmeyer-dnsop-dns-privacy and draft-koch-perpass-dns-confidentiality may be useful.

While this doesn’t specifically related to the DNSSEC topic we cover here on Deploy360, it is part of the same overall space of “making DNS more secure” and so I thought it would be useful to point people to this new list.

Working together as an industry and community, we can make DNS more secure!  Please do join in and help out.

TDYR #139 – Final Day In Singapore: Running, DNSSEC And Meeting Great People

TDYR #139 - Final Day In Singapore: Running, DNSSEC And Meeting Great People by Dan York