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

From: Richard Draves <[email-masked]>
Date: Wed, 13 Oct 1999 22:03:48 -0700

Ignore for a moment scoped addresses and deprecated addresses.

It seems that we want an algorithm that can take into account administrative
configuration of policy. These policies should classify addresses into
buckets. The buckets should have some precedence order. Then the source &
destination address selection should try to satisfy two goals: use
destination & source out of the same bucket, and use higher-precedence
addresses in preference to lower-precedence addresses.

If had this, then administrators could set up buckets for native global
addresses, 6to4 addresses, v4-compatible addresses and give them whatever
precedence they want.

Furthermore, it could solve another issue that Alain raised: what if one's
ISP has discontiguous prefixes - then longest-matching-prefix does not do
the right thing, and may in some situations do exactly the wrong thing. An
administrator could fix this by creating a  highest-precedence bucket using
the ISP's prefixes.

The obvious way to assign precedences to addresses is using a
longest-matching-prefix lookup table. So Keith's table would look like:
::/0 -> 0

Erik's table would look like:
::/0 -> 0
::/96 -> 1
2002::/16 -> 1

Alain's table would look like:
A1, A2 -> 0
B1, B2 -> 1
::/0 -> 2
2002::/16 -> 3
::/96 -> 4
where A1/A2 are Alain's site prefixes and B1/B2 are Alain's ISP's prefixes.
(And if Alain's ISP has an ISP, its prefixes could be yet another bucket.)

So given this setup, what should the destination and source address
selection algorithms be.

For ordering the destination addresses, you want to first use destination
addresses in buckets that also contain at least one source address, followed
by destination addresses in buckets that do not contain any source
addresses. The second-order sort criteria is to prefer addresses from
higher-precedence buckets over addresses from lower-precedence buckets. The
third-order sort criteria applies if the destination addresses' bucket
contains any source addresses: sort the destination addresses by longest
match with the source addresses in the same bucket. Finally all else being
equal leave the destination addresses in the DNS order.

Given a destination address, how do you select a source address? First you
want to use source addresses in the same bucket as the destination address,
preferred over source addresses from other buckets. If there are no source
addresses in the same bucket as the destination address, then prefer source
addresses from higher-precedence buckets over lower-precedence buckets. The
final criteria is to prefer source addresses with the longest match against
the destination address.

OK, now analyzing how this will work in different situations... it seems to
work for situations involving native vs 6to4 vs v4-compatible.

Here's a problem with the idea so far: consider a node in Alain's site with
native addresses from prefix A1 and A2 and a 6to4 address, sending to a node
in a different site served by the same ISP also using 6to4 - so the
destination addresses have prefixes B1, B2, 6to4.

Then the 6to4 source & destination addresses will get selected because
that's the only bucket that contains both a source and a destination
address.

So the original requirement of just a single level of precedence for buckets
isn't giving enough control in this situation.

To fix this would require using a level of precedence inside the main
buckets - so all native addresses could be grouped into one bucket but there
could be different precedence levels inside that bucket for matching against
the site, the ISP, the ISP's ISP, etc.

One might also want to put 6to4 and v4-compatible in the same bucket but
have 6to4 preferred over v4-compatible. Hmmm.

Rich

---

From: Alain Durand <[email-masked]>
Date: Thu, 14 Oct 1999 17:31:18 +0200

> addresses in preference to lower-precedence addresses.

Rich,

The sets of precedence in the updated algorithm I posted today
to select source & destination addresses should take care of
the buckets you suggest.
Those precedence have default values that can be administratively
changed.
One can always define some new levels which could correspond
to new buckets.

Is it not enough?
	
	- Alain.

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 14 Oct 1999 15:02:42 -0700 (PDT)

> configuration of policy. 

Rich,

I don't think we can punt on the problem by letting the user/admin
manually configure the policy.
(I can see it now: The IPv6 mobile phone asks me to configure address selecting
policy when I turn it on the first time. :-)

We must provide defaults which we believe will work reasonable well in 90%
of the cases (well, 99.99% of the cases for the billion mobile phones to
reduce the number of support calls) for this to be useful.

Having said that, I don't see a problem providing some policy hooks for
those who want something different.

   Erik

---

From: Jim Bound <[email-masked]>
Date: Thu, 14 Oct 1999 21:37:52 -0400

so because we cannot define or agree what the defaults we are to create a
configuration nightmare for each node using IPv6, because of transition.

This is not going to fly in the real market place folks.

We need to pick defaults and go with it, get 6to4 done and move on.

If a sales rep cannot explain Ipv6 transition in 3 slides we are
history.

/jim