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.

Quad, eh?

DNS is your IPv6 friend

by Craig Miller

IPv6  The Memory Test

Needs DNS

Old hands at IPv4 pride themselves on knowing the address of their servers, routers, name servers, etc. However with IPv6 and eight (8) groups of four (4) hexidecimal numbers as an address, this becomes more taxing on the memory. Of course an address like 2001:470:1d:583:fc48:b08e:c438:9e5d isn't impossible to remember, brighter minds than mine will be able to.

DNS to the rescue

As the internet grew in the early 80's it became apparent that having a service which would translate names to IP addresses would be extremely helpful. Humans, after all, are used to remembering names. In 1983, the first DNS (Domain Name Service, RFC 1034) was created, and BIND (Berkeley Internet Name Daemon) remains the standard for DNS today.

Internet Humour

DNS information is kept in a structured file, with name to address mapping in 'A' records. An example would look like this:

obake IN A 10.1.1.3
; IN HINFO "Intel Core I7 VM Host"

With the introduction of IPv6 for DNS (RFC 3596) a new type of line or record was added to the DNS structured file, an AAAA record, or Quad A record. 

Since an A record represented an IPv4 address (or 32 bit address) and an IPv6 is an 128 bit address, which is 4 time longer, it is an inside joke to make a DNS record 4 times longer, or a AAAA record.

Quad AAAA records

An example of a single A and Quad A record is:

obake IN A 10.1.1.3
obake IN AAAA 2001:470:1d:583:224:1dff:fed3:a117
; IN HINFO "Intel Core I7 VM Host"

As you can see it is much easier to type ping6 obake, rather than ping6 2001:470:1d:583:224:1dff:fed3:a117. And a lot easier to remember as well.

DNS as a transition tool

A really nice feature of DNS is that it will accept queries on both IPv4 and IPv6, returning either A or AAAA records. This means that if your host only makes DNS queries over IPv4, it can resolve IPv6 addresses (or if you prefer, query AAAA records).

Running a DNS service with A and AAAA records means any host, legacy or not, can resolve IPv6 addresses on your network. There is no cost beyond adding the AAAA records to your DNS. And suddenly, troubleshooting your network will get much easier.

A key difference from IPv4

DNS will typically not have reverse entries for IPv6. As I have mentioned in earlier posts, with SLAAC, and temporary (or private) addresses which change every 24 hours, your reverse entries in your DNS would have to be updated every day!

IPv6 is supposed to make your life easier, but updating reverse entries daily is not easier. So most network operators will have a few statically defined IPv6 reverse entries (usually for servers) and that is it.

IPAM

Another solution to address management, DNS, and reverse entries is the use of IPAM (IP Address Management) software. Of course you could keep track of your address management in an excel spreadsheet, and many do. But when adding IPv6, you will find the IPAM software to free you from typos, versioning, and locked shared file problems. BlueCat and BT Diamond are a couple of the many IPAM vendors out there today.

Hammer Time

Remember, DNS is a tool to make your life easier. Sure you can use a rock to pound a nail, but a hammer is so much nicer. DNS will make ping6 hammer time.

* Quad, Eh? is not an internet joke, but a Canadian one

IPv6 RA, RA, RA

IPv6 Router Advertisements

by Craig Miller

IPv6  The Network is in control

Router Advertisement

The authors of IPv6 wanted to learn from the IPv4 mistakes, and one key issue (at the time) was statically assigned addresses (DHCP hadn't been invented yet). As I have written in a previous post, SLAAC (Stateless Address AutoConfig) was a huge step forward in end nodes being able to get an address auto-magically.

End station (host, nodes, machines, etc) addressing is controlled by the Router Advertisements (RAs). In this article, I will delve into RAs a bit more, and explain how one can configure RAs to give you the result you are looking for.

RA Bits

Not surprisingly, RAs are sent by routers. The RA is a Type 134 ICMPv6 message (IANA ICMPv6 assign numbers). The individual interfaces on your router must be configured to send RAs when IPv6 is enabled. The RA has several flags (bit fields) which can be set or unset. The important ones for addressing are the A, M, and O bits. These control how the end station will get an address. Jeff Carrell summarized it well in a 2012 presentation.

I had this slide up on my cube wall for years, and gave a copy to anyone who seemed remotely interested in IPv6.

Simplifying the RA Bits

L bit

Let's start with the easy one. The L bit (or link bit) as you can see it is always on, and has no bearing on how an end station gets an address. 'Nuff said.

A bit

The next one to tackle is the A bit, this is the one that controls whether SLAAC is used by the end station.

M bit

The M bit is the Managed bit, which tells the end station to initiate DHCPv6 client request (RFC 3315). Unlike DHCPv4, IPv6 clients should NOT initiate a DHCPv6 request unless the M bit is set (not all clients respect this).

O bit

The Other bit, is a combination bit of sorts. The ideas is that SLAAC or manual may not provide all the information and end station may need, such as location of DNS and NTP servers. By setting the O bit, the network administrator is asking the end station to do a DHCPv6 for the options, but NOT for an address.

As you can see from Jeff's slide (above) the O bit is used with either the A bit (SLAAC provides the address) or the M bit (where DHCPv6  provides the address)

But wait, there's more 

RAs also advertise one or more prefixes for the link. Remember in What's with all those IPv6 Addresses end stations can have many IPv6 addresses. They can also have addresses in different subnets (on the same link). This would be useful for an address transition (from one address to another).

Since DNS is so useful (you were memorizing all those IPv6 addresses, right?), Recursive Domain Name Server Serivce (RDNSS) is useful (RFC 6106).

Lastly, for now, when the end station hear's the RA, and it assigns the default route next hop, as the link-local address of the router. By looking at the route table of the end station, you can see the default route:

$ ip -6 route
...
default via fe80::224:95ff:fef1:8ca dev mlan0  proto ra  metric 1024  expires 1608sec

There are other things in the RA, router lifetime, reachability, etc, which I may cover in a later post. But these are the important addressing bits.

RA Implementation Isues

This how it is supposed to work. The RFC's specify the ideal. But then it falls upon the developers to implement the ideal, and sometimes they fall short. When non-obvious combinations of RA bits (or flags) are set, non-obvious behaviours occur. Although the following RFC memo (it was only a draft, and has no number) is now expired, it still contains some good info about implementations of Windows 7, MacOS X 10.7 (aka Lion), and Ubuntu 12.04. It is well worth a read if you want to see how the OSs have really been implemented.

You can find the memo at: https://tools.ietf.org/html/draft-liu-bonica-v6ops-dhcpv6-slaac-problem-00

RA Troubleshooting

Want to see what your router is advertising?  You could fire up wireshark (or tcpdump) and wait, and wait, and wait for the router to send an RA (the configurable time is usually from every few minutes to much longer). Or you could issue a RS (Router Solicitation) and see the look at the RA that comes back.

The easiest way to do this is to use the linux utility rdisc6 (on Ubuntu, part of the ndisc6 package). This will do all the work, and show the results in a fairly human readable form.

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

Hop limit                 :           64 (      0x40)
Stateful address conf.    :           No   <--- M bit
Stateful other conf.      :           No   <--- O bit
Router preference         :       medium
Router lifetime           :         1800 (0x00000708) seconds
Reachable time            :  unspecified (0x00000000)
Retransmit time           :  unspecified (0x00000000)
 Source link-layer address: 00:24:95:F1:08:CA
 MTU                      :         1280 bytes (valid)
 Prefix                   : 2001:470:1d:584::/64
  Valid time              :         7200 (0x00001c20) seconds
  Pref. time              :         1800 (0x00000708) seconds
 Prefix                   : 2607:c000:815e:c400::/64
  Valid time              :         7200 (0x00001c20) seconds
  Pref. time              :         1800 (0x00000708) seconds
 Route                    : 2607:c000:815e:c400::/56
  Route preference        :       medium
  Route lifetime          :         7200 (0x00001c20) seconds
 Recursive DNS server     : 2001:470:1d:584::1
  DNS server lifetime     :         1800 (0x00000708) seconds
 from fe80::224:95ff:fef1:8ca

As you can see this router is advertising two prefixes into my network, and each of my hosts have five (5) IPv6 addresses (link-local, prefix 1 SLAAC, prefix 1 SLAAC/Temporary, prefix 2 SLAAC, prefix 2 SLAAC/Temporary).

Do not adjust your TV set, the RAs are in control

Knowing the RA bits, A, M, and O will help you control addressing on your IPv6 network. I have focused on the addressing components of the RA, but there is more  (home agent, reachability time, MTU size, etc), which can help you solve more challenging problems in your network. The RA is a useful tool to simplify your IPv6 network, hip-hip-hooRA for the RA.

*Jeff Carrell's 2012 presentation