On means & methods for predicting the timing of IPv6 adoption

Previously filled.


I’m more interested in concepts and approaches rather than the answer itself. Some background on developing the answer to this particular question follows below.

My interest here is more around how to phrase these claims such that they are meaningful over the time scales that we’re working with. One of the difficulties in working with claims over long enough periods of time is that institutions, currencies and measurement apparatus can vary sufficiently or fail outright across those time scales. I’m concerned with approaches to the “and how shall we test that?” Election results: easy; Hollywood movie sales: a procedure exists; Simon-Ehrlich or Bjorn Lomborg type wagers: controversial, but possible; and so on. What is of interest in this particular case is not whether something will happen in a binary sense but how soon something that is known to be happening is going to reach a significant enough level to matter, for some relevant definition of “matters.”

My interest is in how one goes about framing these questions (claims) about the future in a meaningful way, one that will be meaningful in the transition into the future as action against the claims will not be continued if the previous calls to action are no longer relevant. Futurism being but memoir writing if it isn’t tied to planning and thus to action. In the IPv6 case, the timing is important from an online entertainment perspective as the investment in the new networking scheme is significant. From a consumer standpoint, customer premises equipment is rarely churned unless it is force-replaced by the internet service provider. These technologies take multiple decades to roll out and be adopted so they are well within the time-span that we consider in the course (-10 years < t < +10 years).

On using wagers to “know the future”

There have been and maybe still are interesting expreriments with prediction markets against diffusion of innovation questions. Spoiler: the market (game) failed when two fine folks figured out how to run an arbitrage scheme on it; there were no countervailing forces sufficient to counteract the scheme. There exist other surveys in academic paper form of intra-corporate opinion markets. Separately filled.

Behind these is the thesis that a market can “know” things (encode knowledge) that no individual participant can “know” (understand). The aphorism often used is “In the short run, the market is a voting machine, but in the long run, it is a weighing machine.” This folk wisdom is usually attributed to Benjamin Graham and then Warren Buffet.


On the evolving IPv6 transition

In this particular case, we have (the industry has) a sufficient answer for business purposes and elements of the industry have been acting upon the answer as suits their temperament for risk and prospection. Google: yes (as shown), Comcast: yes, AT&T: no, Verizon: yes. RFC 6598 of 2012-04 were developed to support ISPs who have as-built infrastructure that will not be making the transition. Parts of Yahoo’s merchant ad systems went live 2012 (I drove that); the rest is transitioning now. The Google chart is interesting in that it did not hit 5% until two years ago. Prior to that one could reasonably say from a business perspective that there was “no business need” to consider the technology.

Some of these dates give the concept of how long these things take:

IPv6 was “in trials.”
B2B-type production availability; e.g. Solaris.
Microsoft shipped IPv6 default-enabled in Vista.
IPv4 was considered to have been exhausted in North America
“the Internet is full, please dial in at a later time.”

There are other longer technology transitions still under way.

On the continuing 64-bit transition

There is a wonderful survey article from ACM Queue that surveys the transition to 64-bit two-score year transition to 64-bit technologies. One is beginning to see the industry transition wholly to 64-bit for server-class and office-work-class gear and 32-bit and below for so called “IoT” leaf-level devices. The key signal for the future here is Intel’s announcement last month repudiating substantially all of their consumer-focused IoT SBC product lines. The supporting staff is now gone; Intel won’t be in that line of business going forward. And they aren’t a supplier in low-power “mobile” consumer gear meaningfully either. It’s an interesting question that: in 2027, “Intel Inside” means … ???


That other cultural transition, that didn’t happen.

The previous examples are all very in-trade and deeply technical. A more culturally-relevant transition that is still unfolding and is likely to several-multiple more generations to complete is the transition to the metric system in the United States, outside of narrow application domains. We tried but the U.S. population still trades against gallons of gas, quarts of milk, auto tires in pounds-per-square-inch; 55 miles per hour saves lives and gas-gallons, and thermostats shall be set to 65 degrees or lower. We are proscribed against carrying more than 3 ounces of toothpaste into airplanes nowadays.

One could imagine that what can’t (won’t) be different in any future scenario is the U.S. popular or commercial measurement system.

Originally a discussion point for PDV-91.

sendmail, still, intermittently, gives “host map: lookup ($domain): deferred”


sendmail gives “host map: lookup ($domain): deferred”, 2015-03-04.


And yet it continues to happen intermittently

  • Has something to do with IPv6 vs IPv4
  • Once sendmail is in that state, it never recovers

    • the queue never clears
    • its growth is unbounded
  • the only remedies are manual intervention
    • sendmail -q (manually)
    • systemctl restart sendmail (manually)


$ sendmail -v -d8.32 -qIMessageID


$ sudo sendmail -v -d8.32 -qIt85HF6hG025984
Running /var/spool/mqueue/t85HF6hG025984 (sequence 1 of 1)
dns_getcanonname(sender.example.com, trymx=1)
dns_getcanonname: trying sender.example.com. (AAAA)
	NO: errno=0, h_errno=4
dns_getcanonname: trying sender.example.com. (A)
dns_getcanonname: sender.example.com
dns_getcanonname(emerson.baker.org, trymx=1)
dns_getcanonname: trying emerson.baker.org. (AAAA)
	NO: errno=0, h_errno=4
dns_getcanonname: trying emerson.baker.org. (A)
	NO: errno=0, h_errno=4
dns_getcanonname: trying emerson.baker.org. (MX)
dns_getcanonname: emerson.baker.org
getmxrr(smart.mail.example.emerson.baker.org, droplocalhost=1)
getmxrr: res_search(smart.mail.example.emerson.baker.org) failed (errno=0, h_errno=4)
dns_getcanonname(smart.mail.example.emerson.baker.org, trymx=0)
dns_getcanonname: trying smart.mail.example.emerson.baker.org. (AAAA)
	NO: errno=0, h_errno=4
dns_getcanonname: trying smart.mail.example.emerson.baker.org. (A)
dns_getcanonname: smart.mail.example.emerson.baker.org
... Connecting to smart.mail.example.emerson.baker.org. via relay...
220 mta.emerson.baker.org ESMTP Sendmail 8.14.5/8.14.5; Thu, 10 Sep 2015 10:17:26 -0700
>>> EHLO sender.example.com
250-mta.emerson.baker.org Hello sender.example.emerson.baker.org [], pleased to meet you
250 HELP
220 2.0.0 Ready to start TLS
>>> EHLO sender.example.com
250-mta.emerson.baker.org Hello sender.example.emerson.baker.org [], pleased to meet you
250 HELP
>>> MAIL From: SIZE=845
250 2.1.0 ... Sender ok
>>> RCPT To:
>>> DATA
250 2.1.5 ... Recipient ok
354 Enter mail, end with "." on a line by itself
>>> .
250 2.0.0 t8AHHQ0v004865 Message accepted for delivery
... Sent (t8AHHQ0v004865 Message accepted for delivery)
Closing connection to smart.mail.example.emerson.baker.org.
>>> QUIT
221 2.0.0 mta.emerson.baker.org closing connection

draft-ietf-homenet-arch-12 | IPv6 Home Networking Architecture Principles

draft-ietf-homenet-arch-12 IPv6 Home Networking Architecture Principles; IETF; Editor: T. Chown (U. Southampton); J. Arkko (Ericsson), A. Brandt (Sigma Designs), O. Troan (Cisco), J. Weil (Time Warner Cable); 2014-02-14; expires 2014-08-18; 104 pages.


This text describes evolving networking technology within residential home networks with increasing numbers of devices and a trend towards increased internal routing. The goal of this document is to define a general architecture for IPv6-based home networking, describing the associated principles, considerations and requirements. The text briefly highlights specific implications of the introduction of IPv6 for home networking, discusses the elements of the architecture, and suggests how standard IPv6 mechanisms and addressing can be employed in home networking. The architecture describes the need for specific protocol extensions for certain additional functionality. It is assumed that the IPv6 home network is not actively managed, and runs as an IPv6-only or dual-stack network. There are no recommendations in this text for the IPv4 part of the network.




Troan, O., Miles, D., Matsushima, S., Okimoto, T., and D. Wing, “IPv6 Multihoming without Network Address Translation”, draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-06 (work in progress), February 2014.

Via: backfill

Are you ready for IPv6 insecurities? | George Kargiotakis

George Kargiotakis; Are you ready for IPv6 insecurities?; At Ath.Con; 2012-03-05; 60 slides.




  • Stateful DHCPv6
    • IA_TA
    • IA_NA
    • IA_PD
  • Stateless DHCPv6
    • SLAAC+OtherConfig Flag = 1
  • Handwringing
    • IPv6 Security Hype
    • Common Local Attacks & mitigation
    • Remote Network Scanning
    • Local Network Scanning
    • IDS/Firewalling
      • OS Support
      • IPv6 Migration
      • Security
    • Scanning IPv6 Internet
    • Tools
    • Food for thought – IPv6 Security Overview
  • Attacks
    • Address Resolution
    • Redirect
    • Duplicate Address Detection DoS
    • First-Hop Router Attack
    • Address configuration DoS
    • DHCPv6 Spoofing
  • Mitigations
    • RFC 6105 IPv6 Router Advertisement Guard; IETF; E. Levy-Abegnoli, Van de Velde (Cisco), C. Popoviciu (Technodyne), J. Mohacsi (NIIF/Hungarnet); 2011-02.
      • RA-Guard
      • L2 Protection
      • SEcure Neighbor Discovery (SEND)
    • RFC 4890 Recommendations for Filtering ICMPv6 Messages in Firewalls; IETF; E. Davis (self), J. Mohacsi (NIIF,  HUNGARNET); 2007-03.
    • RFC 3971 SEcure Neighbor Discovery (SEND); IETF; Editor: J. Arkko (Ericsson); J. Kempf (DoCoMo USA), B. Zill (Microsoft), P. Nikander (Ericsson); 2005-03.
  • Network Scanning
    • Tools of the trade
      • nmap
      • thc-ipv6: dnsrevenum6 (not included in v1.8)
      • ip6-arpa-scan.py
      • dns-ip6-arpa-scan.nse
    • mDNS
  • Best Practices
    • Block unused transition techniques
      • protocol 41
      • (6to4 tunnels)
    • Deny UDP 3544 (Teredo)
    • Deny TCP & UDP 3653 (Tunnel Setup Protocol, TSP)
  • Tunnel Setup Protocol
    • Jimi Wales’ Wiki
    • RFC 5572 IPv6 Tunnel Broker with the Tunnel Setup Protocol (TSP); IETF; M. Blanchet (Viagenie), F. Parent (Beon Solutions); 2010-02.
  • Not Covered
    • Mobile IPv6
    • IPv6 over 3G (telecom)
  • Tools
    • THC-IPv6
    • scapy
    • ndisc6
    • tcpdump, wireshark
    • nmap (-6) + NSE scripts
    • nc6/socat
    • 6tunnel
    • ndpmon

Via: backfill

Broadband Forum’s Technical Reports on IPv6

Technical Reports of the Broadband Forum
Selected reports … in archaeological order

  • TR-254, Issue 1, Functionality Tests for Ethernet Based Access Nodes; 2012-06; 58 pages.
  • TR-242, Issue 1, IPv6 Transition Mechanisms for Broadband Networks; 2012-08; 64 pages.
  • TR-187, Issue 2, IPv6 for PPP Broadband Access; 2013-02; 32 pages.
    • TR-187, Issue 1; 2010-05; 32 pages.
  • TR-177, Issue 1, IPv6 in the context of TR-101; 2010-11; 64 pages.
  • TR-146, Issue 1, Subscriber Sessions; 2013-05; 46 pages.
  • TR-101, Issue 1, Migration to Ethernet-Based DSL Aggregation; 2006-04; 101 pages.


Chris Van Fossen (Hurricane Electric); Webcast 41; On YouTube; 2010-12-28; 2:04.

radvd and NetworkManager for RFC 6106 (IPv6 Router Advertisement Options for DNS Configuration)


  • dhcpd (ISC’s DHCPv6)
    • stateless mode is a dhclient-side activity
    • remove the ia (ask for address) statements from the interface stanzas
    • Example:
      iface eth0 {
      option domain
      option time-zone
      ... }
  • radvd
    • AdvManagedFlag off;
    • AdvOtherConfigFlag on;
    • RDNSS address list {
      AdvRDNSSPreference 8;
      AdvRDNSSLifetime 3600;
      ... }
  • NetworkManager
    • nmcli connection
  • rdnssd
    • obsolete, incorporated into NetworkManager

Commentary & Tutorial

  • Jeremy Visser; Is an IPv6-only Network Feasible?; In His Blog; 2012-06-13.

    • <quote>Ubuntu 12.04 this works out-of-the-box with NetworkManager. On older versions of Ubuntu, you need to change IPv6 from “Ignore” to “Automatic” in NetworkManager.</quote>

Commitments & Comparisons

Fedora, Scoping & Project Documentation

Fedora 12

Comparison of IPv6 support in operating systems; In Jimi Wales’ Wiki

  • Fedora 13 => OK
  • RHEL6 => OK
  • Ubuntu 11.04 (Natty Narwal) => OK
  • Android => NO (Neither: DHCP6, ND RDNSS)
    1. Issue 32621: Support for DHCPv6 (RFC 3315)
    2. Issue 32629: Support for Recursive DNS Server Option in ICMPv6 Router Advertisements (RFC 6106)



  • RFC 6106 IPv6 Router Advertisement Options for DNS Configuration; J. Jeong (Brocade), S. Park (Samsung), L. Beloeil (France Telecom), S. Madanapalli (iRam); 2010-11.
  • RFC 4861 Neighbor Discovery for IP version 6 (IPv6); T. Narten (IBM), E. Nordmark (Sun), W. Simpson (Daydreamer), H. Soliman (Elevate); 2007-09.
  • RFC 3736 Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6; R. Droms (Cisco); 2004-04
  • RFC 3315 Dynamic Host Configuration Protocol for IPv6 (DHCPv6); Editor: R. Droms (Cisco); J. Bound (HP), B. Volz (Ericsson), T. Lemon (Nominum), C. Perkins (Nokia), M. Carney (Sun); 2003-07.

Via backfill

NetworkManager ifcfg-rh generates error: Invalid IP6 route destination address ‘defa’

Bug 991807 ifcfg-rh generates error: Invalid IP6 route destination address ‘defa’

Francesco Prelz; ‘default’ keyword in the RH ‘route6′ file; In network-manager-list; 2013-01-21.


--- ./src/settings/plugins/ifcfg-rh/reader.c.ORIG	2013-01-21 16:59:46.000000000 +0100
+++ ./src/settings/plugins/ifcfg-rh/reader.c	2013-01-21 17:04:23.000000000 +0100
@@ -1041,9 +1041,9 @@
 	gboolean success = FALSE;

 	const char *pattern_empty = "^\\s*(\\#.*)?$";
-	const char *pattern_to1 = "^\\s*(" IPV6_ADDR_REGEX "|default)"  /* IPv6 or 'default' keyword */
+	const char *pattern_to1 = "^\\s*(default|" IPV6_ADDR_REGEX ")"  /* IPv6 or 'default' keyword */
 	                          "(?:/(\\d{1,3}))?";                   /* optional prefix */
-	const char *pattern_to2 = "to\\s+(" IPV6_ADDR_REGEX "|default)" /* IPv6 or 'default' keyword */
+	const char *pattern_to2 = "to\\s+(default|" IPV6_ADDR_REGEX ")" /* IPv6 or 'default' keyword */
 	                          "(?:/(\\d{1,3}))?";                   /* optional prefix */
 	const char *pattern_via = "via\\s+(" IPV6_ADDR_REGEX ")";       /* IPv6 of gateway */
 	const char *pattern_metric = "metric\\s+(\\d+)";                /* metric */

(Hack) Workaround

Install as /etc/NetworkManager/dispatcher.d/02-default-routes-ifcfg-rh


# Copyright (c) 2012-2013, Wendell Craig Baker, wbaker@baker.org
# You have been granted permission to copy, modify, distribute and create
# derivative works based on the contents of this file.  Use and enjoy it
# in good health and moderation.

# Because NetworkManager plugin-ifcfg-rh won't establish default routes
# Because network service (/etc/sysconfig/network-scripts/ifup-ipv6) will establish default rules
# Here we have a hack to extract "hacked out" default rules and install them

function echologger() {
    echo "$@"
    logger "$@"

echologger "trace start $0 $@"

if ((3 < DEBUG)) ; then
    echologger "$0 debug, before PATH=$PATH"
# Because, inexplicably, /usr/sbin and /sbin aren't supplied in the path!
export PATH="$PATH:/usr/sbin:/sbin"
if ((3 < DEBUG)) ; then
    echologger "$0 debug, after PATH=$PATH"

DEVICE="$1"; shift
ACTION="$1"; shift

# Where all the nm hookery hocus pocus lives
# recall: there are two aspects to nmhook: sit pair and default route hacks
declare settings="/etc/sysconfig/network-scripts/nmhook-$DEVICE"
if [ ! -f "$settings" ] ; then
    exit 0
elif ! source "$settings" ; then
    # the file was there but there was a problem sourcing it
    exit 1
elif [ -z "$DEFAULT_DEVICE" ] ; then
    # WATCHOUT - DEFAULT_DEVICE is ill-considered actually ... it makes no sense
    # it specifies other things but not DEFAULT_DEVICE.  It is not used
    if ((1 < DEBUG)) ; then 	# this isn't necessarily an error         echologger "$0 debug, warning there is no DEFAULT_DEVICE definition for $DEVICE"     fi fi 1>&2

if ((1 < DEBUG)) ; then

function drive_ip() {
    local act=$1; shift
    local kind=$1; shift
    local device=$1; shift
    local file="/etc/sysconfig/network-scripts/$kind-$device"
    if ((1 < DEBUG)) ; then
	echologger "$0 debug, file $file"
    if [ ! -f "$file" ] ; then
	if ((1 < DEBUG)) ; then
	    echologger "$0 debug, no such file $file"
	return 0
    local -i line_i=0
    cat "$file" | while read line ; do
	if ((3 < DEBUG)) ; then
	    echologger "$0 debug, line $line_i (raw) $line"
	if [[ "$line" =~ ^#HACK-ifcfg-rh: ]]; then
	    # a special comment
	    #   #HACK-ifcfg-rh: blahblahblah
	    if ((2 < DEBUG)) ; then 		line_i=$((line_i+1)) 		echologger "$0 debug, line $line_i (exec) $line" 	    fi 	    : fallthru 	elif [[ "$line" =~ ^# ]]; then 	    # a regular comment 	    continue 	elif [[ "$line" =~ to\ default\ via ]]; then 	    # it's a default route line that ifcfg-rh won't handle 	    # 	    # NetworkManager[419]:    ifcfg-rh:     error: Invalid IP6 route destination address 'defa' 	    # 	    : fallthru 	else 	    continue 	fi 	local command 	case $kind in 	( route | rule ) 	    # Specimen: 	    #     ip -4 route add ...blahblah... 	    #     ip -4 rule add ...blahblah... 	    thiskind=${kind%4} 	    command="ip -4 $thiskind $act $line" 	    ;; 	( route6 | rule6 ) 	    # Specimen: 	    #     ip -6 route add ...blahblah... 	    #     ip -6 rule add ...blahblah... 	    thiskind=${kind%6} 	    command="ip -6 $thiskind $act $line" 	    ;; 	( * ) 	    { 		echo "$0, internal error, invalid act=$act" 		continue 	    } 1>&2
	if ((0 < DEBUG)) ; then 	    echologger "$0 debug, $command" 	fi 	output=$($command 2>&1)
	declare -i e=$?
	if (( e )) ; then
	    echologger "$0 exit $e ($command)"
	    echologger "$0 output ${output:-empty}"

case $ACTION in
# Events described in NetworkManager(8)
( up )
    for kind in route route6 ; do
	drive_ip add ${kind} ${DEVICE}
( down )
    for kind in route route6 ; do
	drive_ip del ${kind} ${DEVICE}

if ((1 < DEBUG)) ; then
    ip -4 route show
    ip -6 route show

# end

Via backfill

Special Classes & Special-Use Addresses in IPv4 & IPv6

Reserved Addresses & Ranges in IPv4

Address Block Present Use Reference Assigned “This” Network RFC 1122, Section 1981-09 Private-Use Networks RFC 1918 1996-02 Shared Address Space
Carrier-Grade NAT (CGN)
RFC 6598, Section 7 2012-04 Loopback RFC 1122, Section 1981-09 Link Local RFC 3927 2005-05 Private-Use Networks RFC 1918 1996-02 IETF Protocol Assignments RFC 5736 2010-01 DS-Lite RFC 6333 2011-06 Documentation (TEST-NET-1) RFC 5737 2010-01 6to4 Relay Anycast RFC 3068 2001-06 Private-Use Networks RFC 1918 1996-02 Network Interconnect Device Benchmark Testing RFC 2544 1999-03 Documentation (TEST-NET-2) RFC 5737 2010-01 Documentation (TEST-NET-3) RFC 5737 2010-01 Multicast RFC 3171 1999-08 Reserved for Future Use RFC 1112, Section 4 1989-08 Limited Broadcast RFC 919, Section 7
RFC 922, Section 7

Reserved Address & Ranges in IPv6

Address Block Present Use Reference Assigned
::1/128 Loopback Addresss RFC 4291 2006-02
64:ff9b::/96 IPv4-IPv6 Translation RFC 6052 2010-10
::ffff:0:0/96 IPv4-mapped Address RFC 4291 2006-02
100::/64 Discard-Only Address Block RFC 6666 2012-06
2001::/23 IETF Protocol Assignments RFC 2928 2000-09
2001::/32 TEREDO RFC 4380 2006-01
2001:2::/32 Benchmarking RFC 5180 2008-04
2001:10::/28 ORCHID RFC 5180 2007-03 (ex-2014-03)
2001:db8::/32 Documentation RFC 3849 2004-07
2002:::/16 6to4 RFC 3056 2001-02
fc00::/7 Unique-Local RFC 4193 2005-10
fe80::/10 Linked-Scoped Unicast RFC 4291 2006-02
ff00::/8 Multicast Address Space RFC 4291 (node),
RFC 3307 (link)


IPv6 Transition Schemes: tunnels, 6over4, 6to4, 6rd


  • RFC 5969 IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) — Protocol Specification; IETF; ISSN: 2070-1721; W. Townsley, O. Troan (Cisco); 2010-08.
  • RFC 5569 IPv6 Rapid Deployment on IPv4 Infrastructures (6rd); IETF; ISSN: 2070-1721; R. Despres (RD-IPtech); 2010-01.


  • Protocol 41
  • 6rd is modified 6to4
  • CPE
    • IPv6 => address as prefix:V4ADDR::/64 (with prefix padded to /32)
    • IPv4 => tunnel endpoint is ISP link-level routable; e.g. public or RFC 1918
  • ISP
    • IPv6 => prefix is /32-or smaller and ISP-specific
      i.e. not 2002::/16 as that is shared by all ISPs
    • IPv4 => tunnel endpoint is anycast
      e.g., but not of 6to4


  • RFC 3964 Security Considerations for 6to4; IETF; P. Savola (CSC/FUNET), C. Patel (All Play, No Work); 2004-12.
  • RFC 3068 An Anycast Prefix for 6to4 Relay Routers; IETF; C. Huitema; 2001-06.
  • RFC 3056 Connection of IPv6 Domains via IPv4 Clouds; IETF; B. Carpenter, K. Moore; 2001-02.


  • Protocol 41
  • CPE
    • IPv6 => addressed as 2002:CPEv4ADDR::/48
    • IPv4 => CPEv4ADDR (however that is assigned).
  • ISP
    • IPv6 => prefix is 2002::/16
      • unicast => 2002:ISPv4ADDR::/48 for configured ISPv4ADDR
      • anycast => 2002:c058:6301::/48
    • IPv4 => tunnel endpoint is a unicast or anycast address
      • unicast => any link-level routable address, as seen from the CPE
      • anycast => in, but

6over4 – General Transition Mechanisms

  • RFC 2893 Transition Mechanisms for IPv6 Hosts and Routers; R. Gillian (FreeGate), E. Nordmark (Sun); 2000-08.
  • RFC 2529 Transmission of IPv6 over IPv4 Domains without Explicit Tunnels, B. Carpenter (IBM), C. Jung (3Com); 1999-03.
  • RFC 1933 Transition Mechanisms for IPv6 Hosts and Routers; R. Gilligan, E. Nordmark (Sun); 1999-04; obsoleted by RFC 2893


  • Protocol 41
  • Scope <quote snip=”true”>
    • Dual IP layer (also known as Dual Stack): complete support for IPv4 and IPv6 at hosts & routers.
    • Configured tunneling of IPv6 over IPv4: Point-to-point tunnels made by encapsulating IPv6 packets within IPv4 headers to carry them over IPv4 routing infrastructures.
    • IPv4-compatible IPv6 addresses: An IPv6 address format embedding embedded IPv4 addresses.
    • Automatic tunneling of IPv6 over IPv4: IPv4-compatible addresses to automatically tunnel IPv6 packets over IPv4 networks.</quote>
  • IPv4 address embedded in IPv6 at 0::/96
    • IPv4 => IPv4ADDR/32
    • IPv6 => 0::IPv4ADDR/128
  • Node Classes
    • IPv4-only node
    • IPv4/IPv6 node (also considered an IPv6 node)
    • IPv6 node
  • Address Cases
    • IPv4-compatible IPv6 address (i.e. within. 0::/96)
    • IPv6-native address
  • Tunnels
  • Rules with IPv4 address space embedded into IPv6 at 0::/96
    • routing
    • DNS
    • DHCP
    • BOOTP
    • RARP
    • ICMP
  • “regular” IPv6 address assignment
  • IPv4 is a link-level transport
  • “regular” link routing & gateway management

RFC 2526: Reserved IPv6 Subnet Anycast Addresses

RFC 2526: Reserved IPv6 Subnet Anycast Addresses; IETF; D. Johnson (CMU), S. Deering (Cisco); 1999-03.

<quote>Specifically, for IPv6 address types required to have to have 64-bit interface identifiers in EUI-64 format, these reserved subnet anycast addresses are constructed as follows:

|              64 bits            |      57 bits     |   7 bits   |
|           subnet prefix         | 1111110111...111 | anycast ID |
                                  |   interface identifier field  |

For other IPv6 address types (that is, with format prefixes other than those listed above), the interface identifier is not in EUI-64 format and may be other than 64 bits in length; these reserved subnet anycast addresses for such address types are constructed as follows:

|              n bits             |    121-n bits    |   7 bits   |
|           subnet prefix         | 1111111...111111 | anycast ID |
                                  |   interface identifier field  |

accept_ra=2 | Linux, IPv6, router advertisements and forwarding

Andy; Linux, IPv6, router advertisements and forwarding; In His Blog; 2011-09-05.


You want forwarding and you want SLAAC.  You may be on a backrev kernel.


Firstly, if you have a kernel version of 2.6.37 or higher then your answer is to set accept_ra to “2″. From ip-sysctl.txt:

accept_ra – BOOLEAN

Accept Router Advertisements; autoconfigure using them.

Possible values are:

  • 0 Do not accept Router Advertisements.
  • 1 Accept Router Advertisements if forwarding is disabled.
  • 2 Overrule forwarding behaviour. Accept Router Advertisements even if forwarding is enabled.

Functional default:

  • enabled if local forwarding is disabled.
  • disabled if local forwarding is enabled.

This appears to be a type of boolean that [e] wasn’t previously familiar with – one that has three different values.
If you don’t have kernel version 2.6.37 though, like say, everyone running the current Debian stable (2.6.32), this will not work. Helpfully, it also doesn’t give you any sort of error when you set accept_ra to “2″. It just sets it and continues silently ignoring router advertisements.

Bjørn Mork posted about a workaround for earlier kernels.

SOLVED: ssh -Y fails to forward X11 but X11Forwarding=yes


  • ssh -Y fails to forward X11 even though the sshd on the other end is configured with X11Forwarding yes
$ ssh -v -Y server.example.com
: Sending env XMODIFIERS = @im=none
debug1: Sending env LANG = en_US.utf8
X11 forwarding request failed on channel 0


  1. IPv6 is present or has been recently enabled on the server
  2. There is no IPv6 address bound to the lo interface


The server does not have IPv6 enabled “fully enough.”  Fix this.


$ echo 0 | sudo tee /proc/sys/net/ipv6/conf/lo/disable_ipv6
$ ip addr show lo
1: lo:  mtu 16436 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet scope host lo
    inet6 ::1/128 scope host valid_lft forever preferred_lft forever


$ ssh -v -Y server.example.com
debug1: Sending env LANG = en_US.utf8
Last login: Mon Jan 28 13:01:40 2013 from client.example.com
debug1: client_input_channel_open: ctype x11 rchan 4 win 65536 max 16384
debug1: client_request_x11: request from ::1 60577
debug1: channel 1: new [x11]
debug1: confirm x11
debug1: client_input_channel_open: ctype x11 rchan 5 win 65536 max 16384
debug1: client_request_x11: request from ::1 60578
debug1: channel 2: new [x11]
debug1: confirm x11

Some Collected Linux IPv6 References

 Collected References


Table 1: Red Hat ES 5.2 and SUSE SLES 10 IPv6 RFCs and IDs
[Reference Letters circa 2010]
Document Title
RFC 1981 Path MTU discovery for IP version 6
RFC 2460 Internet protocol, version 6 (IPv6) specification
RFC 2461 Neighbor discovery for IP version 6 (IPv6)
RFC 2462 IPv6 stateless address autoconfiguration
RFC 2464 Transmission of IPv6 packets over Ethernet networks
RFC 2465 Management Information Base for IPv6: Textual Conventions and General Group
RFC 2472 PPPv6 (Red Hat only)
RFC 2710 Multicast Listener Discovery (MLD)
RFC 3041 Privacy Extensions
RFC 3056 6to4 [RFC is not listed but probably supported —Ed.
RFC 3315 Stateful DHCPv6
RFC 3484 Default Address selection
RFC 3596 DNS Extensions to support IPv6
RFC 3810 Multicast Listener Discovery Version 2 (MLDv2)
RFC 4007 IPv6 Scoped Address Architecture
RFC 4193 Unique Local IPv6 Unicast Addresses
RFC 4213 Transition Mechanisms for IPv6 Host and Routers
RFC 4291 IPv6 Addressing Architecture
RFC 4443 Internet Control Message Protocol (ICMPv6) for the Internet ProtoVersion 6 (IPv6) Specification


ReadyNAS NV+ (v1, sparc) is discontinued, there will be no IPv6

There is no IPv6 for the ReadyNAS NV (v1)
Question: what firmware update will supply it.
Answer: no such update will ever exist.
Reference: IPV6 support for NV+; By mdgm; In the ReadyNAS Community Forum; 2012-07-04.

Therefore: avoid the ReadyNAS NV+ (v1, sparc)

Stick with ReadyNAS “Ultra” or “Pro” (v2, x86, Atom)


tcpdump of ICMPv6 Router Advertisments

Problem Statement

You are in IPv6. Your hosts are not receiving the router advertisements that they ought to be receiving.  For example, you have several radvd daemons running on the local link.  You expect to see several address assignments.  You see some, but not enough.


tcpdump -i eth0 'ip6 && icmp6 && (ip6[40] = 134)'

and for all of the NDP type traffic

sudo tcpdump -i eth0 'ip6 && icmp6 && (ip6[40] == 133 || ip6[40] == 134 || ip6[40] == 135 || ip6[40] == 136)'

Wrong Answer

tcpdump -i eth0 'ip6 && icmp6 && (icmp6[icmptype] == 134)'


$ tcpdump -i eth0 'ip6 && icmp6 && (icmp6[icmptype] == 134)'
tcpdump: IPv6 upper-layer protocol is not supported by proto[x]
$ rpm -q tcpdump

Also Relevant

Note tcpdump of ICMPv6 Destination Unreachable, Unreachable Address of 2012-12-17.


From: Types of ICMPv6 messages

Type Code
Value Meaning Value Meaning
ICMPv6 Error Messages
133 Router Solicitation (NDP) 0
134 Router Advertisement (NDP) 0
135 Neighbor Solicitation (NDP) 0
136 Neighbor Advertisement (NDP) 0
137 Redirect Message (NDP) 0