Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols

From: Ralph Droms <[email-masked]>
Date: Sun, 23 Jun 2002 17:44:17 -0400

I agree 100% with Micehls' point - assigning unique IDs to sites for use in 
site-local addresses moves the site-local addresses into a globally 
routable address space, with the additional feature that those addresses 
are provider independent.  The result would be an address space that is 
site-local by (potentially unenforceable) executive fiat rather than by 
technical design.

- Ralph

At 08:10 AM 6/21/2002 -0700, Michel Py wrote:
>If I understand correctly, what you are advocating for is SL addresses
>that are globally unique (by using a mechanism such as embedding the ASN
>in the higher bits). [...]
>
>There is one thing that worries me about such a scheme: it does in fact
>give a PI address to everybody. It is to be feared that people using
>these addresses will make arrangements with their upstreams to have
>these leaked in the global table.

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Robert Elz <[email-masked]>
Date: Mon, 24 Jun 2002 21:20:12 +0700

Date:        Sun, 23 Jun 2002 17:44:17 -0400
    From:        Ralph Droms <[email-masked]>
    Message-ID:  <[email-masked]>

  | I agree 100% with Micehls' point - assigning unique IDs to sites for use in 
  | site-local addresses moves the site-local addresses into a globally 
  | routable address space, with the additional feature that those addresses 
  | are provider independent.

Yes, as I've said - the proposals to stick IDs into SL addresses keeps
getting shot down.

I'm not sure that I think a lot of an argument that goes "well, someday
someone might misuse it, so we'd better not have it at all", but that's
not important for now.

What matters here, is that "global" addresses from a non routable prefix
have all of the same problems (they are identical, other than the bit
pattern that makes up the prefix).

kre

---

From: Keith Moore <[email-masked]>
Date: Mon, 24 Jun 2002 10:20:59 -0400

> site-local by (potentially unenforceable) executive fiat rather than by

this sounds like a feature to me, because it would allow hosts using 
such addresses to have their traffic routed between sites without NAT.

private addresses were a bad idea; we should not repeat them in v6.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 24 Jun 2002 16:51:46 +0200

> such addresses to have their traffic routed between sites without NAT.

Not in the real world; these addresses wouldn't be routable because
they won't aggregate.
> private addresses were a bad idea; we should not repeat them in v6.

Indeed. That's not what SL addresses are, fortunately. 

  Brian

---

From: Keith Moore <[email-masked]>
Date: Mon, 24 Jun 2002 11:04:57 -0400

> Not in the real world; these addresses wouldn't be routable because

they will be routable between private networks using bilateral agreements.

one of the common use cases for NAT in v4 is to map between two 
or more networks that use private (thus overlapping) address space.
if we want to avoid NATs in v6 we need to ensure that v6 addresses
never overlap; that sites can get unique v6 addresses whether or
not they're connected to the global internet.

Keith

---

From: Michael Thomas <[email-masked]>
Date: Mon, 24 Jun 2002 08:11:48 -0700 (PDT)

> private addresses were a bad idea; we should not repeat them in v6.

   So it seems to me that what's at issue here is what
   is the lesser of evils. I think one thing which we should
   all be able to agree about is that local addresses 
   regardless of original intent will be used to access
   global address space. The basic problem here is 
   renumbering -- and the fact that people don't
   want to do that. Since, its a tragedy of the commons
   problem, there is simply nothing we can do
   about this unless we create the Address Police
   who can arrest and execute those recalcitrant
   addressing scofflaws. 

   Thus, we have the two options: site locals which
   are actually globally unique could relatively
   easily be made globally routable by simply
   advertising the prefix. The downside here is
   prefix aggregation doesn't happen. For large
   sites, this is probably not a big problem, but
   for small sites it could be a huge issue.
   The other alternative is essentially NAT/ALG's.
   We all know how that works, and what it does
   to the net.

   The thing I don't understand is whether the
   address aggregation problem introduced by a
   new class of globally unique addresses is
   really any worse than the existing problems
   with route aggregation, and specifically about
   mobility and multihoming. It's quite possible
   that we could make things significantly worse
   by introducing a new class of routing prefixes,
   but as far as I understand, the ultimate fix
   for routing table explosion isn't especially
   well understood, and it may require its own
   set of draconian measures *regardless* of
   site locals. On the other hand, we know for
   absolute certain that NAT's completely pooch the
   end to end principle and are well known evil.

   I guess I come down slightly in favor of
   avoiding the known evil in favor of the 
   potentially unknown evil, but as they say,
   ignorance is bliss.

		Mike

---

From: Keith Moore <[email-masked]>
Date: Mon, 24 Jun 2002 11:22:07 -0400

>    is the lesser of evils. 

I think this is a bit over-simplistic.  Just because an address 
prefix is globally unique does not mean it will be widely advertised 
in routing tables, especially when such prefixes are easily 
distinguished from globally-routable prefixes.

Keith

---

From: Keith Moore <[email-masked]>
Date: Mon, 24 Jun 2002 12:02:24 -0400

> someone might misuse it, so we'd better not have it at all", but that's

I don't think much of such arguments either  To me arguments of the form
"people need to solve problem X, and if we don't give them a way to do it
that is friendly to the network they'll do it in a way that might not
be friendly, so we'd better solve problem X" are much more convincing.
There are several problems meeting this description - renumbering and
routing between private sites being two that are handy.

> pattern that makes up the prefix).

I think this is right.  actually I think SLs with a site-id may actually
be preferable than a global with a non-routable prefix, because the SL
may be more easily distinguished from a normal address than the global.

mainly I want a solution to the problem.  apps need to be able to do 
address referrals and right now the algorithm for selecting which address 
to use is little better than a guess.  anything we can do to make this 
faster or more reliable is a good thing, and SLs with site-ids are better 
for this than SLs without site-ids.

Keith

---

From: Abdul Basit <[email-masked]>
Date: Mon, 24 Jun 2002 18:21:12 -0500 (CDT)

Hi,

 I was just wondering whether we can put the 'stateless
address auto-configuratition' schema inside the dns server somehow
so it will the part of dns itself instead of a seprate
router advertisement daemon.

 in this way, we will be able to dynamically assign the ipv6
address along with some sort of name as it is easy to remember
the name and with rapid growth of devices in your network
its almost impossible to manually configure dns for each and e very
device (cell phones )..

 p[leae let me know if theren is already some mechanism there
to solve this problem ?

- basit

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 24 Jun 2002 17:04:57 -0700

>  p[leae let me know if theren is already some mechanism there

RFC 3007

---

From: Pekka Savola <[email-masked]>
Date: Tue, 25 Jun 2002 09:06:01 +0300 (EEST)

http://search.ietf.org/internet-drafts/draft-kitamura-ipv6-name-auto-reg-01.txt
http://search.ietf.org/internet-drafts/draft-gopinath-ipv6-hostname-auto-reg-01.txt

-- 
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: "Tony Hain" <[email-masked]>
Date: Wed, 26 Jun 2002 14:28:58 -0700

> site-local by (potentially unenforceable) executive fiat

And if the point is to end up with global addresses, we already have a
mechanism for those, so modifying SL to make them globally unique does
nothing. If the goal is provider independent space, I agree and have a
couple of drafts that talk about why that kind of space is required and
one possible way to scale it for routing.

Tony

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 26 Jun 2002 14:41:17 -0700

> pattern that makes up the prefix).

Maybe the way to solve this is to take the 'must be 0' bits and define
them as 'locally administered' with a clear note that FE00::/8 will be
blocked on the public net. This would allow sites that want the hassle
of coordinating multiple private interconnects to do whatever they want
(since they will anyway if the implementations allow it), without
leaving any expectations that these are in any way globally unique.

Tony

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 26 Jun 2002 14:50:39 -0700

Keith Moore wrote:
> ...

I don't agree with the stated requirement. While I agree that apps need
a way to do referrals, what says that has to be done using addresses
rather than name strings? Clearly referrals using IPv4 addresses can't
work today, so any app that needs to do a referral will have to use a
name. What about IPv6 changes that? Is it simply to save the receiver of
the referral from having to resolve an address? If so that is a bogus
application design, because the referrer can't know that it has all the
possible addresses for the target. Even if it got the full list from
DNS, it can't know that the target didn't update DNS since it retrieved
the list. In short you are looking to optimize the wrong part of the
system and the resulting application failures will leave it no better
than it is in an IPv4/NAT world.

Tony

---

From: Keith Moore <[email-masked]>
Date: Wed, 26 Jun 2002 18:02:56 -0400

> rather than name strings? 

first we would need a naming system that is fast and reliable.

> Clearly referrals using IPv4 addresses can't
> name. 

no they won't.  clearly you live in a fantasy land where DNS always works
perfectly and lookups take only microseconds.  in the real world, DNS
fails to provide the correct answer a significant part of the time and
lookups often take 10 seconds or more.

> What about IPv6 changes that? 

nothing about IPv6 changes that, except that IPv6 has the built-in
expectation that an app may have to deal wth multiple addresses and
somehow choose one of those addresses without any knowledge as 
which ones are more likely to work than others.

and you think *I'm* in a fantasy land.  

> Is it simply to save the receiver of
> application design, 

who made you the arbitrer of good application design?  who are you to
dismiss applications' real requirements for low latency and high reliability?

> because the referrer can't know that it has all the
> possible addresses for the target. 

the referrer can never be sure that it has all of the possible addresses
for a target, no matter where they were obtained.  DNS isn't the sole
authority on such things, and even DNS is sometimes two-faced.

>  In short you are looking to optimize the wrong part of the
> system 

I'm trying to make IPv6 a viable alternative for apps that don't work
well under IPv4+NAT.  Part of the problem in doing so is that the address
selection burden imposed by IPv6 is very similar to problems you get
when trying to make distributed apps work with NAT.

> and the resulting application failures will leave it no better

that, indeed, is my concern.

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 26 Jun 2002 15:28:01 -0700

> first we would need a naming system that is fast and reliable.

and referrals of addresses trades off reliability for a little speed. As
you note here, some DNS servers are two faced, so how does referring
addresses actually work in that case? The referring node would have to
know the entire topology including the DNS server boundaries to be able
to send the right addresses (if it could even get a complete list). It
would be much simpler for the app to send the name string and let the
receiver find the traget address list from its own topological
perspective.

> lookups often take 10 seconds or more.

So apps should pass around a potnetially bogus list of addresses? I am
all for multi-party apps, but fixing the real problem with DNS seems
like a better approach than a hack that will end up failing anyway.

> and you think *I'm* in a fantasy land.

trying to build complex topological information directly into the app
will fail more often than not. Pass name strings and follow
draft-ietf-ipv6-default-addr-select-08.txt. It will not be as fast, but
it will be more reliable.

---

From: Keith Moore <[email-masked]>
Date: Wed, 26 Jun 2002 18:46:47 -0400

> and referrals of addresses trades off reliability for a little speed. 

when you're trying to complete a phone call, or trying to coordiate
between hundreds of processes in a distributed computation, a 10 
second delay in your message being transmitted due to a DNS lookup 
is simply not acceptable.  (heck, it's not even acceptable when
browsing the web from over a cell phone...)

> As

You're missing something important, which is that the DNS server doesn't
have a much better idea of which addresses work for the app than 
the app itself does, especially given that the DNS query might have
been routed through one or more intermediaries in different parts of the
topology.  Two-faced DNS works only in very limited cases; it's not a 
general solution.  Regardless of whether the app gets its addresses
from DNS or a referral from a peer, it still has to guess about which
address is best.

> So apps should pass around a potnetially bogus list of addresses?

so DNS should pass around a potentially bogus list of addresses
while apps shouldn't?

DNS is just another way of doing address referrals.  It works well
in some cases, less well in others.  It never has been the only way 
to get addresses for a resource.

>  I am

you can't fix some of those problems, they're fairly fundamental
consequences of DNS's design.  for instance, the wide variation in
response times seems to be a direct result of having DNS widely 
federated and widely distributed and the resulting lack of any 
reliable RTT estimates in advance of many queries (so the party doing the 
querying doesn't know when to time out or fail over).  a lot of the 
unreliability (at least, last time I looked) seemed to be due to lots 
of zone administrators not knowing how to configure slave servers or 
glue records properly or to update the sequence numbers.  

this is what happens when you let everybody run their own servers.  
not that it was a bad decision overall, but it does make the idea 
that DNS is the only way that a app should obtain addresses sort 
of dubious.

> it will be more reliable.

some apps will be better off doing this, but this is not a tradeoff 
that you are qualified to make for all apps. 

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 26 Jun 2002 19:27:33 -0400

> nothing. 

where in the world do you get the idea that all interconnection
between IP networks is done using the public Internet? 

Keith

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 27 Jun 2002 09:32:55 +0200

Michael Thomas wrote:
...
>    mobility and multihoming. 

I've been staring at this for three days, and I think the
answer (in the current state of the BGP art) is "yes", or
at least the risk that it is "yes" is unacceptably high.
Just stuffing some probably-unique bits into a SL is not
going to generate aggregatable addresses; it's going to
generate entropy in the routing table.

>    ...It's quite possible
>    site locals. 

True, but let's not make things even worse in the meantime,
by inventing non-aggregatable pseudo-global local addresses.
We don't need them; we've got aggregatable real global addresses,
and we can perfectly well use them for the sort of bilateral
private routing setups that Keith mentioned.

Michel Py wrote:
> >> It is a terrible responsibility to embed everyone-gets-one
> >> PI-address in the addressing architecture. 
> 
> > Keith Moore wrote:
> > why do you think it's not an equally terrible responsible
> > to say "nobody gets a global address prefix unless it's
> > tied to a provider"?
> 
> I don't. What part of my postings makes you think so? Tony and I are
> proposing schemes that are aggregatable and that are not tied to a
> provider.

For the record, you've yet to persuade me that these schemes are
aggregatable in the real world of competitive ISPs. 

   Brian

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 27 Jun 2002 08:05:14 -0700

> aggregatable in the real world of competitive ISPs.

I understand the concern, but it comes down to a matter of cost/benefit
tradeoff. If a geo scheme turns out to be cheaper to maintain than an
ever expanding table full of holes, it will be deployed. The task at
hand is finding *any* scheme that will create provider independent
addresses in an operationally sound way.

Tony

---

From: Keith Moore <[email-masked]>
Date: Thu, 27 Jun 2002 12:21:38 -0400

> generate entropy in the routing table.

the premise has to be that SL + site-ids are NOT going to 
get advertised to the public routing tables.  if there's not
a mechanism for preventing this now, we need to invent one.
but that's not a reason to force or even encourage sites 
to use non-unique prefixes, especially when SLs without 
site-ids cause problems for distributed applications.

SLs with site-ids might be acceptable, but we really need 
to get rid of SLs without site-ids.

> private routing setups that Keith mentioned.

please explain how my private network can get a aggregatable real
global address when it doesn't connect to the public internet.

Keith

---

From: Michael Thomas <[email-masked]>
Date: Thu, 27 Jun 2002 09:42:54 -0700 (PDT)

> site-ids cause problems for distributed applications.

   Define "public". Given the peerwise distribution
   of routes, isn't the distinction of "public" 
   rather arbitrary? If I convince my provider to
   route my site local prefix across their backbone
   (but not leaked outside their AS's), is that a
   violation? What about if my provider then convinces
   their upstream provider to do likewise to extend
   my reach? Is that public? And how likely is it that
   ISP's would pay attention to any such strictures if
   they figured it was an easy way to build what is 
   for all intents and purposes a VPN of the MPLS
   variety?

	   Mike

---

From: Keith Moore <[email-masked]>
Date: Thu, 27 Jun 2002 12:53:14 -0400

>    for all intents and purposes a VPN of the MPLS

my opinion is that the space in an ISP's routing tables
and the cpu time of their routers belongs to the ISP and
the ISP can (and will) do whatever it wishes with it, as 
long as they keep their agreements.   the fact that these 
are limited resources will quite naturally result in 
pressure to limit the scope of advertisement of 
non-aggregatable addresses. 

Keith

---

From: Randy Bush <[email-masked]>
Date: Thu, 27 Jun 2002 10:01:36 -0700

> non-aggregatable addresses. 

this was what happened back in '93 or '94 when a large isp
had/chose to install pretty serious prefix length filters
to keep their routers from falling over.  much flamage,
even some rational-seeming discussion.  but the point you
make was the bottom line.

randy

---

From: Michael Thomas <[email-masked]>
Date: Thu, 27 Jun 2002 10:12:42 -0700 (PDT)

> non-aggregatable addresses. 

   Right -- unless they can make a buck off of it.
   As I understand it, we don't have anything that
   really approaches a "public network" where global
   routes are just advertised. Whether routes are
   advertised or not is much more of a business
   decision than a common weal obligation. 

   If the business pressures are such that with
   stupid router tricks(tm) you can make more
   money on less infrastructure even though it's
   not a globally healthy thing to do, I think we
   better not delude ourselves. Site locals
   definitely toe this line. 

   Alas, the urge to overlay networks seems too
   strong. "What holds up the network? Why, it's
   networks all the way down!"

		  Mike

---

From: Keith Moore <[email-masked]>
Date: Thu, 27 Jun 2002 13:31:56 -0400

>    Right -- unless they can make a buck off of it.

as much as I appreciate the limitations of laissez-faire
economics, I don't see anything particularly wrong with
it in this particular case.  the fact that ISPs can make
a buck off of selling an entry in their routing table
doesn't mean they can sell significant numbers of additional 
entries - at last not unless a significant breakthrough in
routing computation is discovered (entirely possible, but
I'll believe in it when the router vendors have it in shipping
product).  

the real question is whether ISPs will honor SL prefixes
in the absence of explicit compensation to do so.
My guess (based on current technology) is "no", but they're 
welcome to do so if they can manage to deal with the flood.

also, in the IPv4 world there is a sort of slippery slope -
there is no magical number of prefix bits, and no designated
bit pattern, that distinguishes one kind of network from 
another.   so it requires some justification to block
advertisements of some prefixes of length N while 
honoring advertisements of other prefixes of length N.
and it's easy to have a "what's one more prefix bit among 
friends?" attitude.  But IPv6 does have very visible 
distinctions, and doesn't normally delegate on arbitrary
bit boundaries, which makes it easier for an ISP to push 
back on every prefix in a given category.

Keith

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 28 Jun 2002 12:09:53 +0200

> global address when it doesn't connect to the public internet.

6to4

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 28 Jun 2002 12:11:10 +0200

> SLs without 

Only if they leak, which the scope rules prevent.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 28 Jun 2002 12:15:15 +0200

> welcome to do so if they can manage to deal with the flood.

The great advantage of *not* making them globally pseudo-unique
is that it makes it impossible for ISPs to do this. Again, they
are local and mustn't ever leak; then the whole problem goes away.
We didn't have a problem until somebody started talking about
exporting local addresses. If we stop talking about it, no
more problem.

  Brian

---

From: [email-masked]
Date: Fri, 28 Jun 2002 19:20:59 +0900

>Only if they leak, which the scope rules prevent.

	given the common leakage of net 10 addresses (routes, packets
	with net 10 src/dst, and DNS records), i don't feel confortable
	with "only if they leak".  they will leak.

itojun

---

From: Brian Haberman <[email-masked]>
Date: Fri, 28 Jun 2002 07:23:02 -0400

>         with "only if they leak".  they will leak.

At least now the scoped addressing architecture has rules that prevent
leakage (from the routing and forwarding perspective).  I don't recall
those existing for net 10.

Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 28 Jun 2002 13:12:46 +0200

>         with "only if they leak".  they will leak.

Is that any reason to make them meaningful once leaked? 

   Brian

---

From: Keith Moore <[email-masked]>
Date: Fri, 28 Jun 2002 09:23:01 -0400

> > global address when it doesn't connect to the public internet.

to me "doesn't connect to the public Internet" means that neither
v4 nor v6 connectivity is provided.

also, 6to4 has the built-in assumption that if you use a 6to4 
prefixes then you can actually route to that prefix over the
public IPv4 Internet.  and 6to4 has its own special place
in the address selection rules based on assumptions about how
it is used.  

so it's not reasonable to use 6to4 merely as a means for allocating 
a unique v6 prefix.

---

From: Keith Moore <[email-masked]>
Date: Fri, 28 Jun 2002 09:23:58 -0400

> Only if they leak, which the scope rules prevent.

scope rules don't prevent SLs from being used in referrals, and 
in the current state of things apps may not have any suitable
alternative to using an SL in a referral.
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Keith Moore <[email-masked]>
Date: Fri, 28 Jun 2002 09:26:48 -0400

> exporting local addresses. If we stop talking about it, no

sounds like the ostrich theory of engineering.

ignoring the problem doesn't mean that it will go away, it means
that we'll have an even less reliable network than we do now.

Keith

---

From: Keith Moore <[email-masked]>
Date: Fri, 28 Jun 2002 09:31:24 -0400

> leakage (from the routing and forwarding perspective).  

yes, but not through apps performing referrals (including DNS as just
one example).  ambiguous addresses will leak.  

if we give apps alternatives to advertising ambiguous addresses, then we
can credibly say to apps "don't use ambiguous addresses in referrals"

but right now there are situations where the only addresses available
might be ambiguous, and there's no way for a network to obtain an
unambiguous address short of connecting to the global internet, which
it might not want to do.  we need to fix this, and we can't fix it
by merely tweaking the address selection rules.

Keith

---

From: Keith Moore <[email-masked]>
Date: Fri, 28 Jun 2002 09:47:36 -0400

> Is that any reason to make them meaningful once leaked?

if a host or app can tell "this address doesn't belong on my net" by looking
at it, then that's quite useful - the host or app knows to avoid trying to use
that address merely by looking at it.

or if that's not the case, if the local router can immediately tell "I have
no way to route to this eaddress" and issue an ICMP message, then the host
or app can immediately try another address  - this is far better than having
the network treat such addresses as local and forcing the host or app to 
wait for a timeout.

---

From: [email-masked]
Date: Fri, 28 Jun 2002 22:54:06 +0900

>Is that any reason to make them meaningful once leaked? 

	sorry for confusion, i vote for killing sitelocal entirely.

itojun