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

From: Richard Draves <[email-masked]>
Date: Tue, 12 Oct 1999 11:58:25 -0700

I would like to get to a position where we can try different src/dst pairs
and switch among them. Erik's & Peter's presentions at the interim meeting
were promising.

But in the absence of such advanced mechanisms we need simple defaults. In
our framework of library-level destination address ordering and stack-level
source address selection, the questions are
a) what should be the default algorithm for destination address ordering. in
particular, should the algorithm have built-in knowledge of 6to4? I would
really like to avoid building in knowledge of more and more special
prefixes.

I propose that the default algorithm be to sort as follows:
link-local
site-local
global (this includes 6to4 and v4-compatible)

Within each bucket, look at possible source addresses and sort by longest
match with possible source addresses.

If there are ties, then preserve the DNS order.

Some consequences - if both ends have v4-compatible addresses then they
would be preferred.

If both ends have 6to4 addresses and native addresses, then the 6to4
addresses would often be preferred because they would share a TLA.

So this optimizes towards near-term performance considerations. Final
transition away from v4-compatible addresses or 6to4 addresses would happen
by default when sites stopped advertising those addresses in the DNS.

b) how to provide administrative configuration or override?

I would like to have some mechanism for override of the above destination
address order.

Here's one thought. Maybe something like a table of prefixes, with each
prefix mapping to a priority, longest-match lookup in the table to get a
priority for each possible destination address, then sort the destination
addresses into buckets by priority?

So the default table would be
fe80::/10 -> priority 1
fec0::/10 -> priority 2
::/0 -> priority 3

Then if an administrator of a site with both a 6to4 prefix and a native
prefix wants to discourage use of 6to4 destination addresses they would add
a rule
2002::/16 -> priority 4

Rich

> -----Original Message-----
> From: Keith Moore [mailto:[email-masked]]
> Sent: Tuesday, October 12, 1999 10:49 AM
> To: Erik Nordmark
> Cc: Brian E Carpenter; Richard Draves; [email-masked];
> Keith Moore
> Subject: Re: (ngtrans) I-D ACTION:draft-ietf-ngtrans-6to4-03.txt 
> 
> 
> I'm at a loss to understand why native v6 should implicitly 
> be preferred 
> over 6to4.
> 
> For the foreseeable  future, IPv6 will have a different 
> market than IPv4.
> Native v6 networks will be deployed first in those cases where IPv4
> has insufficient capabilities or address space.  We can expect IPv6
> deployment to be driven by demands from different markets  
> (e.g. China), 
> different kinds of hosts  (e.g. wireless), and different kinds of 
> applications (e.g. distributed apps that do not work well in 
> the presence 
> of NATs).   Because the market demands are different, we 
> should not assume
> that there will be significant overlap between the v4 and v6 network 
> topologies, and - because v4 and v6 traffic between two hosts 
> might take
> drastically different paths - this further implies that we 
> should not assume
> that a native v6 path is inherently preferable to a 6to4 path.
> 
> In general, if host A has Na interfaces and host B has Nb 
> interfaces, there
> are Na X Nb potential source and destination address 
> combinations from which
> an initiating host or application could select in an attempt 
> to establish
> communications between A and B.  Each of these address pairs 
> might have 
> associated with it a different reliability, different delays 
> in each direction,
> different amounts of jitter, different amounts of bandwidth.  
> The best 
> choice for one application might be seriously pessimal for another.
> The fact that some of these paths might use encapsulation while others
> of these paths might use native v6 doesn't change that.  And while if
> all other things were equal it would be better to avoid the 
> encapsulation
> overhead of 6to4, it's not reasonable to assume that this overhead is
> more significant than other factors which should affect 
> address selection.
> We certainly should not wire such assumptions into IPv6 
> implementations;
> lest a significant group of users experience a performance 
> penalty as reward
> for their having established native v6 connectivity.  (Note 
> also that what
> looks to a sending host like native v6 connectivity may still 
> be a tunnel
> of some sort besides 6to4, and it's not clear why a host 
> should prefer one
> kind of tunnel over another).
> 
> As for encouraging transition from 6to4 to native v6, encapsulation
> overhead alone serves to do this if and when the amount of v6 traffic
> becomes significant.  The only other necessary condition is for
> applications, hosts, and networks which support 6to4 to also be
> capable of supporting native v6 and using it when configured to do so.
> 
> To me, even the idea of a per-host flag which says "prefer native 
> over 6to4" strikes me as suspect - first, because it's a 
> maintenance hassle
> to have the knob at all; and second, because it seems like 
> the wrong kind 
> of knob (other factors are probably more important).  And to 
> the extent
> that you need such a knob, it seems like you want it to be tweaked on
> the LAN level rather than the host level.  (aside: I wonder 
> how feasible
> it would be for a LAN admin to tweak this knob by playing games with
> the prefix lengths of routing advertisements on the LAN)
> 
> But to me this just serves to illustrate that we really don't have the
> mechanisms in place that are needed to do effective address selection.
> It's not a 6to4 issue, it's a more general issue surrounding IPv6.
> 
> Keith
> 
>

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 13 Oct 1999 00:05:35 -0700 (PDT)

> match with possible source addresses.

I think we need an additional bucket which we can label as "transient"
(transition only) addresses which would include IPv4-compatible addresses
and 6to4 addresses. I'd suggest this bucket is last in the list.

That still has some warts: when a node has two source addresses 
	6to4 address (2002:) 
	native address (2fed:)
and it sending to 2001: the 6to4 address will have a longer common prefix
with the destination.
(The IPv4-compatible addresses don't have this issue since they are "far away"
from other addresses by virtue of being in 0::0/96.)

Thus *IF* we decide we want my suggested default order we could move the 6to4
addresses to also be "far away" from native addresses.
For instance, if 6to4 was using 00XX/16 (XX != 0) instead of 2002/16
we would get what I listed as the desired (default) behavior.

   Erik