Subject: RE: (ngtrans) 6to4

From: Richard Draves <[email-masked]>
Date: Tue, 16 Feb 1999 21:48:38 -0800

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

I disagree, it is a global scope prefix. You do raise a valid point - care
needs to be taken with routing - but that's an orthogonal issue that I'll
get to below. To restate in a confusing way :-): Just because two networks
using global scope addressing can't talk to each other, doesn't mean that
one of them is not global scope.
 
> 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.

I think the 6to4 sites will want routes to handle destinations outside of
the 6to4 prefix.
 
> 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.

Yes, MSR IPv6 uses longest match between source & destination as the last
tiebreaker in source address selection. For example, it will pick the
"right" source address when a site with both 6to4 and 6bone/6ren addresses
sends to a 6to4-only site. However if the 6bone/6ren and 6to4 worlds can
route to each other, then this source address selection feature is not a
requirement for connectivity.

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

I disagree, I think only border/gateway nodes have to support 6to4. But 6to4
is easy to support, so I suspect all implementations would want to support
it.

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

It's not a new scope.

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

My argument is stronger - the chronic routing brokenness may be due a lack
of production quality, but I think the performance problems (higher
latencies & loss rates) are inherent in the architecture of a network built
out of configured tunnels.

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

Yes, native IPv6 backbone infrastructure is preferable to tunneling over
IPv4. However I think realistically, we will see more deployment from the
edges. We need to have a great solution for tunneling IPv6 over the IPv4
Internet backbone. Eventually the big providers can figure out that the real
action is in IPv6 and start to support it natively, but we can't wait for
that.

The network-of-configured-tunnels approach just doesn't seem to work well,
as far as I can tell. So I think we need 6to4 for most sites that will adopt
IPv6. Some lucky sites will be connected to the 6ren & other native v6
providers and won't need 6to4, but they'll be in the minority.

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

My view is that 6to4 sites will greatly outnumber 6ren sites (& other
natively-connected sites), and after 6to4 deployment no site will want to be
on the 6bone because it just won't work as well.

So if there are a small number of well-known gateways to which 6to4 sites
can direct traffic to reach the 6ren, it should be OK. It will not introduce
the same kinds of problems seen with configured tunnels in the 6bone. If we
allow NUD over 6to4 it would be easy to find a working gateway should one go
down.

After many years, the native v6 internet might be large enough that this
will be unsatisfactory. A 6to4 site will want to use the "closest" gateway
to the native v6 internet. (Going the other way, from native v6 internet to
6to4, can happen as soon as the packet hits a dual-stack router, and then
the packet is routed efficiently via v4.)

This will require more intelligent configuration of the 6to4 site's border
gateway. There are multiple answers possible. One is that by the time that
happens, v6 will be well entrenched and people will be happy to do more
configuration to get better performance. Another is that we could automate a
system for distributing the default-free v6 routing table to 6to4 sites and
letting them use it configure themselves automatically.

Rich

---

From: Francis Dupont <[email-masked]>
Date: Wed, 17 Feb 1999 20:30:21 +0100

In your previous mail you wrote:

   > it's just a testbed.

=> We agree! We'd just like to get a real service and of course
a native infrastructure is better than hacks like tunnels.
But 6to4 is based on tunnels, not configurated or host-to-host
automatic: border router to border router tunnels. Then it is
an inferior solution.

   Some lucky sites will be connected to the 6ren & other native v6
   providers and won't need 6to4, but they'll be in the minority.
   
=> I recognize I am perhaps lucky but I disagree on the minority
and it is very important to involve students and researchers
(kids too ? :-) in IPv6: if all the young engineers one needs
to manage NATs over NATs over ... are convinced they should go
to IPv6 we win.

=> I believe a large part of the 6bone will be 6ren sites.

=> you don't need NUD, only dynamic routing: BGP can/will do it.

=> this introduces two issues:
 - as usual with two interconnected infrastuctures you have the problem
   to keep as long as you can an infrastructure or to switch to the other
   as soon as possible. This introduces policies, asymmetrical behavior,
   etc.
 - the standard solution will be to use one part of the embedded IPv4
   address for routing with the danger to inject a large part of the
   IPv4 routing table/mess into the IPv6 world.
For me the second issue is the reason why IPv4 embedded addresses are BAD
(the IPv4 compatible IPv6 address story has already shown this,
fortunately they are no more considered as a device to use today)!

Thanks

[email-masked]

---

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

Francis,

I agree with you about embedded IP4-compatible addresses but they have
some uses we will need I predict.  But 6to4 is not using them. It is
just a set of bits in the NLA to identify a means to tunnel packets. In
the spec it gives the psuedo code for the edge devices.  So I would
claim the 6to4 abstraction is not using embedded IPv4 addresses but
rather using them as a prefix identification for a tunnel.  Which I
think is different.

I still don't see anything wrong from your mail with putting it in our bag
of tricks to get IPv6 deployed.  Let me give you a "real" live customer
case OK.  I can't reveal the customer name and sorry about that.

I know of a company X whose business is discrete manufacturing of
production parts (this is so you can't guess the customer). The product
is assembled from design mechanisms and firmware from multiple suppliers
over the Internet for communications via a set of ISPs.  Right now this
particular customer wants IPv6 today for two reasons:  1 it is using NAT
and wants to get rid of it sooner than later, and 2 wants to use IPsec
between the company and its suppliers.  The customer has determined IPv6
will give all they need plus some other good stuff IPv6 has I won't go
into here.  They also know that IPsec is "mandatory" in IPv6 and when the
company and its suppliers begin getting upgrades to their OS's from
their suppliers (in this case it is a UNIX platform base for Servers and
Desktops) supporting IPv6 they know they will get IPsec.  This way the
company and supplier can secure their communications end-2-end with
IPsec for each packet.  But how do they get across the Internet until
the "core" (as you and Alain define it) is IPv6 ready, when both the
company and the suppliers are ready to receive IPv6 packets at their
edges?  I have come up with ways for this to work with configured
tunnels and with some AIIH+SIIT parts, but they are quite complex.
With 6to4 this customer can move packets via the tunnels at the edge
devices right over the Internet.  That is why 6to4 is a good tool.

Now I can probably come up with cases where 6to4 is not the best
mechanism to use but another mechanism.  But so what.  We learned at
Grenoble we will need variant mechanisms for variant customer solutions.

It is a good tool for our bag of IPv6 transition mechanisms and I think
we should add it to the other ones.   

/jim

---

From: Francis Dupont <[email-masked]>
Date: Wed, 17 Feb 1999 22:55:27 +0100

I agree with you about embedded IP4-compatible addresses but they have
   some uses we will need I predict.  But 6to4 is not using them.

=> 6to4 used IPv4 embedded addresses (as IPv4 compatible IPv6 addresses)
which I believe it is a *bad* idea.

   It is just a set of bits in the NLA to identify a means to tunnel packets.
   In the spec it gives the pseudo code for the edge devices.  So I would
   claim the 6to4 abstraction is not using embedded IPv4 addresses but
   rather using them as a prefix identification for a tunnel.  Which I
   think is different.
   
=> no, 6to4 uses IPv4 embedded addresses because they are convenient.
I agree that they are but the problem is they are *too* convenient.
I have a counter-proposal : just put AS number at this place, it
is a set of bits too and if 6to4+ is implemented only on border
gateways these gateways should use a border gateway protocol and
AS numbers are far better than stupid IPv4 addresses. They can used
for integrated routing optimization for instance because they have
a (congruent) meaning in the IPv6 routing world too...
Another advantage is AS number space is smaller (some thousands of them
are used), has a hard limit (65535) which is not the case for IPv4
addresses (millions of routers, 2*32 max). Last, you can use
some policy routing tables like RADB...

=> another idea is to get some ideas from MSDP (draft-farinacci-msdp-00.txt)
and to exchange tunnel end-point references (in place of multicast source
advertisement) between IPv6 islands (in place of PIM-SM domains).
In fact perhaps we'll need MSDP/MBGP for IPv6 one day too...

[email-masked]

---

From: Jim Bound <[email-masked]>
Date: Wed, 17 Feb 1999 23:12:43 -0500

Francis,

I am not familiar enough with BGP or AS numbers to comment so I will
leave that to the authors or others.

As far as Dino's draft.  I can go look at it sure.
If it can work maybe we should have that as a mechanism.  The more
mechaninisms the better.  I love mechanisms and so will the customers.
Choices are always a good thing for engineers.

But so far you have not told me 6to4 won't work but that it could become
a problem later, I think?

thanks
/jim

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 17 Feb 1999 13:19:44 +0000

Brief due to lousy dialup situation...

1. the 6to4 scope is clearly global. there are some issues with
propagation of routing adverts that will be addressed better in version
01.

2. yes, the longest match source selection is a requirement, as the
default; that is also in the next version, but I think it is
a generic requirement anyway.

3. I think Alain's comments about scope and routing will be
affected by the revised scenarios you will see in version 01.

    Brian

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 18 Feb 1999 13:15:13 +0100

At 22:55 17.02.99 +0100, Francis Dupont wrote:
>is a set of bits too
.....
>addresses (millions of routers, 2*32 max).

AS numbers belong to my provider.
And they're a precious resource in IPv4; I won't get one if I want it.
And you can't route on them without being a global BGP peer.
And we tried that with one of the "experimental" address allocations.

Doesn't work for me.

            Harald

-- 
Harald Tveit Alvestrand, Maxware, Norway
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 18 Feb 1999 14:02:23 +0000

Francis, I hate to be blunt but if you think AS numbers can
be used instead, you need to read 6to4 again from the beginning.
However, wait until next week when I hope to have a new version
that is much clearer on the scenarios.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 18 Feb 1999 13:58:54 +0000

>    IPv4 routing table/mess into the IPv6 world.

No! No! 6to4 does *not* do this in any way. Absolutely not.

    Brian

---

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

If it can work maybe we should have that as a mechanism.

=> it (AS# based auto-tunnelling) can works if you have full routing
(ie the whole knowledge about AS numbers).

=> exactly, I believe 6to4 idea shares automatic tunnels / IPv4-compatible
IPv6 addresses stuff pros and cons. And what Richard Draves wants is not
a new way to set up tunnels, just native infrastructure: it is fist a
strategy issue...

Thanks

[email-masked]

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 22 Feb 1999 18:56:00 -0800 (PST)

Brian,

> a generic requirement anyway.

I don't think it is a generic requirement for IPv6 to work.
Ignoring 6to4, I can construct examples where a longest match works better
than "pick the first" and I can also construct examples where "pick the first"
works better than longest match (assuming that "pick the first" is aware
of the explicitly defined address scopes of global, site-local, and
link-local.)

Re: 6to4.
It is clear that longest match is a sufficient condition to make 6to4 work.
But the only necessary condition is to "select a 6to4 source address if
the destination address is 6to4".

Thus I think we need to understand what we think longest match will really 
buy us in the long term evolution of IPv6 addressing before we mandate it.

   Erik

---

From: Jim Bound <[email-masked]>
Date: Mon, 22 Feb 1999 23:18:36 -0500

>buy us in the long term evolution of IPv6 addressing before we mandate it.

I think I will loose my mind if we mandate longest match -----)....

This is an implementation issue and I cannot see any of the
interoperability classic issues we search for to decide if it is
something we need to standardize?

This discussion has just started on the implementors list so I don't
think it being discussed here is relevant anymore IMO.  

/jim

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 23 Feb 1999 12:12:37 +0000

I'm not so sure it's an implementation detail. It can have quite
a strong impact on traffic patterns if multihoming becomes the norm,
so network managers have just as strong an interest in this
as implementors.

However I agree that mandating an algorithm is too strong. In the
new version of 6to4 I have made longest match a SHOULD which is as 
far as I would want to go. 

   Brian

---

From: Jim Bound <[email-masked]>
Date: Tue, 23 Feb 1999 08:44:23 -0500

SHOULD is fine.  That says you should do this unless you have a good
reason to not do this.  But if I can increase my performance with a more
robust lookup I should not be prevented from doing it as an implementor.
look ups are real coding tasks and thats why I still object to it being
in the document.  its really not an authors business how I build their
protocol or mechanism.  but I will let it go as the work to resist a
SHOULD I can ignore in my implementation on this is list is not worth my
time for debate.

thanks
/jim