1. Default Address Selection for IPv6
draft-ietf-ipngwg-default-addr-select-02
Richard Draves December 13, 2000
San Diego IETF Meeting

2. Source Address Selection and Destination Address Ordering
Minimal requirement for all implementations
Automatically pick “reasonable” source and destination addresses
Configuration/policy is possible
NOT just for multi-homing
Complement other multi-homing approaches
This is review, to remind people what we’re talking about.

3. Not Just for Multi-Homing
Consider a singly-homed IPv6 host…
Loopback, link-local, site-local addresses
Global address, temporary address
v4-compatible address, 6to4 address
Home address
IPv4 address
90% of the complexity due to considerations other than multi-homing.

4. What’s Changed?
Toned down requirement strength. Remaining MUSTs for inter-operability:
Candidate set: what is a legal source address?
Prefer appropriate scope when choosing source addresses.
Simplified default policy table.
Added more destination ordering rules.
Added examples.

5. Default Policy Table
Implementations SHOULD be configurable. If not configured, then they SHOULD operate according to the default policy table:
Prefix
Precedence
SrcLabel
DstLabel
::1/128 50
::/0 40 1
2002::/16 30 2
::/96 20 3
::ffff:0:0/96 10 4
So that it will fit, this table leaves out some rows dealing with scoped IPv4 addresses.
Explain Precedence (higher is better), Label, and MatchSrcLabel.
In a nutshell – Precedence specifies preference for one destination address over another.
Label & MatchSrcLabel specify a preferred source prefix for given destination prefix. An administrator can use the labels to override defaults and achieve better results in some multi-homing scenarios. …
IPv4 destinations are represented as v4-mapped addresses.

6. Source Address Selection Rules
Selecting IPv6 source for IPv6 destination:
Prefer same address (for loopback).
Prefer appropriate scope.
Avoid deprecated addresses.
Prefer home addresses over care-of addresses.
Prefer source assigned to originating interface.
Prefer matching label from policy table.
Prefer temporary addresses.
Use longest-matching-prefix.
The rules are tie-breakers, considered in order.
The mobility rule comes before the strong-model rule because some implementations might have home addresses assigned to a pseudo-interface or loopback interface or something other than the originating interface.
Rule 3 is a little more complicated than just looking at scope – preferred/deprecated is also considered in some situations.
As I mentioned before, I think there should be another rule saying use v4-mapped source for v4-mapped destination.
And I think the policy table override rule should be much lower in the list – I’d move it to just above the longest-matching-prefix rule.

7. Destination Address Ordering
First, select best source for each destination, IPv6 and IPv4:
Avoid unusable destinations.
Prefer matching scope.
Avoid deprecated source addresses.
Prefer home source addresses.
Prefer matching label from policy table.
Prefer destinations with higher precedence.
Prefer smaller scope destinations.
Use longest-matching-prefix.
Otherwise, leave order from DNS unchanged

8. Configuration Examples
Prefer IPv4 over IPv6
Prefer global destinations over link-local or site-local destinations.
Control address selection in multi-homed sites.

9. Remaining Issues
API (socket options?) for controlling mobility & privacy preferences:
Home vs care-of addresses
Temporary vs public addresses
Consolidate SrcLabel/DstLabel?
Last call?