Subject: Re: (ngtrans) 6to4

From: Alain Durand <[email-masked]>
Date: Tue, 16 Feb 1999 15:04:40 +0100

I would like to comment on the 6to4 proposal too.

Comment 1.
---------------
6to4 is basicaly a new scope of IPv6 addresses. It lies somewhere
in between site local and global.

From 6to4 draft:
   Suppose an IPv6 host on site B queries the DNS entry for a host on
   site A, and the DNS returns multiple IPv6 prefixes. If the host picks
   the 6to4 prefix according to the normal rules for multiple prefixes,
   it will simply send packets to an IPv6 address formed with the prefix
   {FP=001, TLA=TLA624, NLA=192.1.2.3}/48. It is essential that they are
   sourced from the prefix {FP=001, TLA=TLA624, NLA=9.254.253.252}/48.

This says that any host in a site using 6to4 -and- real global
IPv6 addresses, willing to talk to a 6to4 only host MUST implement
this scope selection rule to pick up the correct source address.
If not, a 6to4 only destination host could possibly not be able to return
the packet.

My understanding (please someone correct me if I'm wrong)
is that source address selection is not standardised.
Longuest match between source and destination address is one
way to implement this, but I know of other ways.

This will imply that many host implementations will have to be adapted
to support 6to4 and/or that source address selection must be standardised.

Also, as this is "new" scope of IPv6 addresses, I'm worried about RFC2373,
our addressing architecture doccument. I fear it would have to be modified
to include 6to4 considerations.

Comment 2.
---------------
At 15:29 15/02/99 -0800, Richard Draves wrote:
>Configured tunnels a la the 6bone have two major problems, as I see it.
>First, the 6bone can be difficult to join. You have to find someone already
>on the 6bone willing to create a tunnel so you can join. Second, service is
>lousy. There are multiple dimensions to lousy - seems like half the time the
>routing is screwed up, and when it is working the latencies and packet loss
>rates are worse than talking to the same sites via v4. I'll speculate that
>the 6bone is generally more broken than the v4 internet because it's used
>less and so gets less attention and priority, and the performance is worse
>because the configured tunnels do not match well to the underlying v4
>topology so packets end up traversing more physical links.
>
>The "tunnel broker" idea solves the first problem, making it easy for anyone
>to join. I was very pleased to hear Alain & Marc present their work at the
>interim meeting. However, although it solves the first problem it might make
>the second problem worse - there's even less reason to believe the
>configured tunnel topology will make sense vis a vis the v4 topology.

The 6bone is/was a toy network. It's not production quality, it's just a
testbed.
So it's normal that it gets broken.
On the over hand, the 6ren is supposed to be pre-production quality
and not heavily  based over tunnels. I agree that configured tunnels
are suboptimal. But I would rather like to see a native IPv6 infrastructure
that an optimal, automatic tunnel facility.

The underlying concept of the 6to4 approach is that there is NO global,
native IPv6 infrastructure, thus we have to use the "legacy" IPv4 one.
Now, it's a question of strategy, with always the same question:
"Should we deploy IPv6 from the core or from the edges?"
6to4 answer is clearly the "from the edges" approach.

>It would also be great to have connectivity between the 6bone and 6to4
>sites. I think this is easily possible

IMHO, there is great danger if we do not have this connectivity.
Exept the case of VPN and any other private network, there should
be ony ONE Internet, not severals. Again, this is a political comment.

> we just need one or more well-known
>gateway routers with both 6to4 and 6bone addresses. Isolated 6to4 sites can
>be configured with routes for 3ffe::/16 to the gateways. Inside the 6bone,
>we need to propogate a route for the 6to4 prefix, so 6bone sites can send
>packets to 6to4 addresses. I'm afraid I don't know much about BGP - I hope
>this isn't hard to do?

But then, again, a 6to4 site will have to rely on configured tunnels to join
the 6bone/6ren or any other global IPv6 network.
So 6to4 hasn't solve anything in the general case, just make things worse,
because routing through well known gateways may be really sub-optimal.

So my final comment is that 6to4 looks great for VPNs, but may not be
that nice as a general solution. 

	- Alain.

---

From: Thomas Narten <[email-masked]>
Date: Wed, 17 Feb 1999 12:24:44 -0500

> to support 6to4 and/or that source address selection must be

I agree that this is a real issue with 6to4. The 6to4 draft was one my
motivations for presenting the topic of source/destination address
selection as an area where I believe more work needs to be done.

Right now, we have a small number of recommended guidelines, but much
is left to the implementor's discretion. My thinking at present is
that source address selection is an area where a) we know some things
we would like to be able to specify today, and b) it is unclear that
we understand today what sort of address selection policies will be
necessary a few years from now (i.e., we don't have very much
experience yet with multiple addresses on an interface). Given the
difficulty of making changes in host stacks once deployment has begun,
it might make sense to see if we can develop a simple address
selection mechanism that allows some tweaking in the future (via
policy/config) WITHOUT requiring source code changes on hosts.

As an example, consider multi-homed sites, i.e., those connecting to
multiple ISPs. To be friendly to route scaling, one approach is to
give each node in the site an address out of each provider's
prefix. It seems like in order to fully exploit such multihoming, it
would be useful (necessary?) for a host originating TCP connections to
have some control over what address gets used, as opposed to just one
being picked at random.

Thomas

---

From: Jim Bound <[email-masked]>
Date: Wed, 17 Feb 1999 15:03:17 -0500

Hi Alain,

FP = 001.  That is global not site?  Maybe I am missing your point?

>If not, a 6to4 only destination host could possibly not be able to return

I don't agree it is just another global scope address.  The source
address selection/interface/lifetime will work like any other compare in
the code base logic.

>is that source address selection is not standardised.

Nor should it be by the IETF.  We should take this to the IPv6
implementors list and figure it out as we have for inetd.conf et al.
This is not a big deal because we are all stuck forever in our
implementations with this ridiculous consensus that it is OK to use a
lesser scoped address for the src than the dst address.  Which I still
think is wrong wrong wrong.  But lets just do do this on the implist
maybe you or Francis can start that thread on that list.  We can
probably get aggreement by this time next week and maybe implement it by
Connectathon or the next UNH bake-off.  But lets not do this in the IETF
please.  This is the vendor jewels and none of the IETF's business.
The IETF gave the rules on scoping and that is fair its up to us to make
it work.

>way to implement this, but I know of other ways.

OK I will bite.  We use longest match but what other ways are you
thinking, if you can share that.  Or add that to the implist thread for
source address selection.

>to support 6to4 and/or that source address selection must be standardised.

Again I don't agree with your premise.  It will affect routing tables
for tunnels in some cases for the top of my head for Hosts as to
choosing a mechanism.  But there is no source address selection issue
that exists prior to 6to4 being invented.

>to include 6to4 considerations.

It is not a new scope.  001 = Global Unicast Address.  Site is another,
etc, etc...

>The 6bone is/was a toy network. It's not production quality, it's just a

Agreed.  6REN will be the production first real IPv6 network and within
the Internet.  From there we will go where not bit has roamed before.

>So it's normal that it gets broken.

I agree.

>that an optimal, automatic tunnel facility.

This is just another mechanism and for a distinct purpose.  IPv6
basically on top of the IPv4 Internet.  Or under it depending on ones
view.

>6to4 answer is clearly the "from the edges" approach.

I think we do both.  But clearly I am hearing we start with the edges
and move to the core as we can with efforts like 6REN and a few other
ISPs preping for IPv6 in Europe, Asia, and U.S. (note I also hear of
parts on other geographies so I am not ignoring Africa, South America,
West Indies, or Tibet just trying to be terse).

>be ony ONE Internet, not severals. Again, this is a political comment.

Can you expound on this more.  I am not sure where your headed I don't
see multiple Internets because of 6to4 but a virtual pipe to connect
IPv6 Intranets over the Internet initially.  Seems pretty good to me.

>the 6bone/6ren or any other global IPv6 network.

Not if the 6bone supports a or several 6to4 NLAs.

>because routing through well known gateways may be really sub-optimal.

It solved what the draft says it solved it permits me in compaq.com to
send you at imag.edu an IPv6 packet to your IPv6 network over an IPv4
Tunnel.  All uses of networking that are not native meaning other than
VPN, NAT, Tunnels, ALGs, and I think even things like NHRP are always
going to be sub-optimal, but we have no choice for the mechanisms.  

My issue with Tunnels is that the network needs to be able to manage
them and recover from them when multiple recursive tunnels are used and
ICMP and PMTU data gets lost.

>that nice as a general solution. 

Well I just disagree with you on this point and I think the only time we
have disagreed on anything.  I think 6to4 is a good idea to help jump
start IPv6 and that is what is motivating me completely.  I also don't
see anyting technically that is that complex and the code is really only
needed at the edge nodes of a domain.

rah rah 6to4....--------------)

/jim

---

From: Randy Bush <[email-masked]>
Date: Thu, 18 Feb 1999 09:42:23 -0800 (PST)

Matt Crawford <[email-masked]>
> Thomas sez:
> The host always has that control, since it emits packets with
> complete source addresses.  The application generally has the option
> of exerting that control, since the bind() syscall permits it, but
> usually the source address is chosen in the kernel.  That's great,
> because then a simple rule like "longest match of same scope" can be
> inserted there.  But it's bad because you might like to choose the
> best fit between the possible source addresses and the set of
> available destination addresses for the target node.  By the time the
> kernel is default the source address, it's too late.
> 
> There are various places you could hack it in, such as having the
> resolver (or its front end) sort the destination addresses on lookup
> according to their fit with the set of possible source addresses,
> then let the kernel make the matching source choice if the
> application hasn't done so.  This sounds pretty nifty to me, but it's
> a long way from "could do" to "must do."

so applications on hosts are making routing decisions?  my noc's gonna
love debugging this.  not.

randy

---

From: "Matt Crawford" <[email-masked]>
Date: Thu, 18 Feb 1999 11:19:41 -0600

Matt

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 19 Feb 1999 02:33:52 +0000

Randy Bush wrote: (re address selection)

> love debugging this.  not.

Indeed. That's why an algorithmic rule is desirable, so that
rational debugging is possible. This is not specific to 6to4;
it arises whenever an IPv6 node has >1 valid address.

   Brian

---

From: "Matt Crawford" <[email-masked]>
Date: Fri, 19 Feb 1999 10:19:21 -0600

> love debugging this.  not.

I don't see it that way, so we may be thinking in different terms.

First the application on the host gets to choose a destination
address .. like now.  Possibly a library function may try to
influence this choice by ordering the list of possibilities in some
way.  Since the ordering today is seldom defined, this wouldn't be a
big change.

Then the host chooses a source address.  The application could choose
it, or the kernel could.  This choice is usually not made today, and
when it is, it is usually a choice among several addresses from a
common prefix, as on multi-addressed web servers.  The new feature
would be choosing a IPv6 source address from among widely separated
prefixes.  This may or may not influence the path packets travel on.
(I expect it often will.)  But didn't the network manager authorize
the host to make this choice by alloting it multiple prefixes?

				Matt

---

From: Francis Dupont <[email-masked]>
Date: Fri, 19 Feb 1999 17:39:10 +0100

In your previous mail you wrote:

   
   First the application on the host gets to choose a destination
   address ...... Then the host chooses a source address....

=> I believe that (destination then source address selections) should be
done by a "policy module". getnameinfo() seems a good place to put
a part of it but one needs support in kernel too. Another point is
there should be a per-user policy with a default policy managed
by the administrator... The policy can include other things like
security, policy routing (using source routing), CoS/QoS, ...
We (unified BSD teams) exchanged some mails about this kind of ideas,
for instance where to put it (kernel/user), etc.

Thanks

[email-masked]