The Men & Mice Blog

IPv6 cheat-sheet, part 3: IPv6 multicast

Posted by Greg Fazekas on 10/18/19 8:56 AM

3_IPv6-cheat-sheet

Now that we’ve familiarized ourselves with the IPv6 header and the IPv6 address space, let’s take a look at multicast.

Unicast, anycast, multicast

IPv6 packets can be sent, depending on the intended purpose, in a variety of ways:

  • unicast: used for 1-to-1 communication; it sends the packet to a specific node. (Certain unicast addresses within the IPv6 address space are reserved. See the previous post for details.)
  • anycast: used for 1-to-1-of-many communication; it sends the packet to multiple nodes but only intended to the closest on its route.
  • multicast: used for 1-to-many communication; it sends the packet to multiple nodes.

We’re not covering anycast in detail at this moment, but we can — do let us know if that’s something of interest to you!

IPv6 multicast

IPv6 multicast works by nodes* joining multicast groups by sending Multicast Listener Discovery (MLD) report messages.

(*Little terminology from IETF: node is an interface enabled for IPv6. Router is any node that forwards IPv6 packets that are not expressly addressed to it. Host is any node that’s not a router.)

Multicast groups aren’t constrained by local or global (network) geography. Whether the host is on the local network or on the internet, as long as it’s signaling to join a multicast group, it can receive multicast packets sent to that group.

Any host can be a sender, whether it’s part of the multicast group or not. Only hosts part of the multicast group are receivers. Hosts can join or leave multicast groups dynamically at any time.

IPv6 multicast addresses: FF00::/8

All IPv6 multicast addresses share the prefix of FF00::/8.

  • The first octet is FF (1111 1111). This way you can tell at a glance if an IPv6 address is intended for multicast or not.
  • The second octet defines:
    • the lifetime (0 for permanent multicast; 1 for temporary)
    • and scope (1 for node, 2 for link, 5 for site, 8 for organization, and E for global scope).

The multicast address ends with the interface ID.

Well-known IPv6 multicast addresses

Many IPv6 multicast addresses are well-known to software implementing IPv6, to simplify common routing needs.

ff02::1

all nodes

ff02::2

all routers

ff02::5

all OSPF (Open Shortest Path First) routers

ff02::6

all OSPF DRs (OSPF Designated Routers)

ff02::9

all RIP (Routing Information Protocol) routers

ff02::a

all EIGRP (Enhanced Interior Gateway Routing Protocol) routers

ff02::d

all PIM (Protocol Independent Multicast) routers

ff02::f 

UPNP (Universal Plug and Play) devices

ff02::11

all homenet nodes

ff02::12

VRRP (Virtual Router Redundancy Protocol)

ff02::16

all MLDv2-capable routers

ff02::1a

all RPL (Routing Protocol for Low-Power and Lossy Networks) routers (used in Internet of Things (IoT) devices)

ff02::fb

multicast DNS IPv6

ff02::101

network time (NTP)

ff02::1:2

all DHCP agents

ff02::1:3

LLMNR (Link-Local Multicast Name Resolution)

ff02:0:0:0:0:1:ff00::/104

solicited node address

ff02:0:0:0:0:1-2:ff00::/104

node information query

ff05::1:3

all DHCP server (site)

ff05::101

all NTP server (site)

(Did we or did we not promise a veritable smorgasbord of acronyms?)

More IPv6 coming up!

Next time we’ll be taking a look at IPv4-IPv6 tunneling and the particularities of migrating from IPv4 to IPv6.

After that, we have one last post to cover the remaining sections on our cheat-sheet, including useful Linux commands.

As always, do let us know if there’s a particular part of IPv6 (whether covered in here or not) you’d like to know more about!

Topics: IPv6, IPAM, IP address management

IPv6 cheat-sheet, part 2: the IPv6 address space

Posted by Greg Fazekas on 10/11/19 8:52 AM

2_IPv6-cheat-sheet

Now that we know how an IPv6 packet header looks, let’s take a look at where it goes.

A word (or 2^128) on IP addresses

One of the primary advantages of IPv6 is that its address space is vastly larger than IPv4.

IPv4 has about 4 billion addresses available (mathematically, the practical limit is of course lower) and we’re running out of them, fast. Granted, who would’ve thought back in the day that people would want to assign IP addresses to their toasters. (And even if they didn't, 4 billion addresses don't even cover one device per human being on the planet right now by a long shot.)

IPv6, on the other hand, has a mathematical limit of 2^128 IP addresses. That’s a lot. To be exact, it’s 340,282,366,920,938,463,463,374,607,431,768,211,456 (340 undecillion, 282 decillion, 366 nonillion, 920 octillion, 938 septillion, 463 sextillion, 463 quintillion, 374 quadrillion, 607 trillion, 431 billion, 768 million, 211 thousand and 456.

Say that four times fast!)

To put that into perspective: if you took all the atoms on the surface of Earth, you could assign about a hundred(!) IPv6 addresses to each(!).

Okay, it’s a lot. Is there a point to this math trivia?

Yes!

The IPv6 address pool is impossibly large. Even with the reservations and practical limits, it’s mind-blowingly huge. And smart people at IETF came up with some navigation shortcuts to help our brains cope with managing it, as well as reserving a bunch for specific purposes.

Let’s have a look at those.

Common & reserved prefixes in IPv6 addresses

Because of the huge amount of possible IPv6 addresses, and since the format of IPv6 is 16 hexadecimal values (grouped in eight 16-bit groups) instead of IPv4’s more simple 4 decimal groups, developers of the standard came up with ways to shorten them.

One way is to use ‘::’ when a 16-bit group is all zeroes. Note that when there are multiple groups with zeroes, only the first group will get shorthanded to ‘::’. (Reason for this is the need for shortened IPv6 addresses to be reproduced in their full forms.)

Another useful “trick” is the reservation of special structures for specific purposes:

::/0 default route  
::/128 unspecified address All 128 bits are set to zero. (Like 0.0.0.0 in IPv4.) Used only when a device is first looking for an IP address assignment.
::1/128 loopback address Equivalent to 127.0.0.1 in IPv4. When set as a destination the packet will get immediately routed back to its source and never exits the host. Loopback is useful for testing.
::ffff:0:0/96 IPv4-mapped address Used to help the deployment of IPv6. The last 32 bits contain the IPv4 address, with FFFF (following 5 groups of zeroes) in the preceding group.
2001:1::1/128 port-control-protocol anycast Using this will route the packet to the closest device for address translation. (Such as NAT64 or NAT44.)
2001:1::2/128 Traversal Using Relays around NAT (TURN) anycast The IPv6 address block for use with TURN (a protocol allowing host behind NAT to receive data over TCP or UDP). Known as 192.0.0.10/32 in IPv4.
2001:db8::/32 documentation prefix Used to indicate resources such as RFCs, documentation, books, etc.
2620:4f:8000::/48 AS112 DNS sinkhole servers Used in environments where private IP addresses (ie, not globally unique) may originate DNS reverse lookups to these addresses. While best practices dictate to resolve these queries locally, sometimes they are directed at public DNS, which cannot answer the queries. To resolve this issue, and relieve pressure on the authoritative servers, the AS112 project was created, and this reservation ensures its compatibility with IPv6.
fc00::/7 Unique-Local Addresses (ULA) Prefix to local IPv6 unicast addresses generated with a pseudo-random global ID.
fe80::/10 link-local unicast Equivalent to the 169.254.0.0/16 block in IPv4. Used when the host doesn’t have an IPv6 address assigned either manually or through DHCP.
fec0::/10 site-local addresses (deprecated)

While not an exhaustive list by far, it covers the most often used cases.

More IPv6 coming up!

For sake of simplicity, we’ve split this topic into two parts. The second part, common multicast IPv6 addresses, will be out next week. (And if you thought there were too many acronyms in this one, you’re in for a surprise!)

After that, we have one last post to cover the remaining sections on our cheat-sheet, including IPv4-IPv6 tunneling, and covering useful Linux commands.

In the meantime, let us know if there’s a particular part of IPv6 you’d like to know more about!

 

Topics: IPv6, IPAM, IP address management

IPv6 cheat-sheet, part 1: the IPv6 header & EUI-64

Posted by Greg Fazekas on 10/4/19 9:59 AM

IPv6 is increasingly not an option but a fact of life. We’ve talked about it a lot (and some more and more) but this time we don’t want to discuss the merits or pitfalls of IPv6.

Instead, let’s take a closer look at the IPv6 protocol itself. 

We’ll use our famed IPv6 cheat-sheet (also available as a lens cleaner — visit us at events to score one) as a guide, and examine each section in depth.

Let’s start with, just like an IPv6 packet does, the header.

The IPv6 header

When discussing the IPv6 header it’s inevitable to compare it to what came before:

(Image credit: Wikipedia.)

This is of course the IPv4 header. It’s smaller in size: IPv4 uses 32 bit binary numbers whereas IPv6 uses 128-bit binary numbers. Size matters not, however. Or at least matters less.

IPv6 headers are much less complex:

The IPv6 header is more streamlined: it contains 8 fields, compared to IPv4’s 14 fields.

  • version: 4 bits long, and corresponds to IPv4’s field of the same name. It indicates the receiver the IP version to expect. In case of IPv6 that is of course 6, making this field’s binary value 0110.
  • traffic class: 8 bits long, and replaces IPv4’s ‘type of service’ field. The first 6 bits contain the differentiated services (DiffServ) designation of the packet, and is called differentiated services code point (DSCP). DSCP classifies the type of traffic carried by the packet for quality of service (QoS) purposes. For example, streaming media like video and audio on a conference call can enjoy lower latency than non-critical traffic, such as web browsing. The last two bits are for optional explicit congestion notifications (ECN). ECN can be used to signal congestion on the network by marking it in the IPv6 header. (Instead of dropping packets.)
  • flow label: 20 bits long, and new to IPv6. Useful for real-time applications, it signals the receiving node (routers or switches) to keep packets on the same path as to prevent them from being reordered.
  • payload length: 16-bits long. Contains the size of the payload in octets (remember those?) and can include extension headers. (Extensions headers replace the ‘options’ field known from IPv4.) It’s set to zero when the packet carries a jumbo payload.
  • next header: 8-bits long. It shares its function (and values) with IPv4’s ‘protocol’ field, and as the name suggests specifies the type of the next header.
  • hop limit: 8-bits long, formerly known in IPv4 as ‘time-to-live’. Decremented by one passing each node, and the packet is discarded when the value of hop limit reaches zero.
  • source address: 128 bits long, same function as in IPv4. Contains the IPv6 address of the node originally sending the packet.
  • destination address: 128 bits long, same function as in IPv4. Contains the IPv6 address of the destination node for which the packet is intended.

MAC to EUI-64 conversion

Extended Unique Identifier (EUI-64, because it’s 64-bits long) is a new method with which IPv6 hosts can be automatically configured in DHCP. The conversion is needed because hardware MAC addresses are 48-bits long.

This process is done in three steps:

  1. First the 48-bit MAC address needs to be separated into two 24-bit parts: C0:A1:B2:C3:D4:E5 becomes C0:A1:B2 C3:D4:E5.
  2. Then insert FF:FE between them, making it C0:A1:B2:FF:FE:C3:D4:E5.
  3. Lastly, invert the 7th bit: convert the first byte (C0 in this case) to binary (resulting in 11000000), check the 7th bit (0) and flip it (to 1) and translate it back to hexadecimal (binary 11000010 becomes C2).

The final EUI-64 version of the MAC address C0:A1:B2:C3:D4:E5 thus becomes C0:A1:B2:FF:FE:C3:D4:E5.

More IPv6 coming up!

In the next blog post we’ll continue the examination and explanation of the Men&Mice IPv6 cheat-sheet, and take a good look at the IPv6 address space and the things you can do with it.

In the meantime, let us know if there’s a particular part of it you’d like to know more about!

Topics: IPv6, IPAM

The ABCs of DNS: a select glossary from the Men & Mice training archives - Part 4

Posted by Men & Mice on 8/16/19 8:43 AM

Continuing our glossary of DNS tips & tricks, we’re covering the letters J, K, and L this time.

J is for “jumbogram”

Ever wondered what the largest (internet-layer) packet you can send? It’s 4,294,967,295 bytes. (One byte less than 4 GB.) Theoretically. Let’s break down the math (and the tech).

IPv6, among other things, has an extension that allows for a 32-bit length field. Jumbogram is the term for IPv6 packets taking advantage of it, capable of carrying more than the 65,535 octets of the limit of IPv4’s 16-bit length field.

However, transport layers such as TCP and UDP are limited to 16 bits. (TCP doesn’t have a length field, but the TCP MSS option and TCP Urgent field are both limited to 16 bits.) To make transporting larger payloads possible, these transport layers need a redesign to include 32-bit length fields.

RFC 1883, which first described the IPv6 standard, contained these modifications but was superseded by RFC 2460 which no longer did. RFC 2147 described the TCP and UDP enhancements but was obsoleted by RFC 2675 which merged the relevant parts from 1883 and 2147 into one document.

This is all theoretical, of course. RFC 2675 is listed as ‘informational’ and the practicality of jumbograms are debatable. But, as networking becomes more and more ubiquitous with larger and larger data transport needs, it may very well become everyday practice soon enough. Especially because larger payloads mean speedier delivery and less overhead - on the other hand, networks need better reliability to handle them. If just a small bit gets lost, scrambled, or corrupted, the whole payload has to be re-sent.

K is for “Kea”

In addition to DNS, an essential component of any network is DHCP. Just like DNS, development in DHCP doesn’t stop, to the extent of completely new software emerging to replace the old one: as is in the case of the Kea DHCP server.

Kea is the successor to ISC DHCP. While mature and robust, ISC DHCP is also old. It started in 1995, a time when networks were a lot smaller. Since then, network management became a lot more complex and mission-critical.

Kea is a modern DHCP server developed for the challenges of modern times. It's more scalable and offer better performance, with a different architecture. Kea also brings a somewhat different feature set, such as hooks and a rich API to configure users and subnets, Radius integration, and support for several database backends.

As is the case with any software no longer in widespread deployment, the development of ISC DHCP will cease in favor of Kea. ISC already recommends, particularly for new deployments, to use Kea instead of ISC DHCP.

To learn more about Kea and how to migrate from ISC DHCP take a look at its website.

L is for “labels”

As we discussed earlier, domain names are made up of three or more parts. These are called labels. 

A typical fully qualified domain name (FQDN) will look like this:

  • root (the trailing dot at the end)
  • top-level domain or “TLD” (such as .com, .net, etc.)
  • domain (such as menandmice)
  • host (such as www, info, etc.)

Labels can contain 1 to 63 octets. (An octet is a unit consisting of 8 bits. While technically the same as a byte, the latter is usually used to describe storage unit sizes.) Put it simpler, labels can be between 1 and 63 characters. The null label (length zero) is reserved for the root zone and is represented by the label terminating in the trailing dot.

Labels were initially restricted to ASCII, but in 2003 ICANN approved the IDNA (internationalized domain name) system. The IDNA maps Unicode characters to valid DNS characters via Punycode. For example, Þórsmörk.is (lovely place, you should visit!) would become xn--rsmrk-ztay3d.is 

Because domain names can have a maximum of 253 characters, the theoretical limit of a domain is 127 levels. (127 1-character labels + 126 dots separating them.)

Want to learn more?

This series is byte-sized (or, well, octet-sized) — but a lot more can be said and done. To learn more in-depth about DNS specifically, we offer a comprehensive DNS training program. 

You can enroll in different groups depending on your skill level:

  • If you’re new to DNS, we offer the DNS & BIND Fundamentals (DNSB-F) course. It’s part of the DNS & BIND Week (DNSB-W) and serves as a shorter introduction to the world of DNS and BIND.
  • If you’re already familiar with the basics, the full five-day DNS & BIND Week (DNSB-W) course takes you deeper into DNS, including a heavy emphasis on security, stopping just short of DNSSEC (for which we offer a separate course).
  • And if you're looking for even more, we offer the DNS & BIND Advanced (DNSB-A) program, getting into the deep end of things.

Check out our training calendar for 2019, and reach out to us with any questions.



Topics: IPv6, DNS training, Kea, domain name

World IPv6 Day 2019 (plus a podcast!)

Posted by Men & Mice on 6/6/19 9:50 AM

June 6th, 2012 (or “6/6”) saw the World IPv6 Launch Day. Today we celebrate the 7th anniversary.

For those in need of a quick cheat sheet, here’s ours.

(Mind you, this is not ONLY a cheat sheet, but also doubles up as a lens cleaning cloth. Come by our booth at  Cisco Live in San Diego to pick one up.)

Beyond that quick reference, what’s all the fuss about this old-new networking technology? What has changed since it’s been around (from the 1990s)? What hasn’t? And where do (or should) we go from where we are now?

To IPv6 or not to IPv6?

That is the question. For what it’s worth we, and literally everybody we spoke to at RIPE 78, are for IPv6.

That said, there is legitimate criticism against it. More often than not, however, it tends to be rooted in shortcomings of implementation, misunderstandings in adoption strategies, or just general reluctance toward the work involved in the switch.

Large tech companies have adopted IPv6 whole-heartedly. ISPs, cloud providers, and data centers have been offering IPv6 for a while. Microsoft has been at work getting rid of IPv4 addresses in their offices for years. Google even keeps a public chart of IPv6 adoption amongst its users:

Screenshot 2019-06-06 at 10.28.10

Bottom line is: adoption is on the up, but it’s still spotty at best. And it is true: IPv6 isn’t perfect. But then again IPv4 isn’t, either. It will not get any better, though, if we don’t dedicate effort to perfecting it through practice.

Fun fact: IPv6 addresses are free. IPv4 addresses go for $20+ a piece and that price keeps rising.

It’s evident that, various inventions and initiatives notwithstanding, we’ll likely soon be out of IPv4 addresses. Never before have there been so many connected devices, from smartphones to cars, from smart thermostats to smart toasters. IPv6 is an inevitability.

What can we do?

Introducing ‘resolv.pod’: a DNS podcast

We can, and most definitely should, discuss and evaluate our options regarding anything and everything affecting the future of the networks we depend on. Attend conferences, read papers, draft strategies.

To that end, we’re happy to announce that we are launching a podcast aimed at sharing with you the mindshare we have access to.

resolv.podOf course, as is clear from the name of our podcast, the focus won’t be on IPv6 exclusively, but rather anything and everything related to DNS, DHCP, and IPAM. Facilitating discussions about IPv6, amongst other things, and giving listeners fuller context from experts in the field, are the DNAME of the game (OK, name - just couldn’t resist).

As luck would have it, we were fortunate enough to grab a conversation with Geoff Huston, Chief Scientist at APNIC (Asia Pacific Network Information Centre)  in the lovely Reykjavik sunshine at RIPE78.

So to celebrate World IPv6 Day, why don’t you sit back and listen to our very first episode featuring Geoff talking networking highs and lows with Men & Mice’s Carsten Strotmann? It’s sure to entertain - and inform - in equal measure. Happy  World IPv6 Day!

Find resolv.pod on your favorite podcast platform:

More interviews and discussions coming up in the next weeks! Let us know what you’d like to learn more about via the podcast email, our social media channels, or as a comment below.




Topics: IPv6, DNS, podcast, resolv.pod, IPv6 Day

The RIPE-javik logs: Day 4 - Part 1

Posted by Carsten Strotmann on 5/24/19 12:03 PM

ripe day 4carsten@menandmice:~$ cat ~/ripe/ripejavik-day4.txt | blog-publish

Day 4 of RIPE78 was so jam-packed, we had to split it in two. Here’s Part 1!

IPv6 Working Group

Day 4 of RIPE78 started with the IPv6 working group. Geoff Huston discussed his measurement engine that focuses on using "ads" delivered to browsers in order to look into the reliability of IPv6 connections. While the IPv6 failure rate has gone down since early 2017 with 4%, it is now at 1.4%. Somewhat better, but still pretty bad.

Geoff found out that mobile networks deploying 464XLAT usually have more stable and reliable IPv6, than others using NAT64/DNS64 or other stateful IPv4-to-IPv6 translation mechanisms. IPv6 reliability appears to be exceptionally bad in Vietnam with a 6-10% failure rate.

Because of the Happy Eyeballs implementations in browsers, end users possibly don't notice the breakage except for a slight delay in establishing the connection. This is both good and bad: while the users are shielded from experiencing the issues in their ISP’s networks, the provider is also not incentivized to fix the issues. (As “it works”). Other countries with non-optimal IPv6 networks are Panama, Venezuela, Morocco, Bangladesh, and Turkey. Even China, with its experience in IPv6 networking, has a higher than average failure rate.

Another artifact Geoff found during his research is the fact that some networks route their IPv6 traffic differently (and often worse) than the IPv4 traffic. At some point between November 2016 and December 2016, all IPv6 traffic from and to India was routed via networks in Great Britain.

In the next talk, Enno Rey and Christopher Werny from ENRW shared their experience with IPv6 on WiFi hotspots. They are working on a project to provide IPv6 on up to 3,000 wifi hotspots in supermarkets and shopping malls all across Europe. After their evaluation of IPv6 support in common applications used by customers of these hotspots, they decided to deploy IPv6-only with NAT64/DNS64. (WLAN 100% IPv6, IPv6 to IPv4 translation at the gateway to the Internet.)

MulticastDNS and other multicast IPv6 communication are a problem for wireless networks, as the access point needs to distribute the multicast message to all clients in range, and needs to use the oldest WiFi protocol to be able to reach legacy clients. Using the older wifi protocols blocks the air for other traffic for a longer time. Enno and Christopher recommend tuning and throttling multicast traffic in IPv6 enabled WiFi networks to minimize this effect. The IETF is aware of the issues and is working on adjustments to the IPv6 protocol family to make IPv6 more WiFi-friendly.

IoT

Over in the IoT working-group, Jan Zorz reported on his attempt to build a "smart home" and gave insight into his design choices. Being an engineer, and also because of privacy concerns, he does not want to use "off the shelf" smart home devices that send sensitive data into the cloud and whose functionality is dictated by the vendor.

So Jan started to build his own smart devices. As the central management hub, he first started his experiments with a Raspberry Pi, but will switch to a more powerful 64bit x86 desktop mini-PC for production. Jan reported that he did not initially really know what he wanted and would expect from a "smart home" system: that insight developed over time while experimenting with different smart devices.

He encourages everyone to do some experimentation before deciding on a particular smart home technology. If you want to hear about the differences between Z-Wave vs. Zigbee, or which home automation software might be the best, have a look at the video recording of his talk.

Next up on the stage was Jelte Janssen from SIDN Labs talking about the SPIN ("Security and Privacy for In-home Networks”) project. The project is developing software tools that help end users to get insight into the network communication of IoT devices in the home and enable the user to better protect the home network. One tool from the SPIN project is the traffic monitor that shows DNS queries and data traffic in the local network, showing graphically to whom the IoT devices talk.

The goal is to get the SPIN tools in the default install of CPE (customer premise equipment, such as home routers) devices. In the same talk, Peter Steinhäuser from Swiss CPE Firmware developer Embedd reported on his company’s work on integrating SPIN in OpenWRT (a popular open source home router firmware based on Linux).

SIDN Labs has installation instructions for people who would like to test-drive SPIN on their existing OpenWRT based routers. Please note that SPIN is still in development and has some rough edges. However, the project would be happy to get feedback (and pull requests) from actual users.

Part 2 coming soon

Watch this space for the second part of our day 4 coverage on RIPE 78.

Topics: IPv6, IPv4, DNS, IoT

The RIPE-javik logs: Day 2

Posted by Carsten Strotmann on 5/22/19 8:31 AM

ripe day 2

carsten@menandmice:~$ cat ~/ripe/ripejavik-day2.txt | blog-publish

The second day of RIPE 78 started with the plenary, and three presentations on the topic of Distributed Denial of Service (DDoS).

DDoS

DDoS attacks are an increasing risk on the Internet. Mattijs Jonker from the University of Twente explained how DDoS attacks work. His research has revealed that many businesses have all their Internet services (website, mailserver, etc.) in a single network. In case of a DDoS attack, all services are impacted. He counted 31 thousand websites, 3.5 thousand mailservers, and 323 DNS servers that are on a single network and would suffer in case of an attack. An alternative IP address from a different network (autonomous system/AS) would make the services more resilient.

Matthias Wichtlhuber from the German Internet Exchange DE-CIX found that DDoS attackers only use certain protocols for their amplification attacks:

  • unspecified (Port 0)
  • NTP (Port 123)
  • LDAP (Port 389)
  • DNS (Port 53)
  • Chargen (Port 19)
  • Memcache (Port 11211)

Filtering these ports (in transport networks) will stop most DDoS attacks. The problem is that most ISPs cannot do fine-grained filtering. Most can only filter on networks or IP addresses, which blocks all traffic from or to a certain machine. DE-CIX has developed a new fine-grained black-holing system for DDoS attacks that is currently in beta testing.

Koen van Hove, also from the University of Twente, presented the DDOS clearinghouse: a project to collect data of DDoS attacks in a central place. The aim is to be able to research DDoS attacks and develop fast responses to them. The DDoS clearinghouse collects network measurements, identifies DDoS attacks across networks with unique fingerprints, and stores this data in a database (DDoSDB). From the database, attack information and metadata can be retrieved to help users feed fingerprint signatures into their network systems to stop DDoS attacks.

DNS

After the morning break, the main topic was DNS. David Huberman from ICANN discussed the root server system. After talking about the history of the DNS root server system, he explained that there has been no process so far for selecting new root server operators.

With over 1.120 root server instances in the world, 340 of which are in the RIPE region, the root server system is stable and there is currently no need to add additional root server operators beyond the 12 that run the 13 logical root-server addresses. ICANN is not working on a defined governance model for the root server system.

OpenINTEL

Next on the stage was Roland van Rijswijk (NLnet Labs) presenting the OpenINTEL project he has contributed to. OpenINTEL is a massive active measurement system that sends 218 million DNS queries per day from several vantage points on the Internet, resolving a defined set of DNS names. The results will be collected in a big database (Big Data helps to get research funds these days), which so far contains 3.1 trillion results since the start of the project in 2015.

The OpenINTEL system allows researchers to search for various kinds of interesting data: parent-child TTL mismatches, distribution of authoritative DNS-Servers in different AS networks, or even silly things stored in DNS TXT records (like funny IPv6 addresses or private cryptographic keys). The project can be found at https://openintel.nl

KSK roll

Like always, Geoff Huston (APNIC) delivered a highly entertaining talk, this time about the KSK roll in October 2018.

Officially, there was no impact seen for the DNSSEC validating resolvers. But some operators, like EIR in Ireland, have missed all notices about the roll in the two years leading up to it and failed to change the trust anchor of their DNS resolvers which lead to a full-day outage of their DNS resolver services. Other smaller operators were affected as well, some of which fixed the issue by disabling DNSSEC. All except two have re-enabled DNSSEC after fixing their DNS resolver configurations. Geoff also noted that the DNSSEC trust state signaling (RFC 6975 and RFC 8145) does not work reliably to detect broken KSK rolls in the root zone.

Migration from IPv4 to IPv6

In "Get Ready for Mixed World: Economic Factors Affecting IPv6 Deployment", Brenden Kürbis and Milton Mueller from the Georgia Institute of Technology talked about the economics behind network migration from IPv4 to IPv6.

The problem of IPv6 is that it is not possible to switch off IPv4 right away. Instead, IPv4 must be kept enabled for some amount of time (dual stack deployment). The cost generated due to IPv4 depletion will stay, the cost of introducing IPv6 will come on top. Only after some years will the cost benefits be visible. Depending on the growth pattern of the company and the networks, the first cost savings can appear as early as 4 to 10 years. Larger companies will have more benefit from IPv6, while smaller companies will not see economic benefits. In the following Q&A session, people from the audience challenged some of the assumptions in the research that generated this report.

DNS flag day

In the last DNS talk of the day, Petr Špaček from CZ.NIC and Ondřej Surý from ISC gave some insight into the DNS flag day in February 2019.

DNS vendors (Bind 9, Knot, PowerDNS, Unbound, and others) and large DNS resolver operators (Google, Cloudflare, Quad9, etc.) disabled workarounds for broken EDNS implementations. The workarounds were developed to help with DNS servers on the internet that had faulty implementations of the DNS protocol. However, because the workarounds existed, the operators of these faulty servers had no motivation to fix their systems. The cost of developing and maintaining the workarounds fell to the vendors of the DNS products.

For the February 2019 flag day, there was an estimated breakage of 5.68% of all DNS servers. Two large DNS operators were responsible for 66% of this breakage. The flag day was considered a success, as the pressure generated compelled the operators to fix their systems, and no other significant breakage was reported on that day.

Motivated by the success of this first flag day, the DNS server vendors plan another in 2020. No exact date has been set at the moment. On the next flag day, new DNS software releases will change the default settings for EDNS buffer size from today's 4096 bytes to a value around 1220 bytes. The goal is to prevent fragmentation of IP packets, which is known to be broken in some networks and can be a security risk. For this change, authoritative servers and DNS resolvers must be able to operate over TCP in addition to UDP. The main problem is misconfigured firewalls that block DNS over port 53/TCP.

The flag day website will be updated with detailed information about the date and will include online tests so that DNS administrators can test their systems.

More tomorrow!

RIPE 78 is a busy event, with much more going on than we were able to report here. Do visit the session archives to check the other presentations - there are plenty more good talks to dig into. We’ll be back with more RIPE coverage tomorrow!

Topics: IPv6, IPv4, DNS, DDoS, RIPE 78, OpenINTEL, KSK roll

The RIPE-javik logs: Day 1

Posted by Carsten Strotmann on 5/21/19 6:35 AM

ripe day 1

carsten@menandmice:~$ cat ~/ripe/ripejavik-day1.txt | blog-publish

The first day of RIPE 78 started with the welcome talk by RIPE chair Hans Petter Holen and the hosts of the meeting: Icelandic sea-cable provider Farice and RHnet, the university network provider of Iceland.

It was impressive to hear that Iceland has already achieved 80% Fiber-to-the-Home installation and will have 100% by 2025. In terms of Internet speed, Iceland is only second after Norway (for mobile Internet) and Singapore (for fixed line Internet).

After short talks by Andrew Sullivan, the president and CEO of ISOC, the Internet Society (the organisation that facilitates Internet Standards Processes such as those developed by the IETF, amongst other things) and Benno Overeinder for the RIPE Program Committee, probably the best known Icelander in the Internet community took to the stage: Ólafur Guðmundsson, inventor of DNSSEC and currently CTO of Internet accelerator Cloudflare.

IPv4 volatility

Ólafur’s topic was the volatility of IP addresses. While at the beginning of the Internet IP addresses were stable over a long time and could be used to identify a machine, this is not the case today. Mobile devices switch networks constantly, always getting new addresses. A smartphone can have more than 10 different IP addresses over the course of a single day, roaming across different mobile providers and wireless networks.

As Ólafur described, IP addresses cannot reliably be used to identify machines anymore. Still, many service providers, companies, and government agencies do that all the time, for

  • blacklisting,
  • geo-location,
  • to calculate online advertising prices by placing a value to the user using the IP address,
  • or to find the nearest content server.

IPv4 address brokerage makes the situation worse. Because there are no free IPv4 addresses left and many companies have not yet switched over to IPv6, IPv4 addresses are valuable (>20 US$ per address) and are for sale. When sold, these addresses change location, but providers of location databases cannot keep up with the changes and the databases become outdated and full of wrong data.

Roaming and routing

In the next talk, Alo Safari Khatouni spoke about the implication of mobile phone roaming in Europe. In his research, he has specifically looked into how IP data is being routed in roaming situations, and when the difference in latency and bandwidth impacts a roaming user’s experience.

He found no content discrimination (i.e. that certain data is being throttled during a roaming situation), but latency was certainly higher. Mobile network operators route the roaming traffic back to the home network, where it is then routed to the Internet. This means that for a customer of an US-based mobile network operator (MNO) who is in Iceland and trying to access a website in Iceland (to look up the weather conditions - vital information in Iceland!), the network data will be routed through the US MNO’s network. It’s no surprise that this is slower than staying in Iceland and accessing the data directly.

In the Q/A session following this talk, IPv6 evangelist Jan Zorz mentioned that he also experiences IPv6 Path-MTU-Discovery issues while being inside one of the MNO networks in Iceland. It may be that possibly someone is blocking ICMPv6 on the network.

ATLAS

In the first lightning talk, Christopher Amin from the RIPE NCC explained some of the security safety belts RIPE has built into the RIPE ATLAS system.

RIPE ATLAS is a network measuring networks, where ATLAS probes are distributed all around the world. These probes can be remotely controlled by researchers to make traffic measurements on the Internet from different points of the worldwide network. However, some probes are operated by private persons in their home networks and might be located in countries where access to certain Internet content is prohibited by law. Law enforcement might not be able to tell apart access from a real Internet device from that of an ATLAS probe.

To resolve this, RIPE has built in a host of security and safety measures to limit or block the access to sensitive Internet content, but also wants to add support for DNS-over-HTTPS (DoH) measurements to the ATLAS system. The problem here is that DNS-over-HTTPS looks, by design, like HTTPS traffic generated by a web browser. From the outside, one cannot see if the content requested is a website or DNS data. Enabling DoH measurements without restrictions can introduce risks for RIPE ATLAS probe operators. Christopher asked the RIPE community about their comments and how this challenge can be solved.

The second issue Christopher brought up was the use of EDNS (Extended DNS) options in ATLAS experiments. Researchers would like to test new or unspecified option values against DNS servers on the Internet, but this can lead to unexpected behaviour, even crashing DNS servers (if the DNS server software is not of high quality, which sometimes happens if network equipment vendors write their own implementations of DNS). There’s a risk in probing these EDNS options, but Christopher is not sure exactly how big the risk is.

IPv6-only

In the last lightning talk of Day One of RIPE 78, security expert Enno Rey presented his insights from an IPv6-only WLAN study that his company ERNW has conducted for a client. They found that mobile apps, especially on Apple’s iOS "just work.” (Which is no big surprise, as each app is tested by Apple to make sure it works as expected in an IPv6-only environment.)

ERNW found some applications that did not work out of the box and needed manual fixes, like the popular game "Fortnite" and its associated Epic Game Launcher. An XMPP (Jabber) component in the game only asked for IPv4 addresses (and the domain name has no IPv6 AAAA addresses), so this was naturally failing in a network without IPv4. Some other applications like Discord worked, but had some loss of functionality.

More tomorrow

This concludes our first report from RIPE 78. Check out our guide to both the event and the city, and stay tuned for more tomorrow.

Topics: IPv6, DNS, RIPE 78, ATLAS

Men & Mice Sensible IPAM Part 2: Scaling your IP Infrastructure

Posted by Greg Fazekas on 11/21/18 6:13 AM

Continuing our series on creating a sensible strategy to consolidate management of your scattered network resources, we take a look at what happens when new resources need to be added to your network.

This Playbook series consists of five parts:

Each part presents real-world problems that Men & Mice have experience in solving.

Scaling existing configurations

Imagine that you are:

  • an MSP Infrastructure Server Admin, using Microsoft. Your business utilizes Virtual Machines to handle client workloads, but without an efficient handling of IP addresses, your DNS doesn't get updated fast enough. Customers complain about lags.
  • a Product Manager for a SaaS company seeing an uptick in customer numbers. You have the system set up just right, but to handle all the demand, you are looking at pulling in dynamic resources using multi-cloud accounts. You also don’t want to add more team members to handle it, but automate instead.
  • a Director of Operations overseeing a large network spanning several locations. At the start, you used to have spreadsheets to track IP addresses, and kept configuration files practically in your head. Surely there must be a better way.

It makes no sense to start from scratch unless you have no other option. Any business that's been around for a while will have their workflows and configurations set up for the most part. And with the array of affordable cloud resources in services like AWS and Azure, moving on-prem configurations to cloud infrastructure becomes a viable option.

From smaller networks to large, from on-prem to cloud, from manual spreadsheets to automation: it’s just a matter of scaling.

What You Need

heterogenerous_IPinfrastructure

A DNS, DHCP, and IPAM solution to pull data unobtrusively from your existing configurations. You may have been using spreadsheets for tracking IP addresses, and a local library with DNS configuration files. Whatever they may be, you need to plug them into the new solution.

In addition, it needs to replicate and automate provisioning for new resources. Bonus points for a holistic approach, where various vendors can be brought in without the accompanying overhead, special training or new personnel. In short, you want to use an API-driven solution to control and manage all others.

Where Men & Mice can help

Men_Mice_DDI-1

A software-based, API-driven, and back-end agnostic solution, the Men & Mice Suite was developed to simplify core management of IP infrastructure in heterogeneous environments.

The Men & Mice Suite is a single-pane-of-glass overlay for your entire IP infrastructure, current, and future. Adding new resources, regardless of platform or vendor, isn’t hindered with compatibility problems since the software takes care of communicating with various on-prem solutions and cloud services through powerful, reliable APIs.

Overseeing multiple locations and resource allocations for different teams or projects can be done elegantly and easily. Already tested configurations can be deployed swiftly in new environments, extending oversight and reducing time for onboarding.

Once in place, configurations can be scaled and replicated easily and automatically. Copy or extend DNS zones and DHCP scopes, and deploy user authentication (including MS Active Directory) for new locations.

Spawning new virtual machines on cloud infrastructures is supplemented by IP address assignments that are reflected in all DNS servers. Once those IPs are released, the changes are automatically propagated through the network at once.

You and your team can reduce project time and cost significantly through more quickly responding to the changing needs of your business, without the need to set up lengthy processes each time.

Multi-cloud environments can be plugged into the Men & Mice Suite. Automated through a single API layer, and secured with role-based access control the network can scale out to any size and into any platform to accommodate workload, and scaled back once resources become unnecessary.

Plus, with Men & Mice, you can manage and migrate workloads to, from and between your on-prem and whichever best-in-class cloud service make sense for you. We'll cover hybrid and cloud-native solutions specifically in our next post.

 

Topics: IPv6, IPv4, IPAM, IP address management

RIPE 72 – A Blog Report on DNS & IPv6

Posted by Carsten Strotmann on 6/22/16 5:30 AM

RIPE 72 took place in Copenhagen from 23-27 May 2016. This blog report shares some of my thoughts on interesting talks and presentations on DNS and IPv6.  

As always, this report cannot be exhaustive and I recommend that those interested browse the meeting archive of RIPE 72 for other interesting topics.

DNS

Victoria Risk from ISC reported on the changes in the upcoming BIND 9.11 release (BIND 9.11 Release Update) that is planned for August 2016. The new catalog zone feature allows automatic provisioning of slave zones from a central catalog zone. New zones are configured as a master zone on one server and a special entry is written into the catalog zone, a meta-data zone that is configured on the master and all secondary servers. The catalog zone will be replicated by zone-transfer and the secondary server will automatically configure a slave-zone for the newly added domain.

Men & Mice Trainer Jan-Piet Mens has already had a chance to test this new feature and wrote a blog article about it: Catalog zones in BIND 9.11. ISC has issued an Internet Draft in the IETF about catalog zones with the hope that other DNS software vendors will implement a compatible version.

BIND 9.11 will include a new, refined backend for storing DNS zone data in databases, called the dyndb api. This new API is much faster than the older DLZ API and also works with DNSSEC.

Speaking of DNSSEC, BIND 9.11 will come with a new component called dnssec-keymgr that will be able to automate DNSSEC key-rollover based on a policy, much like the external OpenDNSSEC tool. More improvements to BIND 9.11 can be found in the presentation and also in the upcoming Men & Mice Webinar What's new in BIND 9.11.

Jeff Osborn from ISC started a discussion on a license change of the BIND 9 DNS Server in his talk Changing the Open Source License on BIND. Today, the BIND 9 DNS server is licensed under the ISC license, which is a permissive BSD-style license. Jeff proposes a switch to the Mozilla Public License (MPL), which is a so-called copy-left license. Both licenses are open-source licenses, but the main difference is that the MPL requires all source code changes to the product to be made public. This license change will have no negative effect on anyone using the BIND 9 DNS server, but might affect companies that build products that incorporate the BIND 9 server code. As an overlay management solution, the Men & Mice Suite product works with an un-altered BIND 9, so customers using the Men & Mice Suite would also not be affected by such a license change. Jeff welcomes any feedback on the license change. His contact information can be found in the talk's slides, available in the link above.

Patrik Faltstrom, Chair of the Security and Stability Advisory Committee on the DNS root-server system, presented an alert on WPAD Name Collision Vulnerability. WPAD, the "Web Proxy Auto-Discovery", is a way to configure the Web-Proxy to be used by a Web-Browser using DNS. In this function, the special domain name "wpad" is resolved in the local domain name of the network the client is in. Collisions with internal, non-registered domain names and new top level domains in the Internet DNS system now create the vulnerability that external parties can control the internal proxy configuration inside a company's network. Internet Explorer on Windows systems have this function enabled by default, but it can also be enabled in Firefox, Safari or Chrome-Browsers on MacOS X, BSD and Linux. Running an unregistered TLD in an internal DNS deployment is not recommended, but DNS administrators will find it difficult to remove the sins of the past. Administrators should block DNS queries for internal-only domains at their DNS-resolvers, monitor DNS queries leaving the network for internal names and consider manually switching off the WPAD function in the browsers.

Duane Wessels from Verisign gave a talk on the size increase of the Root-Zone Zone-Signing-Key (ZSK). Since the beginning of the DNSSEC-signed root-zone, the ZSK was a 1024bit RSA key, as recommended by RFC 6781 - DNSSEC Operational Practices, Version 2. However, while not an immediate security threat, 1024bit RSA keys are now also seen as having a too small security margin when used for DNSSEC signatures (1024bit RSA keys have been too weak for encryption for many years). The new ZSK will be a 2048bit key and it will be introduced into the DNS root-zone on 20th September 2016. All testing done so far indicates that there should be no problems. Even though the DNS responses from the root zone during a ZSK rollover do increase from 883 to 1138 octets/bytes, the response is still below the 1232byte EDNS0 limit often used in the IPv6-DNS-Resolver or the 1500byte Ethernet MTU.

The Unbound DNS-Resolver now implements DNS Query Name Minimisation to Improve Privacy, RFC7816. Ralf Dolmans of NLnetLabs explains in his talk QNAME Minimization in Unbound how this new feature is implemented. In traditional DNS, a DNS resolver always asks the full question to all servers in the delegation chain. This is because the DNS resolver does not know about the delegation topology of the DNS system in use. In the Internet, there is a defined delegation structure for DNS, starting with the root-zone, the generic, new and country-code top-level-domains and second-level domains owned by companies and individuals below it. In the Internet, a DNS-resolver can shorten the query when asking at the root-zone or TLD level, enhancing the privacy of the users of the DNS resolver. QNAME minimization in the DNS resolver used by a client machine can be tested with a DNS lookup tool such as dig

 

% dig txt qnamemintest.internet.nl +short


IPv6

John Jason Brzozowski from US cable giant Comcast presented IPv6 @Comcast – Then, Now and Tomorrow about the challenges and successes in their deployment of IPv6 "large scale". Overall, IPv6 at Comcast is a success and they are now putting in motion the plan to phase out IPv4.

In the IPv6-Working-Group session, John reported on Community WiFi and IPv6 and how Comcast is using IPv6 to create public WIFI hotspots on CPE devices. Comcast is giving out a full "/64" network to every WIFI-device connected, in order to create easy network isolation and to reduce the multicast traffic over WLAN. This scheme could have even more benefits, such as assigning an IPv6 address for every service running on a host.

The Google public DNS resolver now supports DNS64-translation (currently in Beta) on the public DNS-resolver address "2001:4860:4860::6464" (IPv6-Only Has Never Been So Easy). DNS64 is a translation technology that works together with NAT64 to allow a client on an IPv6-only network to connect to IPv4-only services on the Internet. As DNS64 "re-writes" DNS content, it clashes with DNSSEC, as Jen Linkova from Google explains in IPv6-only and DNS(SEC|64).The workaround proposed in the talk got some criticism from the audience.

Enno Rey from the security company ERNW had a close look at the security issues of Multicast Listener Discovery MLD, a topic that has not seen much attention so far. He and his colleagues have found several issues that can be used for denial of service attacks or traffic redirection attacks by an intruder inside the local network. He recommends an (still to be developed) "MLD guard" function in switches (similar to DHCPv4- or RA-Guard) or to deploy port based ACL filtering of MLD traffic. Nobody should panic because of these findings, but every IPv6 network admin should know about MLD and the implications of having MLD active in their networks.

Vaibhav Bajpai had an interesting talk on Measuring Webpage Similarity from Dual-Stacked Hosts, looking at the differences in website content between a page fetched via IPv6 vs. IPv4. Differences coming from certain objects on the page (CSS, JavaScript, Advertisements …) are only available for one protocol, while the general website is dual-stacked and therefore available on both IPv4 and IPv6.

Two talks covered the topic of IPv6-only networks, but from very different angles. In How to Make Trouble for Yourself - You Build an IPv6-Only Network in 2016, Roger Jørgensen from Bredbandsfylket Troms in Norway reported on their project to build a new fiber optic network in the far north of Norway. The management part of this network is designed and operated as an IPv6-only network. Luuk Hendriks gave a report of his attempt at Going IPv6-only at Home while keeping the most important user of his home network, his girlfriend, happy.

Enno Rey talks about Real Life Use Cases and Challenges When Implementing Link-local Addressing Only Networks as of RFC 7404 from his experiences implementing a Link-Local-only addressing scheme in a larger enterprise network. The Link-Local-only addressing was chosen to simplify address management, as almost 50% of networks in this customer's environment are point-to-point links. There are still issues with vendor support in network devices when implementing Link-Local-only addressing. In the discussion following the talk, the audience gave a mixed message, with some people claiming success at running a Link-Local-only network.

Other topics

Mircea Ulinic presented a way to automate the provisioning and management of network devices (router, switches etc) using the configuration orchestration tool "SaltStack". SaltStack is usually used to automate the provisioning of server machines running a Salt-Agent (Minion). As it is difficult to install a customer agent on network gear, this talk presented a way to use proxy machines that act as the minions for network hardware. SaltStack automation can save a great deal of time when used in large deployments. Details can be found in Mircea's talk: Network Automation with Salt and NAPALM.

Shane Kerr, who we recently had as an interview guest in our latest Webinar on Yeti-DNS, gave a humorous talk about the "Internet of Things (IoT)" in IoT: What is the Problem or “How To Explain To Your Boss That IoT Won't Make the Company Rich….”.

Those of you hungry for more on RIPE 72, all the above talks and more can be found in the meeting archive of RIPE 72.

Topics: IPv6, DNSSEC, DNS

Why follow Men & Mice?

The Men & Mice blog publishes educational, informational, as well as product-related material for everyone and anyone interested in IP Address Management, DNS, DHCP, IPv6, DNSSEC and more.

Subscribe to Email Updates

Recent Posts

Posts by Topic

see all