Subject: unmanaged scope comments

From: Pekka Savola <[email-masked]>
Date: Thu, 19 Sep 2002 18:34:23 +0300 (EEST)

Larger issues: 

1) Especially for case A and C.  I think there needs to be a clearer
characterization of (IPv4) connectivity and addresses, like (this has all
cases I think -- it could be simplified):

 1. global addresses
  a) dynamic
      - enough addresses for every node
      - only one
  b) static
      - ^
      - ^
 2. private addresses: NAT by ISP (or outside of your control) [otherwise
one of cases above]
      - dynamic
      - static

2) 

4	Application requirements of an IPv6 unmanaged network

The application requirements are expressed in mostly three
dimensions: connectivity, naming, and security. Connectivity issues
include the provision of IPv6 addresses and their quality: do host
need a global scope address, should this address be stable, or more
precisely what should be the expected lifetime of the address.

==> connectivity includes one very important component IMO: the quality of
network connections.  This is often ignored.  It's a high risk for a vendor
to enable IPv6 by default, for example, if that'd result in lower quality
connections to e.g. dual-stack web servers (a very real fact in 6bone), this
should be taken into consideration at least in the short term.

3)

4.2	Requirements of client applications
[...]
maintaining the privacy of the client. Many potential users of IPv6
observe that the current NAT configuration provides some level of
privacy: all communications to outside servers appear to come from
the single IPv4 address of the NAT; the source IPv4 address does not
identify a specific host inside the unmanaged network ..

==> .. or even a specific host in the ISP.  IMO it's usually a non-issue,
particularly in unmanaged case, whether someone can identify which node in
a sparsely populated subnet is which.

4) Triggered by sect 4.3 and 4.4, but it's more generic than that; I think
the draft needs to consider differences wrt. static/dynamic
addresses/prefixes.  In particular, privacy, server address and generally
DNS issues come to mind.

5) 

The case where the ISP is IPv6 capable, but the gateway is not is
similar to case A.

5.1	Case A, host deployment of IPv6 applications

In this case the gateway doesn't provide IPv6; the ISP may or may
not provide IPv6, but this is not relevant, since the non-upgraded
gateway would prevent the hosts from using the ISP service. Some
hosts will try to get IPv6 connectivity, in order to run
applications that require IPv6, or work better with IPv6.

==> This is not true I think: for example, even if gateway runs v4 private
addresses, ISP could provide e.g. internal tunnel service or something like
ISATAP to their v6-enabled network.

==> Do you refer to *layer 3* gateway?  (Otherwise, this gets simpler with
e.g. bridged ATM encapsulation in xDSL).

6)

5.1.1	Application support in Case A
Server applications are also not a primary focus of Case A. Server
applications require DNS support, which is difficult to engineer for
clients located behind a NAT. Besides, server applications, at this
stage, cater mostly to IPv4 clients; putting up an IPv6 only server
is not very attractive.

==> I'm not quite sure how DNS support is difficult to engineer; this
probably has an unstated assumption that the address behind NAT would change
too often to be really updateable or writable in DNS.  This does not need to
be the case.
==> In case A, clients don't necessarily need to be behind a NAT.

7) backward/upward compatibility; I brought this up in the interim meeting. 
IMO I don't see it as a hard requirement to be able to be able to perform
v4only <-> v6only conversions.  This depends quite a bit on what our "dual
stack" deployment strategy is: whether we encourage vendors (e.g. LCNA type
applications) to ship v6-only stacks or dual-stacks.

8) A comment:

-- I think that there is a case to be made that using translation
tools boosts the previously mentioned network effect and makes it
work in our favor; the somewhat crippled nature of the translation
tools is in fact also a good thing, because it gives people an
incentive to throw them away once they realize that they are broken.
I realize that this is heresy, so be it. --

==> No I don't agree with the last statement: this gives folks only an
incentive to enhance and tweak these features, not fix them *properly*. 
Think NAT ALGs...

Semi-editorial:

nat/firewall with that name. Since updating DNS is a management
task, it somewhat falls outside the scope of an unmanaged network.

==> management, yes, but it's often automatic.

A peer to peer session typically starts by
an exchange of synchronization messages through the rendezvous
servers, during which the peers exchange the addresses that will be
used for the session.

==> not knowing better these protocols, I'm only guessing, but some of these
messages could be done e.g. to initiate NAT, and thus be at least partially
unnecessary with IPv6.

There are multiple aspects to the security of peer-to-peer
applications, many of which relate to the security of the rendezvous
system. 

==> I'm not sure which threats you refer to; the one I can think of is some
kind of information disclosure.  But I'm more afraid of the (programming) 
security of p2p apps myself.

4.4	Requirements of server applications
The DNS entries for the server will have to be updated, preferably
in real time, if the server's address changes. In practice, updating
the DNS is slow, which implies that server applications will have a

==> The slowness of DNS is debatable, I think.  TTL can be tuned if
necessary.

The security of server applications depends mostly on the
correctness of the server, and also on the absence of collateral
effects: many incidents occur when the opening of a server on the
Internet inadvertently enables remote access to some other services
on the same host.

==> s/host/node/
==> not necessarily only the same node, even on the same local network
==> does 'correctness of the server' refer to the server application?

5.1.3	Naming services in Case A

At this phase of IPv6 deployment, hosts in the unmanaged domain have
access to DNS services over IPv4, through the existing gateway. DNS
resolvers are supposed to serve AAAA records, even if they only
implement IPv4; the local hosts should thus be able to obtain the
IPv6 addresses of IPv6 only servers.

==> s/are supposed to//
==> s/should thus be/are/ (are these really worth the conditionals..)

presence of translation or port mapping services; there is also not
much of a case for letting local IPv4 servers publish their service
on the IPv6 Internet.

==> I agree!  These should be dual-stacked if they're important.

To enable this scenario, the gateway need to use a mechanism obtain
a global address prefix from the ISP, and advertise this address
prefix to the hosts in the unmanaged network; several solutions will
be assessed in a companion memo [EVAL].

==> and in the degenate case...?

5.2.3	Naming services in Case B

[...]. Currently, IPv4 only hosts
discover the IPv4 address of the local DNS server using DHCP; there
must be a way for IPv6 only hosts to discover the IPv6 address of
the DNS server.

==> s/discover/usually discover/

Generic issue: I think that perhaps case B and case C could be reversed; I
find it more probable that ISP is the last party of the three to offer v6
service.

5.3.2	Addresses and connectivity in Case C

There are two ways to bring immediate IPv6 connectivity on top of an
IPv4 only infrastructure: automatic tunnels provided by the [6TO4]
technology, or configured tunnels. Both technologies have advantages
and limitations, which will be studied in a companion document.

==> + mechanisms if gateway does not have global addresses.

5.4	Case D, ISP stops providing native IPv4 connectivity

In this case the ISP is IPv6-only, so the gateway looses IPv4
connectivity, and is faced with an IPv6-only service provider. The
gateway itself is dual stack, and the unmanaged network includes
IPv4 only, IPv6 only and dual stack hosts.

==> no IPv4 connectivity to the customer, or no v4 at all (e.g. no
possibility for ALG's, web caches, DNS / SMTP servers etc.).  Probably the
former.

Editorial:

s/IPv6 only/IPv6-only/ ?
s/IPv4 only/IPv4-only/ ?

2	Topology
(ISP)connection. Several hosts are connected to the subnet:

==> s/are/may be/

or may not perform NAT and firewall function. A key point of this
==> s/function/functions/

3.2	Client applications

network and a server at a remote location. A typical example is
accessing a web server from a client inside the managed network, or
reading and sending e-mail with the help of a server outside the
managed network.

==> s/managed/unmanaged/g (whoops.. :-)

3.3	Peer-to-peer applications

There are two kinds of peer-to-peer applications, the "local peer-
to-peer" that only involve hosts on the unmanaged network, and the

s/on the unmanaged network/in the unmanaged network/ (lots of other places;
I'm not sure which one is correct, but 'in' sounds better to my ear at
least)

well identified peers outside the unmanaged network. These

==> s/well identified/well-identified/ ?

applications are often facilitated by a server outside the managed
networks. Examples of a peer-to-peer application would be a video-

==> s/managed/unmanaged/ (whoops :-)
==> s/networks/network/

3.4	Server applications

==> I think the order should be changed: Server before Peer-to-peer, as peer
to peer is IMO the most generic case.
                                                          requires
some special programming of the NAT or firewall. When the NAT only
publishes a small number of global IP addresses and relies on "port

==> s/requires/require/
==> s/publishes/maps to/ (or something else, publishes sounds funny)?

nat/firewall with that name. Since updating DNS is a management
task, it somewhat falls outside the scope of an unmanaged network.

==> s/nat/NAT/

4.2	Requirements of client applications
An important security issues with client applications is,

==> s/issues/issue/
==> s/is,/is/

4.3	Requirements of peer-to-peer applications
Peer-to-peer applications require global connectivity. In an IPv6
network, we would expect the peers to use a global IPv6 address,
which will have to remain stable for the duration of the peer-to-
peer between client and server.

==> s/peer/peer session/
==> "client and server" is a bit funny wording in P-2-P case.. :-)

to deploy, and light weight; it will have to involve tunneling over

==> s/light weight/light-weight/ (not sure..?)

5.2.1	Application support in Case B

We expect the unmanaged network to include three kinds of hosts:
IPv4 only, IPv6 only, and dual stack. 

==> soften the wording a bit: not every unmanaged network need to include
all three.

IPv4 only hosts use the services a brand new IPv6 only printer.

==> s/services/services, like/

To enable this scenario, the gateway need to use a mechanism obtain

==> s/need/needs/, s/obtain/to obtain/

not.  The gateway has been upgraded and offers both IPv4 and IPv6
connectivity the hosts. It cannot rely on the ISP for IPv6

==> s/connectivity/connectivity to/

connectivity, because the ISP does not offer ISP connectivity yet.

==> s/offer ISP/offer IPv6/

representation of the IPv4 address of the server, either by sing a

==> s/sing/using/

--
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Fri, 20 Sep 2002 00:48:01 +0900

>should be taken into consideration at least in the short term.

	i don't understand what you want to do about it.  will you ping/ping6
	destination and pick shorter roundtrip?  when multiple A records
	are returned for www.foo.com, do you probe them to get the optimal
	performance?  i believe the "quality" factor does not matter, and
	it cannot be measured from endpoint (at least within short time).

itojun

---

From: Pekka Savola <[email-masked]>
Date: Thu, 19 Sep 2002 19:01:15 +0300 (EEST)

On Fri, 20 Sep 2002, Jun-ichiro itojun Hagino wrote:
> 	performance?  

That's a difficult, general question to consider.  It's not easy.  I've 
said one very real possibility to *not* introduce production services in 
the same DNS names yet..

> i believe the "quality" factor does not matter, and

Connection to U.S. from Europe being 400 ms (and a few packets getting
lost here and there) versus 150 ms is very measurable even without any
tools e.g. in web browsing.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 20 Sep 2002 14:39:27 +0200

--On 20. september 2002 00:48 +0900 Jun-ichiro itojun Hagino 
<[email-masked]> wrote:

>> ==> connectivity includes one very important component IMO: the quality
>> of network connections.  This is often ignored.  It's a high risk for a
>> vendor to enable IPv6 by default, for example, if that'd result in lower
>> quality connections to e.g. dual-stack web servers (a very real fact in
>> 6bone), this should be taken into consideration at least in the short
>> term.
>

I have wanted for a long time someone more competent than me to run an 
experiment where one, after a name lookup, would send SYN packets to *all* 
the addresses returned, and only complete the three-way handshake on the 
first one to reply.

after all, it seems impossible to get anyone to take seriously the job of 
getting the network to tell me which of two addresses are "best", and the 
servers in these DOS-attack days have to defend against synfloods anyway.

just wasting some SYN packets seems to me to be likely to achieve the "low 
hanging fruit" of *most of the time* picking the best address to use.

so far, afaik, nobodoy's tried it.

                  Harald

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Sat, 21 Sep 2002 16:40:27 +0900

>>>>> On Fri, 20 Sep 2002 14:39:27 +0200, 
>>>>> Harald Tveit Alvestrand <[email-masked]> said:

> so far, afaik, nobodoy's tried it.

This sounds like an experimental library function I wrote two years ago:

http://orange.kame.net/dev/cvsweb.cgi/kame/kame/kame/libinet6/mconnect.c

(though the library makes a short delay between two consecutive
connect(2)s.)

I used the library with some applications and found it worked well,
but I've not promoted the new library because I didn't know how this
could be widely deployed.

Also, if I understand correctly, there is a web client that has a
similar routine inside the application.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

---

From: Pekka Savola <[email-masked]>
Date: Tue, 24 Sep 2002 09:36:29 +0300 (EEST)

I'll revisit this due to a private comment.

Perhaps I should clarify this a bit.

Your take seems to be "how do we solve this problem given the network and 
v6 connectivity we have".

Mine is basically "we have a problem with network connectivity and v6 and
with the current state, turning v6 on for everything will produce
dissatisfied users".

With "network connectivity" I'm referring to the 6bone mess.

People usually just say, "enable IPv6" but it's more complex that.  As an 
user that actually uses IPv6 quite a bit, I'd be very hesitant to enable 
full use in a generic form.

I'm not sure whether trying to solve this is in our charter or not (or 
even if it was, would we be able to do anything), but that's one real 
problem.  6bone mess is hindering IPv6 deployment.

FWIW, I think 6bone addresses etc. are useful to get people started and 
acquainted with IPv6.  But tunnel-to-everyone, transit-to-everyone mess is 
not.  Those 6bone sites should be connected as leaf sites to proper 
connectivity providers.

---

From: Marc Blanchet <[email-masked]>
Date: Tue, 24 Sep 2002 09:14:12 -0400

> With "network connectivity" I'm referring to the 6bone mess.

6bone = experimental network.  6bone is not the IPv6 internet.

> problem.  6bone mess is hindering IPv6 deployment.

not really. 

> acquainted with IPv6.  But tunnel-to-everyone, transit-to-everyone mess
> is  not.  Those 6bone sites should be connected as leaf sites to proper 
> connectivity providers.

s/6bone/internet ipv6/

Marc.

---

From: Pekka Savola <[email-masked]>
Date: Tue, 24 Sep 2002 16:54:04 +0300 (EEST)

6bone is what we have.

Saying it is not "ipv6 internet" won't change the truth, unfortunately.  
We have a small, with a couple of million potential users, native IPv6
network in Europe too, called 6NET, but I wouldn't go as far as calling
that "ipv6 internet" either.

One must either acknowledge that or live in a dream world thinking we have 
good connections, "ipv6 internet" is doing well etc.

And how we can fix that?  Start building real v6 connections and start 
ignoring 6bone.  But there is no IPv6 internet other than 6bone yet.  
Sorry.

---

From: Marc Blanchet <[email-masked]>
Date: Tue, 24 Sep 2002 10:19:18 -0400

> 6bone is what we have.

we have more than 6bone. one good way to differentiate is: 
 6bone = 3ffe::/16. ipv6 internet = 2001::/16.
> Saying it is not "ipv6 internet" won't change the truth, unfortunately.  

sorry, but in the networks I'm controlling or involved, there is a clear
distinction between the two:
- production = 2001::/16, reliable connections, v6 native if possible
- test/experiment = 3ffe::/16, experimental code from vendors, testing new
mechanisms, etc....

> One must either acknowledge that or live in a dream world thinking we
> have  good connections, "ipv6 internet" is doing well etc.
> 
> ignoring 6bone.

I'll rephrase: start building production v6 networks and use only 6bone for
experimental work.

>  But there is no IPv6 internet other than 6bone yet.  

some. more coming, I agree...

What I'm trying to say is that the current 6bone should not be seen as a
model or a reference of the "ipv6 internet". it is a testbed, experimental
network, crash and burn, ...

Marc.

>> > Your take seems to be "how do we solve this problem given the network
>> > and  v6 connectivity we have".
>> > 
>> > Mine is basically "we have a problem with network connectivity and v6
>> > and with the current state, turning v6 on for everything will produce
>> > dissatisfied users".
>> > 
>> > People usually just say, "enable IPv6" but it's more complex that.  As
>> > an  user that actually uses IPv6 quite a bit, I'd be very hesitant to
>> > enable  full use in a generic form.
>> > 
>> > FWIW, I think 6bone addresses etc. are useful to get people started
>> > and  acquainted with IPv6.  But tunnel-to-everyone,
>> > transit-to-everyone mess is  not.  Those 6bone sites should be
>> > connected as leaf sites to proper  connectivity providers.
>> 
>> s/6bone/internet ipv6/
>> 
>> Marc.
>> 
>> 
>> 
> 
> -- 

------------------------------------------
Marc Blanchet
Viagénie
tel: +1-418-656-9254x225

------------------------------------------
http://www.freenet6.net: IPv6 connectivity
------------------------------------------
http://www.normos.org: IETF(RFC,draft),
  IANA,W3C,... standards.
------------------------------------------

---

From: Bill Owens <[email-masked]>
Date: Tue, 24 Sep 2002 10:23:48 -0400

>ignoring 6bone.  But there is no IPv6 internet other than 6bone yet.

There is perhaps something in between:

[cookiemonster:~] owens% traceroute6 hammer.uoregon.edu
traceroute6 to hammer.uoregon.edu (2001:468:d01:dc::80df:dc1d) from 
2001:468:901:1:203:93ff:fed6:dfcc, 30 hops max, 12 byte packets
  1  c7206-ge0-0.nysernet.net  1.291 ms  0.484 ms  0.503 ms
  2  nyc-m20-nnsyr.nysernet.net  13.811 ms  13.981 ms  13.925 ms
  3  roc-m10-nyc-m20.nysernet.net  21.467 ms  21.235 ms  20.965 ms
  4  buf-m20-roc-m10.nysernet.net  23.047 ms  22.945 ms  22.881 ms
  5  clev-nysernet.abilene.ucaid.edu  27.226 ms  27.581 ms  27.362 ms
  6  ipls-clev.abilene.ucaid.edu  33.778 ms  33.685 ms  33.449 ms
  7  kscy-ipls.abilene.ucaid.edu  42.633 ms  42.661 ms  43.221 ms
  8  kscy-dnvr.abilene.ucaid.edu  54.519 ms  53.815 ms  53.663 ms
  9  snva-dnvr.abilene.ucaid.edu  78.355 ms  78.035 ms  79.221 ms
10  2001:468:ff:b4d::2  92.055 ms *  91.137 ms
11  2001:468:d3f:1::2  91.39 ms  91.674 ms  91.789 ms
12  hammer.ipv6.uoregon.edu  92.268 ms  91.678 ms  91.538 ms

[cookiemonster:~] owens% traceroute hammer.uoregon.edu
traceroute to hammer.uoregon.edu (128.223.220.29), 30 hops max, 40 byte packets
  1  c7206-1.nysernet.org (199.109.32.254)  0.92 ms  0.836 ms  0.476 ms
  2  199.109.5.86 (199.109.5.86)  13.738 ms  13.693 ms  13.754 ms
  3  roc-m10-nyc-m20.nysernet.net (199.109.5.53)  21.355 ms  22.949 ms 
20.973 ms
  4  buf-m20-roc-m10.nysernet.net (199.109.6.2)  22.692 ms  23.851 ms  23.228 ms
  5  abilene-clev-buf-m20.nysernet.net (199.109.2.2)  27.101 ms 
26.637 ms  27.035 ms
  6  ipls-clev.abilene.ucaid.edu (198.32.8.25)  33.208 ms  33.272 ms  33.877 ms
  7  kscy-ipls.abilene.ucaid.edu (198.32.8.5)  42.53 ms  42.008 ms  42.355 ms
  8  dnvr-kscy.abilene.ucaid.edu (198.32.8.13)  53.762 ms  53.011 ms  53.15 ms
  9  pos-6-3.core0.eug.oregon-gigapop.net (198.32.163.13)  86.98 ms 
86.256 ms  90.283 ms
10  uo-0.eug.oregon-gigapop.net (198.32.163.147)  86.877 ms  84.327 
ms  85.403 ms
11  ge-1-1.uonet2-gw.uoregon.edu (128.223.2.2)  85.201 ms  84.273 ms  86.951 ms
12  hammer.uoregon.edu (128.223.220.29)  85.456 ms  84.671 ms  86.446 ms

The reason those traceroutes look so similar is that they're both 
native paths from Syracuse, NY (central NY state) to Eugene, OR. 
There's a slight difference at the far end because UO is dual 
connected to Abilene, and the BGP config is slightly different for v4 
and v6. But they're basically the same path, over the same equipment, 
all running dual-stack and native.

Of course other R&E networks have had native v6 capabilities for 
quite some time, too. One thing that stands out for me with respect 
to this path is that it crosses five ASes and all the participants 
are running released code on standard hardware, routing IPv4 and IPv6 
with the same boxes. And for most of us that means all the boxes - we 
have no IPv4-only routers any more. I'm not sure how many other 
networks are doing that (if you are, I'd like to compare notes ;).

Of course, NYSERNet, the Oregon GigaPoP and Abilene are not the 'real 
internet', where 'real internet' = 'commercial DFZ providers'. But we 
definitely aren't the 6Bone either.

Bill.

---

From: Pekka Savola <[email-masked]>
Date: Tue, 24 Sep 2002 17:31:27 +0300 (EEST)

> networks are doing that (if you are, I'd like to compare notes ;).

We have a full dual-stack backbone in Finland.

> definitely aren't the 6Bone either.

Sure.. but I calling that (using today's terminology) "IPv6 Internet" 
would be as much joke as calling the-network-that-was-in-1980 an Internet.

A good joke.  Heh!

(Sure, you weren't making such an assertion.)

---

From: Pekka Savola <[email-masked]>
Date: Tue, 24 Sep 2002 17:33:47 +0300 (EEST)

>  6bone = 3ffe::/16. ipv6 internet = 2001::/16.

Routing is independent of addressing.

[...]
> network, crash and burn, ...

Sure.. sure.. but before we can have *any* credibility, we must have a 
network that is reasonably global.  Today that that is 6bone, 
unfortunately.

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 24 Sep 2002 10:39:27 -0400

>Routing is independent of addressing.

No, it's not.  :-)

Seriously, I hear this statement a lot, and it is pretty clear to me
that routing is not independent of addressing, since IPv4 and IPv6
both imbed topological routing information in the address prefixes.

In what sense to do you consider routing and addressing to be independent?

>network that is reasonably global.  Today that that is 6bone,

 From what I heard in our meeting, NTT has a "reasonably global" commercial
IPv6 backbone active in Asia, Europe and North America...

Margaret

---

From: Tim Chown <[email-masked]>
Date: Tue, 24 Sep 2002 15:42:56 +0100

> - test/experiment = 3ffe::/16, experimental code from vendors, testing new

and how do you distinguish these prefixes in terms of peering and transit
policies?   

performance isn't just down to which prefix is used, e.g. i am here in
tilab's network in turin and have a 2001: route all the way back to
my home network in the uk:

>tracert6 www.ipv6.ecs.soton.ac.uk

Tracing route to seven.ecs.soton.ac.uk [2001:630:d0:200:a00:20ff:feb5:ef1e]
from 2001:6b8:10:1600:8157:1234:8972:6034 over a maximum of 30 hops:

  1        3 ms     3 ms     3 ms  2001:6b8:10:1600:207:85ff:fea8:6f61
  2        4 ms    60 ms     4 ms  2001:6b8:10:1700:201:2ff:fed8:3b0b
  3        *        *        *     Request timed out.
  4        8 ms     8 ms     7 ms  6bone-gw4.ipv6.cselt.it [2001:6b8:0:100::6]
  5        8 ms     9 ms     8 ms  6bone-gw1.ipv6.cselt.it [2001:6b8:0:100::2]
  6      230 ms   297 ms   200 ms  nl-ams-re-02-t-7.ipv6.aorta.net [2001:730::1:
8]
  7      446 ms   349 ms   326 ms  2001:630:0:1::1e
  8      294 ms   256 ms   402 ms  2001:630:d0:200:a00:20ff:feb5:ef1e

[excuse the broken reverse dns, which i guess should work on a
"production" network]

the response time via the v4 path is much better.   

it depends what the operators are doing with tunnels so i think pekka's
point is the mesh mess, which is annoying when you try to use ipv6 for
day to day use, especially for interactive ssh access.

tim

---

From: Pekka Savola <[email-masked]>
Date: Tue, 24 Sep 2002 17:52:22 +0300 (EEST)

> both imbed topological routing information in the address prefixes.

Well.. I made a presentation in a conference about "IPv6 routing and
addressing" where I showed their connection so they aren't with current
policies.. but for all practical purposes they're not.  Let me elaborate a 
bit.

Routing is completely independent of the addressing in the sense that I 
can advertise any prefix I want in the routing protocols (in this case, 
BGP).

Therefore, when I receive a 2001::/16 or 3ffe::/16 prefix, there is *no* 
way to say "2001" is production while "3ffe" is not.  Indeed, both 3ffe 
prefixes are advertised over production backbones, and 2001 prefixes over 
6bone.

The only connection in routing/addressing is that currently there is a  
widely-implemented prefixlength restrictions in place everywhere.  This 
restricts a bit what you can do with your addresses.  But if you're a 
major player like an ISP, that's entirely up to you (and your neighbors).
 
> IPv6 backbone active in Asia, Europe and North America...

Market speak, I'd say.

The more important point is, how many other IPv6 backbones they connect
to.  Private walled gardens help no one.

When you can reach e.g. 80-90% of all IPv6 users through commercial-grade
networks, we're in a very good shape.. that's not happening yet.

---

From: Keith Moore <[email-masked]>
Date: Tue, 24 Sep 2002 13:22:32 -0400

> both imbed topological routing information in the address prefixes.

that, and the best strategy we know of for making it scale is to
do topological aggregation.   

which is not to say that we couldn't have addresses that were completely
independent of topology - we'd just need to propagate a rather large 
address-to-location mapping table to all of the routers along with the 
routing table.  

Keith