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

From: Richard Draves <[email-masked]>
Date: Wed, 6 Oct 1999 22:28:20 -0700

Some comments on the new draft...

First, it's noticeably improved: easier to read and understand.

In section 2.1:

   To ensure the correct operation of 6to4 in complex topologies, all
   IPv6 hosts MUST provide the following algorithm, or its equivalent,
   for address selection when sending IPv6 packets.  This algorithm
   SHOULD be enabled whenever a source host has at least one 2002::
   prefix assigned to it.

   If the set of IPv6 addresses returned by the DNS for the destination
   host contains at least one 2002:: address, then the source host MUST
   choose a 2002:: address for both the source and destination of the
   IPv6 packet.

Consider a transition scenario where two sites A and B both have 6to4
prefixes and native prefixes. For example A has 2001:: and 2002:: prefixes
and B has 2002:: and 2003:: prefixes. This seems to be saying that
communication between the two sites must use 6to4? I can imagine policy
reasons for preferring 6to4 or native communication in this circumstance.

(Alain brought up this scenario at the interim meeting.)

This also seems to contradict a comment in section 5.2:

   Sites which have at least one native IPv6 connection, in addition to
   a 6to4 connection, will therefore have at least one IPv6 prefix which
   is not a 2002:: prefix. Such sites' DNS entries will reflect this and
   DNS lookups will return multiple addresses.  If two such sites need
   to interoperate, whether the 6to4 route or the native route will be
   used depends on IPv6 address selection by the individual hosts (or
   even applications).

Another issue: I don't understand the "6to4 exterior routing domain".
Wouldn't the set of 6to4 routers using the relay router just have a default
route pointing to the relay router? This is how we're deploying 6to4.

Section 5.2.1 - in the long run, I would definitely expect native IPv6
providers to operate relay routers. Connectivity to the 6to4 world will be a
service their customers will want.

Section 5.2.2:

   A relay router participates in IPv6 unicast routing protocols on its
   native IPv6 interface and on its 6to4 pseudo-interface, but these are
   independent routing realms with separate policies (even if the same
   protocol, such as BGP4+, is used in both cases).

Again, I don't understand the reason for using routing protocols on the 6to4
pseudo-interface. We are not doing this in deployment.

   On its 6to4 IPv6 pseudo-interface, the relay router advertises
   whatever IPv6 native prefixes its local policy permits, from among
   those reachable through its native IPv6 interface. In the simplest
   case, a default route to the whole IPv6 address space could be
   advertised. It has been suggested that these routes could actually by
   advertised along with IPv4 routes using BGP4 over IPv4, rather than
   by running a separate BGP4+ session.

OK, the simplest case is what I have in mind. Why make it more complicated?

   In the event that BGP4 or BGP4+ is not available to it, a 6to4
   routerserved by the relay router will be configured with a default
   IPv6 route to the relay router (for example, Site A's default IPv6
   route would be 2002:09fe:fdfc::/48).

Wouldn't the default route be ::/0?

   Finally, given that there is no 6to4 router discovery protocol, a
   route will be configured in the relay router to each 6to4 router it
   serves (for example, the relay router shown above will be configured
   with a route to Site A, i.e. 2002:c001:0203::/48).  Note that
   configuring this route is the logical equivalent of configuring one
   end of a configured tunnel [RFC 1933], but it will be managed as part
   of a routing configuration.

   Clearly this requirement for explicit route configuration is an
   operational scaling issue, but one configuration action per user site
   is as little as can be reasonably expected. Additional mechanisms to
   automate such configuration are for further study.

I don't like having any explicit configuration in the relay for supporting
additional sites. In our current deployment, there's no 6to4 exterior
routing so we don't need any per-site configuration of the relay.

Rich

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 7 Oct 1999 14:34:06 -0700 (PDT)

> Yes, but note the concatenation of MUST, SHOULD and MUST - the SHOULD
> allows for a site to have a different algorithm in the case you
> describe. Maybe this should be spelled out.

What is the motivation for preferring 6to4 communication over native 
communication when both are available?

I'm concerned that we might get stuck with 6to4 forever and the "backbone"
will never support native IPv6.
Making the default policy be "prefer native IPv6 over 6to4 when both are 
available" would at least provide a mechanism for introducing native IPv6
over the "backbone". Without such a policy even if/when many sites have native
IPv6 prefixes (in addition to 6to4 prefixes) all the backbone traffic would
be 6to4.

   Erik

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 07 Oct 1999 04:34:44 -0500

> route pointing to the relay router? This is how we're deploying 6to4.

That certainly works, but there is no reason that they shouldn't
also be aware of explicit routes (they might even have a choice of
relay routers, depending on the native destination).

> service their customers will want.

Yes

> pseudo-interface. We are not doing this in deployment.

See above; it should say "may participate" in fact.
> OK, the simplest case is what I have in mind. Why make it more complicated?

As above - when multiple relay routers are available.

> Wouldn't the default route be ::/0?

Bad phrasing on my part. ::/0 will point to 2002:09fe:fdfc::/48

> routing so we don't need any per-site configuration of the relay.

Right, that's the simple case. I believe there will be more
complex cases too. This needs to be made explicit in the next
revision - it's a deployment choice.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 11 Oct 1999 03:52:59 -0500

Well, the SHOULD means that if you want to run the optional 6to4
protocol, you need to run an address selection algorithm
that picks the 6to4 mode in preference to native IPv6. But
I agree that the text needs to be clearer on exactly when
you should do so and when you shouldn't.

  Brian

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter (IAB Chair)
Program Director, Internet Standards & Technology, IBM Internet Div
On assignment for IBM at http://www.iCAIR.org 
Non-IBM email: [email-masked]

---

From: Alain Durand <[email-masked]>
Date: Mon, 11 Oct 1999 11:20:36 +0200

>you should do so and when you shouldn't.

Brian,

My understanding of the 6to4 mechanism is that it is a transition mechanism
to help in the early days of IPv6 when there is little if any native IPv6 
infrastructure.

In the long run, like any other transition mechanism, as IPv6 becomes 
widely available,
this mechanism will be phased out.
At that time, if the address selection algorithm says "prefer 6to4 over 
native IPv6",
we may have a problem.

This is the reason why I would rather like to have the opposite selection rule,
that is "prefer native IPv6 over 6to4 when both are available for src AND dst".

         - Alain.

---

From: Jim Bound <[email-masked]>
Date: Mon, 11 Oct 1999 12:15:10 -0400

Brian/Keith,

Quick logic check.

from: 5.2 Mixed scenario with relay to native IPv6

   3. A relay router MUST advertise a route to 2002::/16 into the native
  IPv6 exterior routing domain. It is a matter of routing policy how
   far this advertisement of 2002::/16 is propagated in the native IPv6
  routing system. Since there will in general be multiple relay routers
  advertising it, network operators will require to filter it in a
   managed way. Incorrect policy in this area will lead to potential
   unreachability or to perverse traffic patterns.

   A 6to4 site which also has a native IPv6 connection MUST NOT
   advertise its 2002::/48 prefix on that connection, and IPv6 network
   operators MUST filter out and discard any 2002:: prefix
   advertisements longer than /16.

NOTE The above specifically:

then: 5.2.2 Summary of relay router configuration

   On its native IPv6 interface, the relay router MUST advertise a route
  to 2002::/16. It MUST NOT advertise a longer 2002::  prefix on that
   interface. Routing policy within the native IPv6 routing realm
   determines the scope of that advertisement, thereby limiting the
   visibility of the relay router in that realm.

It may just be editing... But it appears maybe that in 5.2 it says MUST
NOT for native IPv6 interface, but then in 5.2.2 it says MUST advertise?

Which is it?  Or is there missing text?

p.s. more late reviewing the spec again but it looks 100% better......

thanks
/jim

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 11 Oct 1999 14:37:12 -0700 (PDT)

> you should do so and when you shouldn't.

I'm a little bit puzzled by your statement.
Clearly the source address selection algorithm in the IPv6 hosts
can't be affected whether or not the site has configured to "run the optional
6to4" (unless we add some remotely controlled policy knob to
IPv6 hosts).

I also don't understand why you think 6to4 requires that 6to4 addresses
be preferred over native IPv6 addresses.
Imagine 4 sites:
	A which has just 6to4 addresses
	B and C which has 6to4 addresses and native addresses
	D which has just native addresses

I think we'd agredd that when A and B communicate we want B to use its
6to4 address. And when B and D communicate we want B to use its native address.
 I'm arguing that when B and C communicate a resonable default policy for
source and dest address selection it to make them communicate using native
addresses (or try the native address first with 6to4 addresses as a second
choice.)
Your use of "SHOULD" seems to be saying that you'd prefer that they
use 6to4 addresses in this case, and I fail to understand why that
is desirable and/or required.

   Erik

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 12 Oct 1999 05:24:37 -0500

Jim,

Can't analyse this while on travel - I will hold it over until 
next week. Thanx

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 12 Oct 1999 05:22:40 -0500

Erik,

The reason we get into this discussion (and the same goes for
Alain's comment) is that my original proposal was *always* use
longest-match, which would select 6to4 unless there was a longer
match on a native address. Jim shot that one down in flames and I've
been looking for a configuration-free replacement.

The consequence of what you and Alain are saying is going to
be a host configuration option for "prefer 6to4" versus "prefer native"
in case that both are available. Do we really want another
config option? If yes, the words are easy to write.

  Brian

---

From: Jim Bound <[email-masked]>
Date: Tue, 12 Oct 1999 11:42:30 -0400

Hi Brian,

>been looking for a configuration-free replacement.

I did not kill the concept of "longest-match" and that was the initial
discussion.  But, in that initial discussion (which became src/dst
selection discussion later) my issue was the MUST of "longest-match"
because it implied a software algorithm to match src/dst and there are
other algorithms.  So all I wanted was a SHOULD or an EXAMPLE.  But then
we drifted into more of my concern and that was the src/dst algorithm to
select a src and dst pair.  But I think on the thread I started Richard
Draves and I parsed an answer and I gave into to the fact we need to do
this at times.  Richard I think presented this at the Interim meeting?

>config option? If yes, the words are easy to write.

It has to be a config option for sure.  The reason is even if 2002::/16
is the first prefix back from DNS later in 6to4 transition nodes will
want to start using the native connection for the reasons 6to4 states
in the spec or because IPv4 nets become disjoint to often later in
transition.

I haved resigned myself to the fact that we will require many knobs for
IPv6 transition and this is just another one.  

/jim

  Brian

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 12 Oct 1999 08:59:38 -0700 (PDT)

> config option? If yes, the words are easy to write.

I personally don't think we need to configuration option, but
others might think the order should be different.

My order is:
1. If both the source and destination have at least one native IPv6 address use
   IPv6 native source and destination. 2. If both the source and destination
have (at least one) 6to4 address use
   6to4 source and destination addresses.
3. If both the source and destination have (at least one) IPv4-compatible
   addresses (remember that automatic tunneling stuff) use
   IPv4-compatible source and destination addresses.

In the above "native" means addresses that are not 6to4, not IPv4-compatible,
and not IPv4-mapped.

And "use" really means "put those address pairs first in the list when doing
destination and source address selection" - it probably makes sense to
try the less preferred combinations if the more preferred ones do not work.

The above order of preferences have the benefit that they allow 6to4 to work
while ensuring that as native IPv6 communication with its native IPv6
addresses are added to the network, the traffic will move towards using
native IPv6 communication.

Swapping rule #1 and #2 would make it very hard, once there is significant
deployment of 6to4 addresses, to move communication to use native IPv6.

So does anybody have any issues with the above order?

   Erik

---

From: Jim Bound <[email-masked]>
Date: Tue, 12 Oct 1999 14:12:56 -0400

sounds good erik...if we can avoid knobs we should.......
/jim

---

From: Bob Fink <[email-masked]>
Date: Tue, 12 Oct 1999 11:51:49 -0700

Erik,

At 08:59 AM 10/12/99 -0700, Erik Nordmark wrote:
>   IPv6 native source and destination. 
>2. If both the source and destination have (at least one) 6to4 address use

I like the order. Question: what is the logic one uses to determine it is a
native IPv6 address. Is it strictly a test for the Aggregatable format
prefix and not the 6to4 TLA, or...?

Bob

---

From: Keith Moore <[email-masked]>
Date: Tue, 12 Oct 1999 13:48:54 -0400

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: Tue, 12 Oct 1999 14:18:28 -0700 (PDT)

> prefix and not the 6to4 TLA, or...?

With the current definition of the 6to4 addresses the check for native would be
	Not in 0::0/8 except 0::1
	Not in 2002::0/16

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 12 Oct 1999 15:42:05 -0700 (PDT)

> I'm at a loss to understand why native v6 should implicitly be preferred 

I think the short summary is that at the end we want native IPv6 communication
(since we don't think that there will be enough IPv4 addresses to run a
6to4 box in each site, etc, etc) and we need to make sure we can get from
here to there with as little pain as possible.

A big question in my mind is how 6to4 will be rolled out.
Is is clear to me that communication where both ends use 6to4 addresses
are easy to deploy and it fits with operational issues (e.g. ISPs settlements 
based on how the IPv4 traffic flows - since 6to4 is tunneled using IPv4
across the "backbone").
However, it is not clear to me who would be interested in deploying
6to4 relays (between 6to4 and native) as a production "service", in
particular since such boxes doesn't fit well with the ISPs business 
interactions.
In the deployment scenario where there are no deployed production
6to4 relays we have the issue of how to move from the 6to4 world to
an IPv6 native world.

In that scenario a site which wants to be globally reachable needs to have both
a 6to4 prefix and a native prefix. But there might be sites which do not care
about global reachability and only have one of the types of prefixes. With the
address selection order proposed in the 6to4 draft most  communication would
use 6to4 i.e. the packets would be tunneled over  the backbone even if there
is an IPv6 native path i.e. when both  endpoints have a native address in
addition to a 6to4 address. This means, not only that communication would
potentially be less efficient,  but that we will delay detecting any problems
with the native "backbone"  routing until a site removes its 6to4 addresses
from the DNS. It is  preferrable to start using the native addresses and
native "backbone"  IPv6 routing when the native addresses are introduced in
the DNS so that we detect failures/misconfiguration earlier rather than when
we  really have no choice but use IPv6 native communication.

> 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.

Agreed.
What we are talking about here is the *default* address selection policy
i.e. when there is no application or other advise to prefer certain addresses.

Are you concerned about the default or the ability for applications
(or local configuration) being able to override the default?

> capable of supporting native v6 and using it when configured to do so.

What do you mean by "when configured to do so"?
Are you implying a per-host knob or something else?

My point is that if we have a carefully crafted default policy we would
simplify the move to native IPv6.

> the prefix lengths of routing advertisements on the LAN)

I agree that less knobs is better. And if we need knobs they should only
be for the infrequent cases.

BTW: As far as I know nobody has proposed any interaction between
routing advertisements and address selection.

> It's not a 6to4 issue, it's a more general issue surrounding IPv6.

We clearly need to specify IPv6 address selection.
But if we agree that 6to4 addresses (just like IPv4-compatible addresses
used with auto tunneling) are "special" we have to decide to what extent
we need to do something special with those addresses in the *default*
address selection specification.

   Erik

---

From: Jim Bound <[email-masked]>
Date: Wed, 13 Oct 1999 08:55:34 -0400

Keith,

As far as addr selection, we are working on that now.  We can do it
either way based on the discussion at hand and the outcome.  So I don't
think the actual src addr selection is the issue.  

The issue for 6to4 is which is the preference given both 6to4 and native
IPv6.

Again why not let this be something the user decides when he/she installs or
reinstalls or updates the TCP/IP implementation on the host.  We will do
this for IPsec and do it today for several product features as host
vendors.

I think we just simply disagree on this config being on a
LAN or WAN level.  I think all this intelligence regarding IPv6
Transition must be in the "end-node" not on the network anywhere.
I would suggest we as a WG would not complete that debate and we would
stalemate as a group on that discussion, so I suggest we not go there?

Let me give you a scenario where IPv6 native will in fact be the
preference.  

A customer has deployed IPv6 for their Intranet and all of their core
applications for their business have been ported to IPv6 and take
advantage of all the IPv6 new features not in IPv4.  But, at times the
customers Intranet is connected over the Internet for some type of
processing need between two Intranet sites.  Most of the traffic 
the traffic is Intranet packets, and the path over the Internet btw 
Intranets is lets say only 25%,  

So what do we do now?  Erik's suggestion will force that native IPv6 is
tried to reach the Intranet across the Internet but that will fail.
Here is why?

  Company = Zig Zag Papers Inc:

  Zig Zags IPv6 Prefix is singly homed with 9ABF::/16

  Zig Zags Site A has NLA of CBDE and Site B NLA is AFDE 

  Zig Zag only has a 6to4 IPv6 connection between sites and no
  IPv6 native Internet connections.

Now a node in Site A [email-masked] 9ABF::CBDE::0045

Wants to send a cross the Intranet packet to:

              Site B [email-masked] 9ABF::AFDE::0026

But when rollone does getipnodebyname for smokeone it gets back two
A6 records:

          9ABF::AFDE::026  and 2002::AFDE::026

With Erik's suggestion yesterday rollone will send to 9ABF prefix.

But that packet will go up in smoke trying to reach smokeone and send
ICMPv6 dst unreachable to rollone, as there is no Internet IPv6 native
connection.  Then rollone will resend the packet using 2002 prefix and
it will work.

I think this is correct the behavior in this scenario as 2002 prefix is
only 25% of the traffic.

By setting the default to use IPv6 native addresses we are saying that
we prefer use of IPv6 over a transition mechanism.  That is a good
thing for us to do IMO.  

/jim

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 13 Oct 1999 15:54:46 -0700 (PDT)

>   IPv6 native Internet connections.

If that is the case from where did Zig Zag get their native prefix? (9ABF::/16)
This would normally come from their IPv6 provider. If they have an IPv6
provider then they have native IPv6 communication.

What am I missing?

   Erik

---

From: Keith Moore <[email-masked]>
Date: Wed, 13 Oct 1999 16:09:13 -0400

> here to there with as little pain as possible.

understood, but I don't think that it necessarily follows that a host should
use native v6 in preference to 6to4 when both are available.

> particular since such boxes doesn't fit well with the ISPs business 

my best guess is that since 6to4 has a much lower barrier to deployment,
much of the early v6 deployment will use 6to4.  native v6 access will
only be used, initially, by emerging and large portions of the Internet
that cannot get enough address space, or for private nets that are tired
of fighting the problems associated with private address space, NATs, 
and VPNs.  since the vast majority of v6 users in the near term will
be using 6to4, native v6 ISPs will need to provide routing to 6to4
sites as part of that service.  given that they will need to provide
NAT-PT with ALGs anyway, adding 6to4 relay service to that mix is not 
a significant additional burden.  however, it's not clear to me what
would induce  v4-only ISPs to provide a service which routes packets
from 6to4 to native v6.  my guess is that v4-only customers that needed
access to the v6 world would, in the near term, have to purchase that 
connectivity separately  - either by paying their current ISP more money 
enable v6 on the existing link, or by setting up a tunnel to a 
different ISP.  if and when there were sufficient customer demand for
v6, it might become a bundeled service.  and when v4 addresses become
scarce enough, some ISPs might offer v6-only access at a reduced price.

> 6to4 relays we have the issue of how to move from the 6to4 world to

my view is that if and when there is a significant native IPv6 constituency
(i.e. there is a sufficient number of valuable services available to 
you only if you can exchange v6 packets with the native v6 world)
then there will be a demand for 6to4 relay router services, and that ISPs
will provide them - though perhaps for extra cost - as part of some
kind of v6 service offering.  

> from the DNS. 

the communications would potentially be less or more efficient, but 
it is probably not appropriate to assume one or the other.
I agree that it's difficult to detect problems with the less-frequently
used path, but this is true of *any* multi-path routing scenario -
not just one that involves a choice between native v6 and 6to4.

> It is  preferrable to start using the native addresses and

not clear.   certainly you want to be able to test each path separately,
but making a blind choice on behalf of IPv6 users that native access 
is preferred over 6to4 access violates the principle of least surprise.  
if the native access performs worse than 6to4 access (as seems likely 
to happen much, perhaps most, of the time for new/experimental links) 
this becomes a disincentive to install native v6 access - if you install 
native v6 and the net slows down, the problem gets blamed on IPv6.  
either that or when you install native v6, you are forced to buy at least
as fast a pipe for v6 as you were using for v4 (and hence 6to4).  this is 
a different kind of disincentive for deploying native v6 - it raises 
the barrier to entry because you cannot start by buying a small amount
of connectivity.

> (or local configuration) being able to override the default?

I'm concerned that the default will often be so pessimal, that
"dumb" applications (those which cannot find the best address pair)
will behave worse when native v6 is enabled.  In order to be 
effective, then, v6 applications will have to become smart.  this 
raises the barrier to deployment of v6 applications.

> Are you implying a per-host knob or something else?

here I'm just trying to say that any host or application or router
that supports 6to4 also needs support for native v6 - we want to
make sure there is a transition path to native v6.  but if the host,
applicaiton, or router isn't connected to the global v6 network
then the native v6 stuff needs to be disabled.

> simplify the move to native IPv6.

to me it is not clear that we can create such a policy without 
either (a) adding a lot more machinery so that address selection 
can work better over the vast majority of cases or (b) overly 
constraining how v6 is deployed

> We clearly need to specify IPv6 address selection.

(then we can see whether it will actually work well!)

> address selection specification.

I guess I wonder why 6to4 addresses are any more "special" than 
any of the various other hacks, or (as I said above) whether we 
can develop a sane policy that does the right thing the vast
majority of the time without overconstraining v6 deployment.

Keith

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 13 Oct 1999 16:59:47 -0700 (PDT)

> it is probably not appropriate to assume one or the other.

Well, in the 6to4 case we know for sure there will be encapsulation, right?
Whereas in the native case there may or may not be encapsulation.
Sure, the 6to4 and native paths might be very different - with either
being better.
So I think on average we can argue that 6to4 is likely to be slightly worse.
But that isn't the main point.

> not just one that involves a choice between native v6 and 6to4.

Sure. But the question is how to move the net to native IPv6.
If the default is to prefer 6to4 I'm very concerned that we will never ever
get significant deployment of native IPv6.

The reasons for this are:
 - The easy knob to control the traffic is what is put in the DNS (A records
   vs. AAAA/A6 and what type of IPv6 address).
 - If you assume that 6to4 will be deployed more rapidly than native IPv6
   this means that most IPv6 nodes will have 6to4 addresses in the DNS.
 - With the default being "prefer 6to4 over native" it is very difficult for
   a site to try to switch using native communication; putting a native IPv6
   address (in addition to the 6to4 address) in the DNS doesn't change anything
   since the peers will prefer the 6to4 address.
   So unless you can convince all your peers to change their address selection
   policy the bulk of the traffic will continue using 6to4.
   The only way you can switch is to remove your 6to4 addresses from the DNS,
   which might affect the ability to communicate with 6to4 only sites.

This is analogous to the discussions we had many years ago about
getipnodebyname (in RFC 2553) returning IPv6 addresses before any IPv4-mapped
addresses. The choice was to put the IPv6 addresses first in the returned
list of addresses since otherwise all communication would use IPv4 (since
almost all nodes will have A records for a long time) and we wouldn't even
know if IPv6 works.
Thus a ported application which calls the recommended
      hptr = getipnodebyname(name, AF_INET6, AI_DEFAULT, &error_num);
will prefer IPv6 over IPv4 if the "name" has AAAA/A6 records as well as A
records in the DNS.

> is preferred over 6to4 access violates the principle of least surprise.

I fail to undetstand why you think there will be more surprised
by preferring native over 6to4 than the other way around.
If this is just based on your anticipated performance difference
I guess we have a agree that we disagree. I think the performance
argument could be argued either way and is completely dwarfed by the issue
of eventually migrating the whole net to native IPv6.

> native v6 and the net slows down, the problem gets blamed on IPv6.  

Same applies the other way around: if you use native and install 6to4 
and things get slower the problem gets blamed on IPv6.

> the barrier to entry because you cannot start by buying a small amount

You lost me.
Whether or not native IPv6 has additional cost doesn't matter.
Or if it does matter it is more a question of:
	I installed a native IPv6 link (in addition to 6to4) and put native
	addresses in the DNS but all IPv6 peers continue using 6to4 to talk
	to my site. The native link has almost zero utilization so I might
	as well disconnect it!
 
How do you proposing fixing that issue while the default policy is to
prefer 6to4 addresses over native addresses.

> majority of the time without overconstraining v6 deployment.

They are no more "special" than e.g. IPv4-compatible addresses.
Both 6to4 and compatible addresses are "special" since we have to make sure
they are not dead-ends that we can't move away from in a reasonable manner.
They must be viewed as a means to get to IPv6 native communication otherwise
we have a problem.

   Erik

---

From: Keith Moore <[email-masked]>
Date: Thu, 14 Oct 1999 00:23:18 -0400

> So I think on average we can argue that 6to4 is likely to be slightly worse.

with line speeds and delays varying by something like 8-9 orders of 
magnitude (and variation likely to increase in the future due to
gigbit and faster networking on one end and various flavors of
wireless on the other), we could also argue at least as convincingly 
that any encapsulation overhead will get lost in the noise.  

> get significant deployment of native IPv6.

okay.  let me first say that I defintely don't want to see us end up in 
a dead end where we have no good path by which the net can migrate from 6to4 
to native v6.  and this almost certainly implies that, assuming 6to4 is
accepted and deployed, that the net needs to be able to support a mixture
of native and 6to4, with large numbers of each, for many years.  
let me also say that I'm not committed to 6to4, precisely because of
the potential for 6to4 to further fragment the network into v4,
native v6, and 6to4 portions.  I think it's an interesting idea, 
and well worth examining, because it appears to remove a fairly huge
and immediate barrier to v6 deployment (the chicken-and-egg problem)
and replaces it with an apparently less burdensome and much more distant
problem (that of migrating from 6to4 to native v6).  and in the meantime
it facilitates deployment of v6 hosts and development of v6 applications.

in other words, not all dead ends are equal.  I'm much more worried about
the dead-end potential of NAT-PT than I am about 6to4, because if NAT-PT 
becomes the default way of doing IPv6  (i.e. if most v6 connections between
sites go through two NAT-PT boxes) we will end up with an IPv6 network 
which is more dysfunctional than a NATted IPv4 network.

the reason I'm pressing on the address selection issue is not  
because I'm trying to get 6to4 accepted.  the reason is that I'm 
convinced that any attempt to use address selection as a replacement 
for routing is broken, and that doing so will seriously impair the 
reliability and the efficiency of the v6 network. this amounts to a 
huge dead end, because people won't use v6 over v4 unless v6 works
at least approximately as efficiently/reliably as v4.
the 6to4 vs native case just illustrates this problem.

both the "DNS order" heuristic and the "longest prefix match"
heuristic seem as likely to do the wrong thing as the right one.
if I were to pick any heuristic at all I would try the various
addresss in order of the available bandwidth of the corresponding 
outgoing link - fastest to slowest - on the theory that a fast 
link would be able to return ICMP unreachable messages more quickly 
and allow me to more quickly fail over to other links.

>    vs. AAAA/A6 and what type of IPv6 address).

yes, this is an easy-to-control knob, but in how many cases is it likely
to do what is needed?  sure, if a server site has an OC-12 v6 connection and
a T-1 v4 connection, it wants to say "prefer native v6", but how realistic
is this?  for cases where the inbound native v6 bandwidth is approximately
equal to the inbound v4 bandwidth, what matters isn't the server's preference
so much as the characteristics of each end-to-end path, and path 
characteristics cannot be reliably obtained via DNS.  

>    address (in addition to the 6to4 address) in the DNS doesn't change 
>    anything since the peers will prefer the 6to4 address.

but servers won't want to do this for a production environment anyway
unless the v6 link is likely to provide at least similar performance
(for the vast majority of clients) than v4.  and *this* isn't likely 
until there is a fairly extensive native v6 network.

>    which might affect the ability to communicate with 6to4 only sites.

I'm starting to think that we cannot afford to legitimize the notion of
sites which can only communicate with other 6to4 sites, because that
leads to a dead-end.  clearly it is desirable to have sites be able to 
migrate to IPv6 independently of their ISPs, but they need to be able
to communicate with the entire v6 network (modulo administrative controls).

> will prefer IPv6 over IPv4 if the "name" has AAAA/A6 records as well as A

yes, that suffices to exercise IPv6 functionality, but if it results in
choosing a pessimal path, people will blame the slower response on IPv6.

> of eventually migrating the whole net to native IPv6.

indeed, it *can* be argued either way.

my point is that *if* significant performance differences exist
between v4 and v6 (which seems likely if you assume that the market 
for v6 connectivity will be different than that for v4) then 
*any* automatic preference (of 6to4 over native or vice versa) will
cause users to complain when a v6 link is added, unless the selection
algorithm results in better performance for alomst everyone - 
a tall order.  note that a greater variation in performance may result 
in diminished satisfaction overall even when there are as many 
users whose performance improves as those whose performance degrades.

> and things get slower the problem gets blamed on IPv6.

agreed. I'm assuming it's unlikely to start with native and then add 6to4 later.

> prefer 6to4 addresses over native addresses.

I am not sure that it can be fixed by juggling an address selection policy
which is based solely on DNS order and prefix match length. 

I'd rather fix it by either (a) making it likely that 6to4 sites can 
communicate effectively with native v6 sites from day one (this eliminating 
the need for a service to advertise both 6to4 and native addresses,
and reducing the negative consequences for sites that do - because the
choice won't matter so much) or (b) providing some other way for 
v4 sites to efficiently connect to the v6 network independently
of their ISPs (no, I don't think tunnel broker is good enough)

If we can't come up with either (a) or (b) then my fallback
position would be that the address selection policy be site
configurable, probably by some kind of run-time mechanism,
rather than something which is wired into host code or which
has to be tweaked on every host when a change is necessary
(e.g. I suppose local resolvers could reorder DNS responses 
based on current local preferences)

> They must be viewed as a means to get to IPv6 native communication otherwise

I am fully in agreement with this; I think we're just concerned about 
different dead-end cases.

Keith

---

From: Alain Durand <[email-masked]>
Date: Wed, 13 Oct 1999 15:39:43 +0200

I'm copying this to IPng mailling list.

>In the above "native" means addresses that are not 6to4, not IPv4-compatible,

I think we can generalized this order with the following algorithm to select
both source and destination address.

Lets define the precedence prec of an address as the following function
         prec(link local) = 10
         prec(site local) = 20
         prec(native-v6 global, non 6to4) = 30
         prec(native-V6 global, 6to4) = 35
         prec(IPv4 compatible) = 50

Note: those are suggested default value. They can be override manually
by configuration options if one does not like this specific order.

0. Consider the set of all possible source addresses
     and the set of all possible destination addresses,

1. Select destination address dst with the lowest precedence prec(dst)

2. If several destination addresses are still available, one may pick
     the first one returned by the DNS or use random selection.

3. Select src in this order:
         - one with the same precedence as prec(dst)
         - if impossible, one with the lowest precedence
           and prec(src) > prec(dst)
         - if impossible, one with the highest precedence

4. If several source addresses are still available, longest prefix match
   with the selected destination address or random selection may be used.

5. If the communication failed because the destination address
     is unreachable (scope too small for example), remove dst from
     the set of possible destination addresses and reiterate at step 1.

In the case of a simple application that select the first address returned by
the DNS and let the kernel fix the source address, step 3 & 4 of this algorithm
can be used by the kernel.

         - Alain.

---

From: Jim Bound <[email-masked]>
Date: Thu, 14 Oct 1999 12:38:11 -0400

Hi Erik,

>provider then they have native IPv6 communication.

Good point.  Maybe my assumption is wrong.  Let me try to explain.

Its my impression that many customers will want to begin using IPv6 on
their INtranets long before IPv6 can be routed natively across the
Internet.  My assumption above is that Zig Zag was given an IPv6 prefix
by ISP EZWIDER, but EZWIDER gave it to them on the condition that they could
not route IPv6 globally for Zig Zag at this time but would provide a
6to4 mechanism at their site, or Zig Zag could set up 6to4 to route to
other parts of Zig Zag.

What Zig Zag is doing is using IPv6 for their whole manufacturing
operation in different locations and their prefix is 9ABF::/16?

I guess I am not clear on what the rules are for the providers maybe?

/jim

---

From: Bill Manning <[email-masked]>
Date: Thu, 14 Oct 1999 09:53:07 -0700 (PDT)

> I guess I am not clear on what the rules are for the providers maybe?

This prefix has been hijacked and in the cause of sanity/stability
should be suppressed.

--bill

---

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

> which is more dysfunctional than a NATted IPv4 network.

Just as an aside: I don't know of anybody that thinks NAT-PT will be used
when two IPv6 nodes communicate. The intent is to use it only when IPv6-only
and IPv4-only nodes communicate.
Thus NAT-PT will only be a dead-end is only subsets of the sites
move to IPv6. To the extent we believe there will be address eaters 
(cell phones, large growth in areas like China, and/or multiparty applications)
that greatly benefit from the IPv6 address space I think over time large
portions of the network will see significant benefits in IPv6. But that
argument does not necessarily apply to the "backbone".

> the 6to4 vs native case just illustrates this problem.

Sure, address selection is different than routing.
But it is very much like multihoming: when the peer has IPv4 addresses,
native IPv6 addresses, 6to4 addresses, and perhaps even compatible addresses,
the host needs to choose an order. (The "network" can't choose an order
with today's mechanism since the DNS only provides an (unordered) set of
addresses.)

> and allow me to more quickly fail over to other links.

But you need the bandwith of the *path* for this to make reasoanble choices.
If I have a 10Mbps Ethernet with happens to go theough a 64k remote
Ethernet bridge, and 1Mbps DSL, the slower interface would be the preferred.
Thus it is as likely to do the wrong thing as the right thing.
No different than the other tools.

And if you took the time to actually try to measure the path characteristics
you'd loose for all but the very longest connections.

BTW: There has been discussions in the context of IPv6 multihoming
in making TCP be able to open connections in parallel (send a few SYNs using 
different source,dest address pairs and see which response comes back first.)
I think it would be useful to continue to explore that since it might be
able to find better paths on average, and also provide quicker detection when
a path is not working during the connection setup.

> characteristics cannot be reliably obtained via DNS.  

Yes, but I'm arguing that unless you actually try to measure the path 
characteristics you can't do much better than just picking a default
policy that at least gives the server site admin a knob where things can
be controlled. The only such knob we have today is what addresses are placed in
the DNS.

> until there is a fairly extensive native v6 network.

The bandwith of the IPv6 and IPv4 links (assuming they are in fact different
physical links which might not be the case) doesn't have to be indentical - it
has to be in relation to the amount of traffic the links are expected to
handle. So if only 1% of the clients use IPv6 then the IPv6 link only needs
1% os the bw of the IPv4 link.

> to communicate with the entire v6 network (modulo administrative controls).

I agree completely. But I'm concerned that 6to4 (due to the extra burden
of the relay routers) might not accomplish this. But that is a different
topic than the default address selection policy where this discussion started.

> choosing a pessimal path, people will blame the slower response on IPv6.

Sure, but they have the ability to control it. Remove the IPv6 addresses from
the DNS. I don't see how we can do any better.

> users whose performance improves as those whose performance degrades.

So are you arguing that we should not define a default policy but instead
define a dynamic path selection protocol?
While a path selection protocol would be nice I think we need a default
policy that allows admins to control (using the DNS content) the movement
from 6to4 to native IPv6.

> of their ISPs (no, I don't think tunnel broker is good enough)

I think (a) is hard since it depends on the separate relay routers
which may or may not be deployed as a production service.
What fallback do we have should they not be deployed?

[I agree that the tunnel broker is fine for experimentation with IPv6
but unlikely to be used for production service.]
I thought somebody in the Utrecht IAB workshop mentioned "use BGP over IPv4"
as a possibility for (b).
I think the idea might be (and I know very little about BGP)
to add a BGP attribute which specify IPv6 routers that will accept tunnels.
The ttribute is sujected to policy as they are transmitted between BGP
speakers. And the receiver of the attributes can they use some yet to be
specified  protocol for establishing a tunnel to at least one of the available
IPv6 routers (using whatever metrics BGP provides as a guide in the
selection process).

> based on current local preferences)

Problem 1: We don't have a site configuration mechanism available.
I guess router renumbering could conceivable be used together with
extensions to neighbor discovery.

Problem 2: What is the default when the site configuration mechanism
doesn't supply any information? (I think we still need to pick a default.)

> different dead-end cases.

I must have missed which dead-end case you are concerned about.
The way I read it you seem to be concerned about a negative reaction
against IPv6 when adding new addresses to the DNS causes a performance
degradation. Is that what you mean by dead-end or am I just not getting it?

   Erik

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 14 Oct 1999 13:35:02 -0500

I've just looked through this whole sub-thread again (while sitting
on a train from Zurich to Geneva) and I think that for the next
rev of the document, it will have to become a config option
as Jim suggested. I can't see any other formula that meets all 
the constraints that people have expressed.

  Brian

---

From: Jim Bound <[email-masked]>
Date: Fri, 15 Oct 1999 08:25:09 -0400

>the constraints that people have expressed.

That is kinda of where I got last night reviewing everything.  If we
start having to do all this stuff it stifled me from an implementation
view point.  I think we all need to build 6to4 now and ship it real
soon.  If we do all this list has been discussing it will take awhile to
just get the host stuff for addr selection updated.  So a config is
expedient and will work.  

/jim

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 15 Oct 1999 09:05:55 -0700 (PDT)

> the constraints that people have expressed.

And what will the default be in the absense of any configuration?

I know I'm sounding like a broken record ...

   Erik

---

From: Keith Moore <[email-masked]>
Date: Fri, 15 Oct 1999 12:39:39 -0400

> And what will the default be in the absense of any configuration?

what is the default for IPv4 hosts and applications when presented
with multiple IPv4 addresses?  

a. some try the first one, then the second, etc.
b. some randomize the list first
c. a few try the first one and give up if that fails
c. a very few of them try to be more clever about picking the order

in practice in the IPv4 world, if you advertise multiple IPv4 addresses
in DNS, you'd better make sure that they all have a high probability
of working for most of your users.

I've yet to see anything that makes me believe that the situation will
be any different in the IPv6 world.  

Keith

---

From: Keith Moore <[email-masked]>
Date: Fri, 15 Oct 1999 13:28:41 -0400

> I think we all need to build 6to4 now and ship it real
> soon.  

I agree that implementation experience would be useful, but 
I see a significant risk in shipping products that do not provide
a path to universal v6 connectivity.  e.g.

- if people ship NAT-PT boxes now, v6 applications behind different
NAT-PT boxes will be able to exchange packets, but they will be subject to
all of the limitations of the NATted world.

- if people ship 6to4 boxes now, hosts behind those boxes may
not be able to communicate with hosts in the native v6 world.

Keith

---

From: Keith Moore <[email-masked]>
Date: Fri, 15 Oct 1999 14:56:08 -0400

> and IPv4-only nodes communicate.

yes, that's the intent.  my concern is about an unintended consequence.

> move to IPv6.

I disagree.  

It's really difficult to imagine that all ISPs will uniformly move to
v6 within 2-4 years' time; the bulk of the information that I've received
says that fast routers either don't support v6 or that their v6 code isn't
up to production quality, and the router vendors can barely keep their
v4 codebase up.  So I have to assume that for several years the core
of the net will be IPv4 only, and that v6 is only supported at the
periphery and by a few emerging nets that really need v6 capability.
Lots of folks that are using v6 will thus be using 6to4 and NAT-PT.

If there is a native or 6to4 path between two hosts, applications
will work fine, but if two v6 nodes attempt to communicate across 
NAT-PTs, they end up with a NATted network.  applications written
assuming a non NATted network will fail.  thus until essentially 
everyone has native v6 connectivity, (i.e. a great many years) 
applications writers will be prevented from using most of the features
that makes v6 attractive over v4.

> the host needs to choose an order.

I'm not convinced that this kind of multihoming will work either,
and to me it's scary that we seem to be betting the farm on this approach.

> But you need the bandwith of the *path* for this to make reasoanble choices.

agreed.  this is just the best heuristic I could come up with that
only used local information.  in reality, this is a routing problem, 
and what it needs is a routing protocol.

> you'd loose for all but the very longest connections.

right.

> be controlled. The only such knob we have today is what addresses are placed
> in the DNS.

What you seem to be saying is:

1. we've got a difficult routing problem to solve - we're trying to 
   make intelligent choices about which of several (source, address)
   pairs to use, which are likely to imply paths with wildly varying 
   characteristics, in the absence of any information about the 
   characteristics of those paths.

2. since we don't have any good way to solve this problem, we need
   to have a default address selection rule.

I'm not sure I can argue with the need for a default address-selection
rule - consistency between hosts' handling of this is probably 
a good thing.  But we shouldn't pretend that any combination of 
a default address-selection rule and server-side DNS ordering is 
going to solve the multihoming problem.  Routing is difficult enough when
you actually have information about the path characteristics to inform
the decision.  Limiting the amount of information available makes the 
problem easier, but it doesn't improve the results.

So we're back to a situation where if you advertise multiple addresses
for your service and you don't provide global connectivity and adequate
bandwidth for *each* of those addresses, you're toast.  Might as well
admit that that's the case and live with it.

> 1% os the bw of the IPv4 link.

right.  I should have said "available bandwidth".  max bandwidth does matter
if a single connection can eat up much of the available bandwidth on that link.

> of the relay routers) might not accomplish this. 

And for what it's worth, I share your concern.

> But that is a different

well, the address selection policy was trying to make a special case of
6to4, when clearly this case is in the margins.  but if we assume that
a site basically doesn't advertise multiple v6 addresses at all unless
it provides reliable, global connectivity with adequate bandwith for 
each of those addresses, then there's less burden on the address selection
policy.  in this case I agree with you that you might want to favor
native v6 address matches over 6to4 address matches.

it's only because people seem to think that we can do effective multihoming
using address selection that this is even an issue.

Keith

---

From: Erik Nordmark <[email-masked]>
Date: Sun, 17 Oct 1999 22:11:47 -0700 (PDT)

> yes, that's the intent.  my concern is about an unintended consequence.

I get it know and I agree with your concern. Thanks.

>    to have a default address selection rule.

Not quite :-)
Even if/when we have a good way to solve this (based on historic information
gathered from TCP? hops?) we'd still need a default selection rule
since there are likely to be cases when you have no history, or hops 
is to expensive for a short connection?

> using address selection that this is even an issue.

Sure.
Unfortunately all we have today is a hammer.
We need more tools for host based path selection.

  Erik

---

From: Keith Moore <[email-masked]>
Date: Mon, 18 Oct 1999 09:01:16 -0400

> We need more tools for host based path selection.

either that or we need to give up on the idea that host-based
path selection is for anything other than transitioning from
one address block to another.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 18 Oct 1999 15:36:24 -0500

> And what will the default be in the absense of any configuration?

It looks as if the consensus is to pick native IPv6 if available.

  Brian