Subject: RE: (ngtrans) I-D ACTION:draft-ietf-ngtrans-6to4-03.txt

From: Richard Draves <[email-masked]>
Date: Thu, 14 Oct 1999 14:07:36 -0700

More thoughts on letting administrators configure address selection...

One scenario that Alain raised is when longest-matching-prefix (LMP) does
the wrong thing. Can administrative configuration of some kind of precedence
be used to fix this?

Here's a scenario:

             ISP A                                   ISP B
  (prefixes 2004::/16, 2006::/16) ---------  (prefixes 2005::/16, 2007::/16)
              /                    \     /                         |
             /                      \   /                          |
          site 1                   site 2                        site 3
    (prefix 2006:1::/48) (prefixes 2004:2::/48, 2007:2::/48)  (prefix
2005:3::/48)
      node 2006:1::1          node 2004:2::2, 2007:2::2         node
2005:3::3

The ISPs are using two TLAs (ran out of room in their first TLA, or
mergers).

Site 2 communicates a lot with site 1 and site 3, the admins are very
motivated to optimize this communication. In fact this why site 2 is paying
to multihome.

Note that LMP does the wrong thing - for communication between site 1 and
site 2, comparing 2006:1::1 with 2004:2::2, 2007:2::2 it will pick
(2006:1::1, 2007:2::2). Similarly for communication between site 2 and site
3. Everyone is very upset.

So assuming this is worth trying to fix with address selection (instead of
the longer term proposals)... let's look at the precedence idea as a way of
fixing this.

Suppose site 3 configures its nodes to prefer destination addresses in the
prefixes 2005::/16 and 2007::/16. Then 2005:3::3 will pick destination
2007:2::2 over 2004:2::2. Good.

But in site 2 the problem is source address selection and it's more
difficult. Preferring 2007:2::2 over 2004:2::2 will work for communication
with 2005:3::3, but it's the wrong thing to do for communication with
2006:1::1.

Here's one possibility - let the administrator configure preferred source
prefixes (for source address selection) as well as precedences (for
destination address selection) and buckets (for both source & destination
address selection). So in this case, site 2 would configure something like

	2004:2::/48 -> bucket 0, precedence 0, prefer source addrs matching
2004:2::/48
	2007:2::/48 -> bucket 0, precedence 0, prefer source 2007:2::/48
	2004::/16   -> bucket 0, precedence 1, prefer source 2004:2::/48
	2006::/16   -> bucket 0, precedence 1, prefer source 2004:2::/48
	2005::/16   -> bucket 0, precedence 1, prefer source 2007:2::/48
	2007::/16   -> bucket 0, precedence 1, prefer source 2007:2::/48
	::/0        -> bucket 0, precedence 2, prefer source ::/0
	2002::/16   -> bucket 1, precedence 3, prefer source 2002::/16
	::/96       -> bucket 2, precedence 4, prefer source ::/96

This is quite flexible, of course it's also getting quite complicated...

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: Richard Draves <[email-masked]>
Date: Fri, 15 Oct 1999 15:42:27 -0700

> >So suppose the administrator can say "give first preference 
> to addresses in
> >my own site (prefix A/48), next to addresses from my ISP 
> (prefixes A/16 and
> >B/16), next to all other global native addresses, next to 
> 6to4, last to
> >v4-compatible".
> >
> >That sounds like a useful capability for the administrator.
> >Suppose the administrator tries to do this with your algorithm.
> >
> >Then a node with two source addresses, one from prefix A/48 
> and one 6to4,
> >initiates communication with another node with one 
> destination address from
> >prefix B/16.
> >
> >I believe that your algorithm will select the 6to4 source 
> address instead of
> >the A/48 source address - clearly the wrong thing.
> 
> I do not see why. With my algorithm, node A will have both an 
> global, non 6to4
> address within A/48 and a 6to4 one. node B will have only 
> global, non 6to4 
> addresses
> 
> My suggested algorithm will consider the pairs:
> (A/48:prec=30, B/48:prec=30)
> (A/6to4:prec=35, B/48:prec=30).
> There is only one pair of common precedence, that is:
> (A/48:prec=30, B/48:prec=30)
> The lowest numerical value of precedence LP is 30.
> The algorithm will then select the non 6to4 addresses as 
> source address for A.

Yes, if all global native addresses have the same precedence value of 30.

My point is that we have a system that lets administrators give precedences
to different sets of addresses (and it would be good thing to give
administrators that level of control), then administrator might want for
example to give A/48 precedence 25, give A/16 and B/16 precedence 28, and
all other global native addresses precedence 30.
 
> >Another situation - the source addresses are the same 
> (prefixes A/48 and
> >6to4), but there are two destination addresses (prefixes 
> B/16 and 6to4). In
> >this situation your algorithm will select the 6to4 source & 
> destination
> >addresses instead of the two native addresses.
> 
> Same thing, the algorithm will select global.

Again, I'm trying to accomodate policies that will give A/48 and B/16
different precedences. In that case, your algorithm will select the two 6to4
addresses instead of the two native addresses.

Rich