Skip to main content

Appendix B. Changes since RFC 3484

Some changes were made to the default policy table that were deemed to be universally useful and cause no harm in every reasonable network environment. In doing so, care was taken to use the same preference and label values as in RFC 3484 whenever possible and for new rows to use label values less likely to collide with values that might already be in use in additional rows on some hosts. These changes are:

  1. Added the Teredo [RFC4380] prefix (2001::/32), with the preference and label values already widely used in popular implementations.

  2. Added a row for ULAs (fc00::/7) below native IPv6 since they are not globally reachable, as discussed in Section 10.6.

  3. Added a row for site-local addresses (fec0::/10) in order to depreference them, for consistency with the example in Section 10.3, since they are deprecated [RFC3879].

  4. Depreferenced 6to4 (2002::/32) below native IPv4 since 6to4 connectivity is less reliable today (and is expected to be phased out over time, rather than becoming more reliable). It remains above Teredo since 6to4 is more efficient in terms of connection establishment time, bandwidth, and server load.

  5. Depreferenced IPv4-Compatible addresses (::/96) since they are now deprecated [RFC4291] and not in common use.

  6. Added a row for 6bone testing addresses (3ffe::/16) in order to depreference them as they have also been phased out [RFC3701].

  7. Added optional ability for an implementation to add automatic rows to the table for site-specific ULA prefixes and site-specific native 6to4 prefixes.

Similarly, some changes were made to the rules, as follows:

  1. Changed the definition of CommonPrefixLen() to only compare bits up to the source address's prefix length. The previous definition used the entire source address, rather than only its prefix. As a result, when a source and destination addresses had the same prefix, common bits in the interface ID would previously result in overriding DNS load balancing [RFC1794] by forcing the destination address with the most bits in common to be always chosen. The updated definition allows DNS load balancing to continue to be used as a tie breaker.

  2. Added Rule 5.5 to allow choosing a source address from a prefix advertised by the chosen next-hop for a given destination. This allows better connectivity in the presence of BCP 38 [RFC2827] ingress filtering and egress filtering. Previously, RFC 3484 had issues with multiple egress networks reached via the same interface, as discussed in [RFC5220].

  3. Removed restriction against anycast addresses in the candidate set of source addresses, since the restriction against using IPv6 anycast addresses as source addresses was removed in Section 2.6 of RFC 4291 [RFC4291].

  4. Changed mapping of RFC 1918 [RFC1918] addresses to global scope in Section 3.2. Previously, they were mapped to site-local scope. However, experience has resulted in current implementations already using global scope instead. When they were mapped to site-local, Destination Address Selection Rule 2 (Prefer matching scope) would cause IPv6 to be preferred in scenarios such as that described in Section 10.7. The change to global scope allows configurability via the prefix policy table.

  5. Changed the default recommendation for Source Address Selection Rule 7 to prefer temporary addresses rather than public addresses, while providing an administrative override (in addition to the application-specific override that was already specified). This change was made because of the increasing importance of privacy considerations, as well as the fact that widely deployed implementations have preferred temporary addresses for many years without major application issues.

Finally, some editorial changes were made, including:

  1. Changed global IP addresses in examples to use ranges reserved for documentation.

  2. Added additional examples in Sections 10.6 and 10.7.

  3. Added Section 10.3.1 on "broken" IPv6.

  4. Updated references.

Last updated on