Subject: draft-ipngwg-default-addr-select-00.txt

From: Richard Draves <[email-masked]>
Date: Fri, 22 Oct 1999 16:19:50 -0700

I submitted a new draft on address selection last night.

> It's available at
> ftp://ftp.research.microsoft.com/users/richdr/draft-ipngwg-default-addr-se
> lect-00.txt.
> 
The main changes from draft-draves-ipngwg-simple-srcaddr-01.txt are:

   Added framework discussion. 

   Added algorithm for destination address ordering. 

   Added mechanism to allow the specification of administrative policy 
   that can override the default behavior. 

   Changed the candidate set definition for source address selection, 
   so that only addresses assigned to the outgoing interface are 
   allowed. 

Unfortunately I won't be able to present it (at least not in person) at DC.
I would appreciate any comments here on the list.

Thanks,
Rich
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Robert Elz <[email-masked]>
Date: Sat, 23 Oct 1999 20:11:03 +1000

Date:        Fri, 22 Oct 1999 16:19:50 -0700
    From:        Richard Draves <[email-masked]>
    Message-ID:  <4D0A23B3F74DD111ACCD00805F31D81014515CD5@RED-MSG-50>

  |    Changed the candidate set definition for source address selection, 
  |    so that only addresses assigned to the outgoing interface are 
  |    allowed. 

I think this is a mistake.

Eg: consider a node with two interfaces A and B.   Allow A to have
a global address GA (and a local address LA though that won't be
relevant here).   Allow B to have just a local address LB (no global
prefix has been advertised on that link).   For the purposes of
this example it doesn't matter whether the local addresses are site
local, link local (or both).

Then consider a packet to be sent to the destination global address GD
(exactly one address is available, and it has global scope).

And then assume that the node has chosen to transmit the packet through
interface B (as assumed in section 5 of the draft, the outgoing interface
has been chosen already).   For the purposes of this example (just to
avoid the "why?" questions, assume that interface B is the only
interface containing a default route, and that no more specific route
can be used to reach GD).

The rule above (section 4.1 of the draft) allows only LB to appear in the
candidate set of course addresses, and given only one address in the
candidate set, that address must be chosen.   That means sending to a
global destination address (perhaps way over the other side of the
global internet) using a local source address, which is not going to
be condusive to working communications.

While selecting an address from the set on the outgoing interface ought
be done where possible, forcing selection of a useless source address,
when an adequate one would have been available, doesn't make a lot of
sense.

The equivalent for IPv4 would be to demand that the source address
selected be the address of the outgoing interface, only to discover
that you're sending through an unnumbered interface...   IPv6
doesn't really have unnumbered interfaces, but it does have ones that
have only local scope addresses.

kre

---

From: Alain Durand <[email-masked]>
Date: Fri, 29 Oct 1999 11:25:52 +0200

In the draft:
    table:

                 Prefix    Precedence Label MatchSrcLabel
                 fe80::/10     40       1         1
                 fec0::/10     30       2         2
                 ::/0          20       3         3
                 2002::/16     10       4         4
                 ::/96         10       5         5

    One effect of the default policy table is to prefer using native
    source addresses with native destination addresses, 6to4 source
    addresses with 6to4 destination addresses, and v4-compatible source
    addresses with v4-compatible destination addresses. Another effect
    of the default policy table is to prefer communication using native
    addresses to communication using either 6to4 or v4-compatible
    addresses, but not to express a preference for 6to4 addresses over
    v4-compatible addresses or vice-versa.

Why dont you want to express a preference for 6to4 addresses
over v4-compatible addresses ?

	- Alain.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 29 Oct 1999 11:32:51 -0500

Alain,

I think that is a local operational choice. Personally,
I would give 6to4 precedence, but I am prejudiced :-)

   Brian