Fedora 25, installation notes & experiences

Issues

  • IPv6 addresses come up with RFC7217 privacy mode enabled
    As such, the local radvd does not tag the machine with a “known” address.
    Remediation: turn off IPV6_ADDR_GEN_MODE=stable-privacy or set IPV6_ADDR_GEN_MODE=eui64 in the relevant /etc/sysconfig/network-scripts/enp1s0.

Reminder

Fedora Live Workstation…

  • … does not enable sshd. The firewall is configured to allow it, but the service is not enabled or started after the build.
  • … builds to graphical.target.  To back down to the non-graphical mode, systemctl set-default multi-user.target.  See the guidance in the (legacy) /etc/inittab commentary.
  • … uses firewalld to manage the iptables.  If you need to install a custom iptables setup, e.g. with xtables-addons xt_geoip rules then you need iptable-services.

Actualities

sudo dnf install -y xtables-addons

See the separate recipe for bringing down firewalld and bringing up the separable iptables services

systemctl get-default
sudo systemctl set-default multi-user.target
sudo systemctl enable sshd
sudo systemctl start sshd
nmcli reload
nmcli modify enp1s0 ipv5.addr-gen-mode eui64
nmcli con down enp1s0
nmcli con up enp1s0
$ cat /etc/sysconfig/network-scripts/ifcfg-enp1s0
HWADDR=00:EC:AC:CD:E6:12
TYPE=Ethernet
BOOTPROTO=dhcp
DEFROUTE=yes
IPV4_FAILURE_FATAL=no
IPV6INIT=yes
IPV6_AUTOCONF=yes
IPV6_DEFROUTE=yes
IPV6_FAILURE_FATAL=no
#IPV6_ADDR_GEN_MODE=stable-privacy
NAME=enp1s0
UUID=6c463f92-11d2-30ba-8273-d86bb3c58859
ONBOOT=yes
AUTOCONNECT_PRIORITY=-999
PEERDNS=yes
PEERROUTES=yes
IPV6_PEERDNS=yes
IPV6_PEERROUTES=yes

References

Standards

RFC 7217
A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)
F. Gont (SI6 Networks & UTN-FRH); IETF; 2014-04.
Abstract: This document specifies a method for generating IPv6 Interface Identifiers to be used with IPv6 Stateless Address Autoconfiguration (SLAAC), such that an IPv6 address configured using this method is stable within each subnet, but the corresponding Interface Identifier changes when the host moves from one network to another. This method is meant to be an alternative to generating Interface Identifiers based on hardware addresses (e.g., IEEE LAN Media Access Control (MAC) addresses), such that the benefits of stable addresses can be achieved without sacrificing the security and privacy of users. The method specified in this document applies to all prefixes a host may be employing, including link-local, global, and unique-local prefixes (and their corresponding addresses).
RFC 4941
Privacy Extensions for Stateless Address Autoconfiguration in IPv6
Narten (IBM), Draves (Microsoft) Krishnan (Ericsson); IETF; 2007-09.
Abstract: Nodes use IPv6 stateless address autoconfiguration to generate addresses using a combination of locally available information and information advertised by routers. Addresses are formed by combining network prefixes with an interface identifier. On an interface that contains an embedded IEEE Identifier, the interface identifier is typically derived from it. On other interface types, the interface identifier is generated through other means, for example, via random number generation. This document describes an extension to IPv6 stateless address autoconfiguration for interfaces whose interface identifier is derived from an IEEE identifier. Use of the extension causes nodes to generate global scope addresses from interface identifiers that change over time, even in cases where the interface contains an embedded IEEE identifier. Changing the interface identifier (and the global scope addresses generated from it) over time makes it more difficult for eavesdroppers and other information collectors to identify when different addresses used in different transactions actually correspond to the same node.

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.

Abstract

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.

Mentioned

Referenced

selected

[I-D.ietf-v6ops-ipv6-multihoming-without-ipv6nat]
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.

Referenced

People

Mentions

  • 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
      • 192.88.99.0/24 (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

Defining an IPv6-Ready CPE

Mentions

  • Address types
    • Link-Local (LL)
    • Unique Local Address (ULA)
    • Global
  • NAT
  • Dual Stack
  • Multicast Proxy Daemon
  • ICMPv6 Multicast
  • Recursive DNS Server (RDNSS)
    • RFC 6106 IPv6 Router Advertisement Options for DNS Configuration; IETF; J. Jeong (Brocade, ETRI), S. Park (Samsung), L. Beloeil (France Telecom), S. Madanapalli (iRam); 2010-11.
  • Privacy Extensions
  • EUI-64
  • Stateless Address Auto-Configuration (SLAAC)
  • DHCPv6
    • Stateful
    • Stateless
    • Prefix Delegation
  • Zeroconf (IPv4)
  • Point-to-Point Protocol (PPP)
    • Assigns /64
    • Assign /127 (/128)
    • Link Control Protocol (LCP)
    • Network Control Protocol (NCP)
    • IP6CP (IPv6CP) of Point-to-Point Protocol (PPP)
      • RFC 5172 Negotiation for IPv6 Datagram Compression Using IPv6 Control Protocol; IETF; Editor: S. Varada (Transwitch); 2008-03.
      • RFC 5072 IP Version 6 over PPP; IETF; Editor: S. Varada (Transwitch); D. Haskins, E. Allen; 2007-09; Obsoletes: RFC 2472.
  • Identity Association (IA)
    • Identity Association for Non-temporary Addresses (IA_NA)
      • RFC 3315 Dynamic Host Configuration Protocol for IPv6 (DHCPv6); IETF; Editor: R. Droms (Cisco), J. Bound (HP), B. Volz (Ericsson), T. Lemon (Nominum), C. Perkins (Nokia), M. Carney (Sun); 2003-07.
    • Identity Association for Temporary Addresses (IA_TA)
      • RFC 3041 Privacy Extensions for Stateless Address Autoconfiguration in IPv6; IETF; T. Narten (IBM), R. Draves (Microsoft); 2001-01.
  • Addressing LAN Clients
    • TR-101, Issue 1, Migration to Ethernet-Based DSL Aggregation; 2006-04; 101 pages.
      See TR-101 notes, backfill.
    • Claim: Prefix is at least /56 → 72 bits per TR-177.
  • Firewall
    • Statefull
    • User (Customer) managed
  • RFC 6106 IPv6 Router Advertisement Options for DNS Configuration; J. Jeong (Brocade, ETRI), S. Park, (Samsung), L. Beloeil (France Telecom), S. Madanapalli (iRam); 2010-11; Obsoletes: RFC 5006.
  • TR-069 Issue 1, Amendment 4, CPE Wan Management Protocol, Protocol Version v1.3; 2011-07; 190 pages.
  • Access
    • 6to4
    • 6rd
    • 6in4
      • Tunnelbroker.net
      • Hexago
      • Sixxs.net
    • A+P (Address plus Port)
    • NAT64
    • Dual-Stack Lite
    • 4rd

References

Broadband Forum

  • TR-187, Issue 1, IPv6 for PPP Broadband Access
  • TR-181, Amendment 2, TR-069 Data model extension for IPv6
  • TR-177, Issue 1, IPv6 in the context of TR-101
  • TR-124 Issue 2, Functional Requirements for Broadband Residential Gateway Device

IETF

  • RFC 6555 Happy Eyeballs: Success with Dual-Stack Hosts; IETF; D. Wing, A. Yourtchenko (Cisco); 2012-04.
  • RFC 6434 IPv6 Node Requirements; IETF; E. Jankiewicz (SRI), J. Loughney (Nokia), T. Narten (IBM); 2011-12.
  • RFC 6204 Basic Requirements for IPv6 Customer Edge Routers
  • RFC 6144 Framework for IPv4/IPv6 Translation
  • RFC 6092 Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service

Source

George Kargiotakis (GENNET Broadband Solutions); Defining an IPv6-Ready CPE; In Some Conference; 2011-05; 16 slides.
Via backfill

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

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 {
      ...
      ia
      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.
    Mentions

    • <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)

Concepts

Standards

  • 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

Special Classes & Special-Use Addresses in IPv4 & IPv6

Reserved Addresses & Ranges in IPv4

Address Block Present Use Reference Assigned
0.0.0.0/8 “This” Network RFC 1122, Section 3.2.1.3 1981-09
10.0.0.0/8 Private-Use Networks RFC 1918 1996-02
100.64.0.0/10 Shared Address Space
Carrier-Grade NAT (CGN)
RFC 6598, Section 7 2012-04
127.0.0.0/8 Loopback RFC 1122, Section 3.2.1.3 1981-09
169.254.0.0/16 Link Local RFC 3927 2005-05
172.16.0.0/12 Private-Use Networks RFC 1918 1996-02
192.0.0.0/24 IETF Protocol Assignments RFC 5736 2010-01
192.0.0.0/29 DS-Lite RFC 6333 2011-06
192.0.2.0/24 Documentation (TEST-NET-1) RFC 5737 2010-01
192.88.99.0/24 6to4 Relay Anycast RFC 3068 2001-06
192.168.0.0/16 Private-Use Networks RFC 1918 1996-02
198.18.0.0/15 Network Interconnect Device Benchmark Testing RFC 2544 1999-03
198.51.100.0/24 Documentation (TEST-NET-2) RFC 5737 2010-01
203.0.113.0/24 Documentation (TEST-NET-3) RFC 5737 2010-01
224.0.0.0/4 Multicast RFC 3171 1999-08
240.0.0.0/4 Reserved for Future Use RFC 1112, Section 4 1989-08
255.255.255.255/32 Limited Broadcast RFC 919, Section 7
RFC 922, Section 7
1984-10

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)
Registry

References

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

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.

Scheme

  • 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 192.88.99.0/24
      e.g. 192.88.99.201, but not 192.88.99.1 of 6to4

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.

Scheme

  • 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 192.88.99.0/24, but 192.88.99.1

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

Scheme

  • 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.

Problem

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

Mentions

<quote>
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.
</quote>

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

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

Indications

  • 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
<snip/>
: Sending env XMODIFIERS = @im=none
debug1: Sending env LANG = en_US.utf8
X11 forwarding request failed on channel 0

Background

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

Diagnosis

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

Remediation

$ echo 0 | sudo tee /proc/sys/net/ipv6/conf/lo/disable_ipv6
0
$ 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 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host valid_lft forever preferred_lft forever

Success

$ ssh -v -Y server.example.com
<snip/>
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

Google is serving IPv6 out of Australia, some 170ms out, and no rDNS for their addr

Domain Name IPv6 Address rDNS of the Address Ping Time
www.google.com 2404:6800:4008:c01::67  (none) 173 ms
www.youtube.com 2404:6800:4008:c01::5d  (none) 172 ms
www.yahoo.com 2001:4998:c:401::c:9102
2001:4998:f011:1fe::3000
2001:4998:c:401::c:9101
r2.ycpi.vip.gq1.yahoo.net 51.7 ms
ad.yieldmanager.com 2001:4998:44:80b::1000
2001:4998:44:80b::1001
mpr1-v6.ngd.vip.ne1.yahoo.com 50.0 ms
www.facebook.com 2a03:2880:10:8f02:face:b00c:0:1 edge-star6-10-12-prn1.facebook.com 33.0 ms
$ for i in www.{google,facebook,yahoo,youtube}.com ad.yieldmanager.com ad.doubleclick.net ; do ( ping6 -c 1 $i || echo $i unknown host ) 2>&1 | sed -e "s/^/$i--> /" ; done | grep -Ee '(from|host)'
www.google.com--> 64 bytes from 2404:6800:4008:c01::67: icmp_seq=1 ttl=53 time=173 ms
www.facebook.com--> 64 bytes from edge-star6-10-12-prn1.facebook.com: icmp_seq=1 ttl=55 time=33.0 ms
www.yahoo.com--> 64 bytes from r2.ycpi.vip.gq1.yahoo.net: icmp_seq=1 ttl=53 time=51.7 ms
www.youtube.com--> 64 bytes from 2404:6800:4008:c01::5d: icmp_seq=1 ttl=53 time=172 ms
ad.yieldmanager.com--> 64 bytes from mpr1-v6.ngd.vip.ne1.yahoo.com: icmp_seq=1 ttl=53 time=50.0 ms

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)

)

Routing & Traffic Control | Linux, IPv6 and iproute2

Bret Hubert, Gregory Maxwell, Remco ven Mook, Martijn van Oosterhout, Paul B. Schroeder, Jasper Spaans; Linux Advanced Routing & Traffic Control HOWTO; 2002-07-22.
Especially:

 

Policy Routing Using Linux
Matthew G. Marsh; Policy Routing With Linux – Online Edition
Especially:

Availability & Pricing


Quotes

  • Cutting edge is a polite way of saying “too risky” and “fit only for the severely bored.”

 

Create rDNS for fe80::/64 and ff02::/16 to make debug easier

Concept

Forward and reverse DNS for the link (link-local) addresses

  • Domain link. for unicast addresses within fe80::/64
  • Domain ndp.link. (NDP) for multicast addresses within ff02::/16

Do the best you can, the point here is to make tcpdump readable and your life managing EUI-64 and SLAAC-defined address substantially easier

Also Noted

tcpdump of ICMPv6 Router Advertisments; 2013-01-01.

Zones

$ host -t soa link.
link has SOA record ns0.emerson.dns.baker.org. hostmaster.emerson.baker.org. 19 28800 7200 604800 86400

$ host -t soa ndp.link.
ndp.link has SOA record ns0.emerson.dns.baker.org. hostmaster.emerson.baker.org. 4 28800 7200 604800 86400

$ host -t soa 2.0.f.f.ip6.arpa.
2.0.f.f.ip6.arpa has SOA record ns0.fd.ip6.arpa.emerson.dns.baker.org. hostmaster.baker.org. 68 3600 7200 604800 86400

$ host -t soa 0.8.e.f.ip6.arpa.
0.8.e.f.ip6.arpa has SOA record ns0.fd.ip6.arpa.emerson.dns.baker.org. hostmaster.baker.org. 68 3600 7200 604800 86400

Actualities

$ sudo tcpdump -i eth0 'ip6 && icmp6 && (ip6[40] == 135)' 
16:55:56.181501 IP6 lovelie.he.emerson.baker.org > rutabaga.ndp.link: ICMP6, neighbor solicitation, who has rutabaga.he.emerson.baker.org, length 32
16:55:57.418622 IP6 baggie.link > fishnet-effect.ndp.link: ICMP6, neighbor solicitation, who has fishnet-effect.he.emerson.baker.org, length 32
16:55:59.063757 IP6 wantowen.link > loosened.link: ICMP6, neighbor solicitation, who has loosened.link, length 32
16:55:59.911758 IP6 wantowen.link > baggie.link: ICMP6, neighbor solicitation, who has baggie.link, length 32
16:56:04.074817 IP6 loosened.link > wantowen.link: ICMP6, neighbor solicitation, who has wantowen.link, length 32
16:56:04.912787 IP6 baggie.link > wantowen.link: ICMP6, neighbor solicitation, who has wantowen.link, length 32
16:56:14.646033 IP6 waggie.link > wantowen.sanguine.emerson.baker.org: ICMP6, neighbor solicitation, who has wantowen.sanguine.emerson.baker.org, length 32
16:56:14.647737 IP6 dalliance.link > wantowen.sanguine.emerson.baker.org: ICMP6, neighbor solicitation, who has wantowen.sanguine.emerson.baker.org, length 32
16:56:14.648278 IP6 suffragette.link > wantowen.sanguine.emerson.baker.org: ICMP6, neighbor solicitation, who has wantowen.sanguine.emerson.baker.org, length 32
16:56:14.748757 IP6 frequented.link > wantowen.r1.t2.linode.emerson.baker.org: ICMP6, neighbor solicitation, who has wantowen.r1.t2.linode.emerson.baker.org, length 32
16:56:14.811537 IP6 baggie.link > loosened.ndp.link: ICMP6, neighbor solicitation, who has loosened.he.emerson.baker.org, length 32
16:56:19.590663 IP6 flying-pork.link > wantowen.sanguine.emerson.baker.org: ICMP6, neighbor solicitation, who has wantowen.sanguine.emerson.baker.org, length 32
16:56:19.655751 IP6 wantowen.link > dalliance.link: ICMP6, neighbor solicitation, who has dalliance.link, length 32
16:56:19.655771 IP6 wantowen.link > suffragette.link: ICMP6, neighbor solicitation, who has suffragette.link, length 32
16:56:21.645804 IP6 lovelie.link > wantowen.linode.emerson.baker.org: ICMP6, neighbor solicitation, who has wantowen.linode.emerson.baker.org, length 32
16:56:24.599803 IP6 wantowen.link > flying-pork.link: ICMP6, neighbor solicitation, who has flying-pork.link, length 32
16:56:24.663738 IP6 dalliance.link > wantowen.link: ICMP6, neighbor solicitation, who has wantowen.link, length 32
16:56:24.664269 IP6 suffragette.link > wantowen.link: ICMP6, neighbor solicitation, who has wantowen.link, length 32
16:56:26.396510 IP6 lovelie.he.emerson.baker.org > joubijou2.ndp.link: ICMP6, neighbor solicitation, who has joubijou2.he.emerson.baker.org, length 32
16:56:26.897687 IP6 lovelie.sonic.emerson.baker.org > joubijou2.ndp.link: ICMP6, neighbor solicitation, who has joubijou2.sonic.emerson.baker.org, length 32
16:56:29.606825 IP6 flying-pork.link > wantowen.link: ICMP6, neighbor solicitation, who has wantowen.link, length 32

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.

Answer

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)'

Result:

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

Also Relevant

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

Background

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

References

The IPv6 Chicken

The IPv6 Chicken

All this stuff is © 2010 Timmins Technologies, LLC; from his site. Herein is just recital of how it works.

If the image to the left loads fully, you have no Path MTU issues.
Your working IPv6 address is somewhere within $ADDRESS

ipv6chicken.com 208.83.69.51 2607:f4b8:2600:1:28a3:aeff:fedc:adda
www.ipv6chicken.com 208.83.69.51 2607:f4b8:2600:1:28a3:aeff:fedc:adda
ipv6.ipv6chicken.com (none) 2607:f4b8:2600:1:28a3:aeff:fedc:adda


transitional technologies

Via Backfill

IPv6 Source & Destination Address Selection: RFC 6724, RFC3484, addrlabel, gai.conf

References

Previously

Summarization

Source Address Rulescite

  1. Prefer same address.
  2. Prefer appropriate scope.
  3. Avoid deprecated addresses.
  4. Prefer home addresses.
  5. Prefer outgoing interface.
  6. Prefer matching label.
  7. Prefer privacy addresses.
  8. Use longest matching prefix.