Quibbling in IPv6

Looking at the Language of IPv6

by Craig Miller

Trouble with Quibbles

Perhaps I should back up the train a bit, and talk about the IPv6 address and what the parts are called. An example IPv6 address is 2001:0DB8:ABCD:EF01:0001:002:0003:0004 * The address is made of of 8 groups of hexadecimal groups representing 16 bits, separated by colons.

Blowing Chunks

But what is each group of 4 hexidecimal letters called? Apparently it has taken the IETF 13 years to realize a name was needed. Back in 2011, in true IETF style, a draft RFC was created to foster discussion. It is interesting to look at the evolution of the draft RFC proposal (Naming IPv6 address parts). In the earlier drafts (e.g. draft-2), you can see the following suggestions:

1. Chazwazza 
2. Chunk 
3. Column 
4. Colonade, Colonnade 
5. Doctet 
6. Field 
7. Hexadectet 
8. Hit 
9. Orone 
10. Part 
11. Provider number, customer number, network number 
12. Quad nibble, qibble, quibble 
13. Segment 
14. Tuple 
15. Word 

All had reasons for why they represented 16 bits of information, and would not be confusing with other networking terms.

And in light conversation...

As you progress to the 4th revision of the RFC (Naming IPv6 address parts) you will find that they paired the list down to two.

1. Hextet
2. Quibble

Hextet is the official name based on revision 4, with Quibble to allowed in informal conversation. However the RFC was never standardized (there is no RFC number assigned), so it appears to be still up for grabs.

May the chazwazza be with you!

* There is an official documentation prefix defined by RFC 3849, 2001:db8::/32
** ST TroubleWithTribbles" by Source. Licensed under Fair use via Wikipedia

Tools of the trade

IPv6 Tools

by Craig Miller

IPv6 Tools

Just like the old saying, "with a hammer, everything looks like a nail"  we tend to over use ping or ping6 to troubleshoot our networks. In this post, I wanted to share some other tools which I use in debugging networks.

IP

ip is the successor to the venerable ifonfig. And with good reason, as ip can tell you much more about your configuration. It is installed by default on most distros, and usually lives at /sbin/ip.

link status

ip can display the status of the link (Layer 2 in the OSI model), as well as allow configuration of a VLAN based interface. To display the the link status use:

$ ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 10:9a:dd:54:f6:34 brd ff:ff:ff:ff:ff:ff
3: eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state DORMANT qlen 1000
    link/ether 10:9a:dd:ae:81:77 brd ff:ff:ff:ff:ff:ff

As you can see, it reports that status of link (is that cable plugged in?), and the MAC (Media Access Control, aka Ethernet) address.

ip addresses

ip can also show IPv4 and IPv6 addressing (using -4 and -6 respectively).

$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 10:9a:dd:54:f6:34 brd ff:ff:ff:ff:ff:ff
    inet 10.1.1.15/24 brd 10.1.1.255 scope global eth0
    inet6 2607:c000:815f:5600:e4a1:4d5f:961a:4973/64 scope global temporary dynamic 
       valid_lft 6951sec preferred_lft 1551sec
    inet6 2001:470:1d:489:fd2f:ea14:d171:c541/64 scope global temporary dynamic 
       valid_lft 6951sec preferred_lft 1551sec
    inet6 2607:c000:815f:5600:fd2f:ea14:d171:c541/64 scope global temporary deprecated dynamic 
       valid_lft 6951sec preferred_lft 0sec
    inet6 2001:470:1d:489:487d:35e:3834:c9a/64 scope global temporary deprecated dynamic 
       valid_lft 6951sec preferred_lft 0sec
    inet6 2607:c000:815f:5600:487d:35e:3834:c9a/64 scope global temporary deprecated dynamic 
       valid_lft 6951sec preferred_lft 0sec
    inet6 2001:470:1d:489:a0f0:7c93:4135:b344/64 scope global temporary deprecated dynamic 
       valid_lft 6951sec preferred_lft 0sec
    inet6 2607:c000:815f:5600:a0f0:7c93:4135:b344/64 scope global temporary deprecated dynamic 
       valid_lft 6951sec preferred_lft 0sec
    inet6 2607:c000:815f:5600:129a:ddff:fe54:f634/64 scope global dynamic 
       valid_lft 6951sec preferred_lft 1551sec
    inet6 2001:470:1d:489:4d85:44b3:3b87:1513/64 scope global temporary deprecated dynamic 
       valid_lft 6951sec preferred_lft 0sec
    inet6 2001:470:1d:489:5cd0:431a:b989:4517/64 scope global temporary deprecated dynamic 
       valid_lft 6951sec preferred_lft 0sec
    inet6 2001:470:1d:489:a121:bf93:87b8:c125/64 scope global temporary deprecated dynamic 
       valid_lft 6951sec preferred_lft 0sec
    inet6 2001:470:1d:489:c8c8:e6c4:ed49:e502/64 scope global temporary deprecated dynamic 
       valid_lft 6951sec preferred_lft 0sec
    inet6 2001:470:1d:489:129a:ddff:fe54:f634/64 scope global dynamic 
       valid_lft 6951sec preferred_lft 1551sec
    inet6 fe80::129a:ddff:fe54:b634/64 scope link 
       valid_lft forever preferred_lft forever
3: eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state DORMANT qlen 1000
    link/ether 10:9a:dd:ae:81:77 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::129a:ddff:feae:8177/64 scope link 
       valid_lft forever preferred_lft forever

As you can see, there are many SLAAC temporary addresses (RFC 4941) on the eth0 interface.

But wait, there's more!

routing

ip can also display IPv4 and IPv6 routing. Remember that IPv6 is a different network protocol (Layer 3), and packets can flow differently than their IPv4 counter parts. No surprises looking at the IPv4 routes:

$ ip -4  route
default via 10.1.1.1 dev eth0  metric 100 
10.1.1.0/24 dev eth0  proto kernel  scope link  src 10.1.1.15 

The IPv6 route table displays the default route with a link-local next hop

$ ip -6  route
2001:470:1d:489::/64 dev eth0  proto kernel  metric 256  expires 6865sec mtu 1280
2607:c000:815f:5600::/64 dev eth0  proto kernel  metric 256  expires 6865sec
fe80::/64 dev eth0  proto kernel  metric 256  mtu 1280
fe80::/64 dev eth1  proto kernel  metric 256 
default via fe80::224:a5ff:fee1:7ca dev eth0  proto kernel  metric 1024  expires 1464sec mtu 1280 hoplimit 64

rdisc6

While ip will tell you the configuration of the host, rdisc6 will tell you the configuration of your router, or at least what it is sending out as Router Advertisements (RAs). RAs send out prefixes, and controls whether clients will start DHCPv6 clients (RFC 3315), with the A, M, and O flags. rdisc6 will make a router solicitation (RS), and print out the RA in response.

$ rdisc6 eth0
Soliciting ff02::2 (ff02::2) on eth0...

Hop limit                 :           64 (      0x40)
Stateful address conf.    :           No
Stateful other conf.      :          Yes
Router preference         :       medium
Router lifetime           :         1800 (0x00000708) seconds
Reachable time            :  unspecified (0x00000000)
Retransmit time           :  unspecified (0x00000000)
 Source link-layer address: 00:24:A5:E1:07:CA
 MTU                      :         1280 bytes (valid)
 Prefix                   : 2607:c000:815f:5600::/64
  Valid time              :         7200 (0x00001c20) seconds
  Pref. time              :         1800 (0x00000708) seconds
 Prefix                   : 2001:470:1d:489::/64
  Valid time              :         7200 (0x00001c20) seconds
  Pref. time              :         1800 (0x00000708) seconds
 Route                    : 2607:c000:815f:5600::/56
  Route preference        :       medium
  Route lifetime          :         7200 (0x00001c20) seconds
 Recursive DNS server     : 2607:c000:815f:5600::1
  DNS server lifetime     :         1800 (0x00000708) seconds
 from fe80::224:a5ff:fee1:7ca

The Stateful address is the M flag, and Stateful other config, is the O flag. You can also see that two prefixes are being advertised into this network (the prefix advertised by my ISP is dynamic, where as my Hurricane Electric tunnel prefix is static).

There is a companion utility ndisc6 which will generate neighbour solicitations (NS). I don't use it much, but in order to install rdisc6, you will most often install the ndisc6 package.

v6disc

In addition to the tools above, I have written an IPv6 automatic discovery tool which you can find on github. v6disc.sh will detect which interfaces are up, and query all IPv6 nodes. if you have been wondering when nmap my scan your IPv6 networks, wait no longer. v6disc also has a Dual Stack option which will correlate IPv6 and IPv4 addresses, making your transition to IPv6 easier.

$ ./v6disc.sh -D
-- Searching for interface(s)
Found interface(s): eth0
-- INT:eth0 prefixs: 2607:c000:815f:5600 2001:470:1d:489
-- Detecting hosts on eth0 link
fe80::129a:ddff:fe54:b634 10.1.1.15
fe80::203:93ff:fe67:4362 10.1.1.18
fe80::211:24ff:fece:f1a 10.1.1.12
fe80::211:24ff:fee1:dbc8 10.1.1.14
fe80::224:a5ff:fef1:7ca 10.1.1.1
fe80::225:31ff:fe02:aecb 10.1.1.9
fe80::226:bbff:fe1e:7e15 10.1.1.23
fe80::256:b3ff:fe04:cbe5 10.1.1.122
fe80::280:77ff:feeb:1dde 10.1.1.13
fe80::a00:27ff:fe21:e445 10.1.1.123
-- Discovered hosts
2607:c000:815f:5600:129a:ddff:fe54:b634 10.1.1.15
2607:c000:815f:5600:203:93ff:fe67:4362 10.1.1.18
2607:c000:815f:5600:211:24ff:fece:f1a 10.1.1.12
2607:c000:815f:5600:211:24ff:fee1:dbc8 10.1.1.14
2607:c000:815f:5600::1 10.1.1.1
2607:c000:815f:5600:225:31ff:fe02:aecb 10.1.1.9
2607:c000:815f:5600:226:bbff:fe1e:7e15 10.1.1.23
2607:c000:815f:5600:256:b3ff:fe04:cbe5 10.1.1.122
2607:c000:815f:5600:280:77ff:feeb:1dde 10.1.1.13
2607:c000:815f:5600:a00:27ff:fe21:e445 10.1.1.123
2001:470:1d:489:129a:ddff:fe54:b634 10.1.1.15
2001:470:1d:489:203:93ff:fe67:4362 10.1.1.18
2001:470:1d:489:211:24ff:fece:f1a 10.1.1.12
2001:470:1d:489:211:24ff:fee1:dbc8 10.1.1.14
2001:470:1d:489::1 10.1.1.1
2001:470:1d:489:225:31ff:fe02:aecb 10.1.1.9
2001:470:1d:489:226:bbff:fe1e:7e15 10.1.1.23
2001:470:1d:489:256:b3ff:fe04:cbe5 10.1.1.122
2001:470:1d:489:280:77ff:feeb:1dde 10.1.1.13
2001:470:1d:489:a00:27ff:fe21:e445 10.1.1.123
-- Pau

There's even a quiet mode which just returns the discovered hosts addresses without all the chatter (good for scripting). v6disc is open source (GPL) and can be found on github at https://github.com/cvmiller/v6disc

Other Tools

Of course there are the network x-ray tools, tcpdump and wireshark.But are too big to properly cover in this post, so I'll cover in another post.

Happy Network

The keys to troubleshooting are know where you are at (ip addr), know where you are going (ip route), and what is out there (rdisc6 & v6disc). With these powerful, yet easy to use tools, your IPv6 network will be humming along in no time.

* Tools image from Creative Commons 

Little bitsy pieces

Fragmenting IPv6

by Craig Miller

A whole made of fragments

In the last post, I spoke of IPv6 Extension Headers (see Stretching IPv6 with extension 

headers), and one of those extension headers was the fragmentation extension header.

It's Different

Fragmentation happens differently from IPv4. Instead of the routers realizing that the packet is too large for the next hop, and fragmenting the packet, only the source host will fragment a packet. If an IPv6 router sees a packet that is too large for the next hop, it will drop the packet, not fragment.

When to Fragment?

How does the source host know what MTU (Maximum Transfer Unit) size to use? By sending a path MTU discovery (PMTUD RFC 4821 ). A probe packet is sent using the link MTU to the destination. If there is a link along the path that where the packet is too big, the router will drop it, and send back and ICMPv6 packet too big message. The source host will then decrease the payload size of the packet.

Most of the time, because of PMTUD, packet size will be scaled back to fit the smallest MTU size of the path, and no fragmentation will be required.

It is for this reason, that packets sent to other hosts on the same link should never be fragmented. Remember the RA Guard vulnerability? When fragmented packets are rejected from hosts on the same link, this vulnerability is eliminated.

Why Fragment?

If PMTUD works so well, when would it make sense to see a fragmented packet? If everything worked right, there would never be fragmentation. However the creators of IPv6 didn't want to assume everything would always work correctly. So they added the ability for the source host to fragment packets when needed.

There are some UDP applications which do not pay attention to PMTUD, and send out packets of their own desired length. When the stack receives such a packet, and through PMTUD it knows that this packet will not successfully cross the path to the destination, the stack on the source host will fragment the packet, and add a fragment extension header. See RFC 2460 section 4.5 for full details the specifics of fragmentation extension header values.

Guidelines

Some key thoughts about IPv6 fragmentation

• It is almost never required, thanks to PMTUD. 
• Source hosts do fragmentation, not routers in IPv6. 
• Be wary of ICMPv6 packets which are fragmented (a method of circumventing RA Guard).

Fragmentation is an option in IPv6, but it is an expensive option (both source and destination have to keep track of fragments used, splitting and reassembling packets). Thanks to PMTUD, it is rarely used. IPv6, and it makes networking simpler.

Stretching IPv6 with extension headers

Extending IPv6

by Craig Miller

IPv6  Extension Headers

Extending the reach

There was great concern when IPv6 was being created in the '90s about the increase in size of the IP header. After all, the IP source and destination addresses were increasing from 4 to 16 bytes each. 

It was important to keep the header size to a minimum, since every packet would have a header, and it represents overhead. After all, sending packets isn't about the headers, it is about the data that is being carried (e.g. web, streaming video,  voice over IP, etc.).

By rearranging things, and removing fields (like the header checksum), the creators of IPv6 managed to make the new header only 40 bytes long. 

But in removing as much as possible, the IPv6 header was stripped of many common things we have come to expect, such as fragmentation, and encryption. The concept of extension headers was added. It is important to know about extension headers, as they can also be misused to cause problems in your network. 

Extension headers defined in IPv6 (RFC 2460) are:

1. Hop-by-Hop Options
2. Routing (Type 0) - Removed by RFC 5095
3. Fragment
4. Destination Options
5. Authentication (AH)
6. Encapsulating Security Payload (ESP)

IPv6 extension headers are inserted after the IPv6 header and before the layer 4 (think: tcp, udp) header.

The purpose of some of the extension headers are obvious, such as Fragment, Authentication (authenticated header), and ESP. Let's look at the less obvious ones.

Hop-by-hop options: It was thought that there may be cases where the forwarding routers might need more information than what was left in the pared down IPv6 header.

Destination options: This is used to pad the header to align it to an 8 byte boundary, making it easier for the destination host to process. 

Security concerns

Many extension headers do not make sense between two hosts on the same link. For example, fragmentation. If both hosts are on the same link, there should be no need to fragment (remember IPv6 fragmentation is only done by the sender, not by the routers). Therefore, a host on the same link should not accept a packet with a fragmentation extension header.

Why is this a problem? Remember router advertisements (RAs)? These are only transmitted on a link (e.g. do not cross routers). Remember also that RAs define a network prefix, and a default gateway. What if a BAD person where to transmit their own RAs, telling hosts on the link that the BAD person was the default router. This would be a excellent method to do man-in-the-middle attack, since now all packets would travel through the BAD guy.

Cisco implemented a feature (in hardware) called RA Guard to block against this. Their layer 2 switches would examine packets for RAs, and discard them if they weren't from a designated router port. But the BAD guys figured out that they could use an extension header, like the fragmentation header, to pad out the RA packet a bit, and get past RA Guard.

Valid RAs should never be encapsulated in a fragmentation extension header, since RAs are always transmitted on the same link as the receiving host.

More extension headers

Since RFC 2460 was written in 1998, more extension headers have been added to IPv6. RFC 7045 gives a good list of current extension headers. Here are some additional headers added since RFC 2460:

1. Mobility Header, (RFC 6275)
2. Experimental use, Host Identity Protocol (RFC 5201)
3. Shim6 Protocol, (RFC 5533)
4. Use for experimentation and testing, (RFC 3692), (RFC 4727)

Extend this ...

You don't have to be an extension header expert to use IPv6. Most IPv6 packets will have no extension headers. They add back functionality that was stripped out of the IPv6 header, and used only when needed. 

Every networking mechanism has vulnerabilities and complexities. IPv6 simplifies many things in your network, and most likely you won't have problems with extension headers. Knowing about them, can help you troubleshoot, and fix your network faster.