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

From: "Steven M. Bellovin" <[email-masked]>
Date: Tue, 11 Jun 2002 11:05:25 -0400

In message <[email-masked]>, [email-masked]
m.com writes:

>So, to make SL work, we need changes to the DNS name server, changes
>to the resolver, routers to advertise the scope zones, hosts to
>learn the scope zones from routers and include them on DDNS
>registrations and use them in making routing decisions, updates to
>routing protocols, IANA needs to manage a new zone scope naming
>space, and who knows what else.
>
>Wouldn't it make sense to hold off on SL until we at least have
>some proposals on the table which describe the changes necessary to
>make SL work, at which time we could have a discussion on the
>technical merits of the proposal(s)?  Until that time, though, the
>SL unicast address space should either be reserved or moved to
>experimental.
>

I think this is the key point.  Regardless of the possible benefits of 
site-local addresses -- and I'm willing to withhold judgment on that 
point -- we don't know in detail how to make them work.  At a minimum, 
we need changes in routing and the DNS.  We may need new global 
namespaces as well, with all that implies for co-ordination and 
administrative overhead.

		--Steve Bellovin, http://www.research.att.com/~smb (me)
		http://www.wilyhacker.com ("Firewalls" book)

--------------------------------------------------------------------
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: Tue, 11 Jun 2002 12:59:44 -0400

> namespaces as well, with all that implies for co-ordination and

and given that all that stuff is "needed", and the costs associated not just
with this infrastructure but also of the increased burden on applications,
it ought to raise a strong suspicion that SL addresses are not worth the cost.

Keith

---

From: Markku Savela <[email-masked]>
Date: Tue, 11 Jun 2002 20:16:40 +0300

Well, I've not yet fully gotten into issue of getting site local
addresses from the name server, but...

... I assume when a resolver gets an address as a reply from the DNS,
it will supply the scope id from the interface which the DNS reply
came in. And, this applies to all scope levels (consider, multicast
groups could be in DNS too, with any of the 15 or so scope levels).

Now, for this to truly work, the DNS server does need some extra code
to deal with non-global scopes. The database must include the scope in
some form (for example interface name), and it must not return replies
of non-local addresses to other than indicated interface.

However, this seems to be a local implementation issue, which does not
change the protocol on the wire.

I think similar considerations apply to routing protocols: the zone
ids are always available from the interface which the packet is
using. Of course, some system admin must configure them to the
interface first.

---

From: Keith Moore <[email-masked]>
Date: Tue, 11 Jun 2002 14:12:59 -0400

This is just insane.

DNS is supposed to return the same results for everyone, not try to
guess whether the client can use a particular address.  The DNS server
isn't even aware of where the client is attached to the net, nor about
how many interfaces it has or where they're connected.

It's simply not acceptable to add scope ids to addresses.

Keith

---

From: Markku Savela <[email-masked]>
Date: Tue, 11 Jun 2002 21:22:46 +0300

> From: Keith Moore <[email-masked]>

> how many interfaces it has or where they're connected.

Probably right, but sadly similar thing happens already with IPv4
10-nets. The local ISP's provide only 10/8 addressess (with NAT), and
their DNS returns 10-addresses. Now if your host is connected
simultaneously to two ISP's (for example first to local ISP to get
access, and then virtually through a VPN tunnel to remote intranet,
which also SADLY happens to use 10-addresses and own DNS servers).

In this case you have to do similar "scope-id" things with IPv4
addresses, route queries to different DNS servers depending whether
application is using ISP's addresses or intranet addresses (yes, host
implementation GETS difficult).
--------------------------------------------------------------------
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: Randy Bush <[email-masked]>
Date: Tue, 11 Jun 2002 11:29:50 -0700

> guess whether the client can use a particular address.

you may want to look a tdraft-ietf-dnsop-dontpublish-unreachable-03.txt
and why and what it is trying to achieve.  essentially, everyone does
not have the same view of the address space.

randy

---

From: Keith Moore <[email-masked]>
Date: Tue, 11 Jun 2002 14:41:30 -0400

it seems obvious in hindsight that private addresses were a mistake
in IPv4.  so the fact that they exist, and that we now find it necessary
to warn people to not advertise them in DNS, shouldn't be cited as
a justification to make further mistakes which will then necessitate
further kludges to DNS.

as for the idea that we need SL addresses for nonconnected sites -
far better that we establish a new prefix for those addresses
and allow IANA or the RIRs to dole out address blocks from that
space, with the caveat that they will never be advertised on the 
public Internet (actually they should be filtered).   they will
still be useful for private connections between networks, and
giving everyone a unique prefix whether they are connected or not
will eliminate a big motivation to use NAT in IPv6.

granted that still creates a kind of scoped address, but at least
it's globally unique.  I think it would be better to advertise
addresses with non-routable prefixes in DNS than to advertise SLs
in DNS, with all of the kludges that this would entail.  at least 
a host or app should be able to tell rather quickly that a prefix is 
private and that it doesn't have a route to it.

Keith

---

From: Randy Bush <[email-masked]>
Date: Tue, 11 Jun 2002 12:02:34 -0700

> a justification to make further mistakes which will then necessitate

agree.  so let's get rid of these kinky scoped addresses in v6

randy

---

From: Alain Durand <[email-masked]>
Date: Tue, 11 Jun 2002 12:13:20 -0700

> agree.  so let's get rid of these kinky scoped addresses in v6

That would certainly make life in v6 land much simpler.
And anything that makes it simpler ease transition worries.

	- Alain.

---

From: [email-masked]
Date: Wed, 12 Jun 2002 07:54:49 +1000

> namespaces as well, with all that implies for co-ordination and 

	Well we already have a global managed namespace.  The
	scopename would be just be a name within the namespace
	already delegated to you.

	host1.example.com. SA <SL-IPV6-address> site1.example.com.
	host1.example.com. SA <SL-IPV6-address> site2.example.com.
	host1.example.com. SA <global-IPV6-address> .

	host2.example.com. SA <SL-IPV6-address> site2.example.com.
	host2.example.com. SA <global-IPV6-address> .

	host3.example.com. SA <SL-IPV6-address> site1.example.com.
	host3.example.com. SA <global-IPV6-address> .

	Here host2.example.com and host3.example.com would have to
	communicate using global addresses while host1.example.com
	and host2.example.com could choose to use there site2.example.com
	SL address and host1.example.com and host3.example.com could
	choose to use there site1.example.com SL address.

	Mark
	
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]
--------------------------------------------------------------------
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: Wed, 12 Jun 2002 16:05:42 +0700

Date:        Tue, 11 Jun 2002 11:05:25 -0400
    From:        "Steven M. Bellovin" <[email-masked]>
    Message-ID:  <[email-masked]>

  | I think this is the key point.  Regardless of the possible benefits of 
  | site-local addresses -- and I'm willing to withhold judgment on that 
  | point -- we don't know in detail how to make them work.

That's true.    Te question is really should we go ahead and figure
out the answer, or should be just decide that we don't know the answer
today, and consequently, we will delete the mechanism, so even if someone
does work out the answer tomorrow, it is all irrelevant, because there's
no way to use it left in the protocols any more.

There is way too much of the latter in all areas of the IETF these days.
I don't know the answer to this today, so I will forbid it forever.

  | At a minimum, we need changes in routing and the DNS.

No.   At a minimum we need changes to nothing at all.   Not changing
routing might alter the way SL addresses get used - effectively imposing
DMZ's between sites.   With that, a SL address (to routing) is simply
the same as any other address, scopes are irrelevant (as there's never
two different ones touching any node).   The most we need is a way to
filter routing information passed around - and that we already have.

The DNS needs no changes whatever we do.   We simply never put SL addresses
in the DNS, no matter what.   There seems to be this fixation that the
DNS is the only thing that can ever be used to translate between names and
addresses (some of the side discussion on addr->name translations is
showing that).   People, the DNS didn't always exist, and we still managed
name to address translations!   While I wouldn't advocate going back to
host tables as a translation method - the fact that there was once a world
with no DNS shows that it is possible to do things other ways.

I still believe that the right way to use SL addresses (other than in
disconnected sites, where SL is all that exists, and they can go in the
local private disconnected DNS with no problems at all), is for an app
for which use of a SL address makes sense, to indicate that to the
resolver when it does its name lookup.   The resolver then looks up the
DNS (the normal way) and gets back global addresses (and only global
addresses).  Then using (one of the) node's local site local addresses,
the resolver sends a packet to the global address(es) received - a ICMP
node information, asking for the node's site local addresses (on the
interface the packet arrives).   If there is no site border in the way
it will get a reply with the relevant site local addresses included.
It then simply places those addresses in the information it returns to
the application (most likely inserting them ahead of the globals in the
list returned, but an API option could indicate to return only the
site locals when any are available, suppressing global addreses).

>From this we get site local addresses to use, and there's none of them
at all in the DNS - the cost is a couple of extra packets when the
application translates its names.   And only for applications that have
indicated that using SL addresses makes sense.   That really means only
for long lived apps, as the main reason for using SL addresses (disconnected
sites aside) is so a renumbering event wouldn't affect the connection.
If the connection isn't likely to last longer than old addresses would be
in deprecated state, then using SL addresses instead of globals makes no
sense.   Hence apps that have short lived connections typically (which
means less than multiple hours - perhaps even mode) would never do this.
No extra overhead at all for http, smtp, ...

The other implication from this, of course, is that all nodes on the
global internet (that are ever to be reached based upon their names)
would be required to have global addresses, as that's all the DNS ever
returns.   That's fine - let's get rid of the absurd notions that
having only a private address (1918, SL, anything else) has any benefits
at all - they don't - all they do is provide restrictions (not beneficial
ones, they can't be relied upon).    Nodes that are never to be named
could have SL addresses only, though personally I don't see the point.

  | We may need new global 
  | namespaces as well, with all that implies for co-ordination and 
  | administrative overhead.

Not for SL addresses as defined now.   Some proposed modifications of SL
addresses might need such things (or might not, NUSLA's didn't), but this
part is certainly irrelevant for now.

SL addresses are just fine.   More work is needed on them for sure, to
make them even more useful, and suggesting to people that until the
implementations better support them, they should consider very carefully
before enabling the things, is all just fine.   But there's no reason at
all to be even considering deleting them.

kre

---

From: Randy Bush <[email-masked]>
Date: Wed, 12 Jun 2002 08:09:47 -0700

> no way to use it left in the protocols any more.

yes, otherwise we would have a mocha (my favorite flavor) ice cream
mechanism with no currently known way to use it to make ice cream.
but some day, we might know how, and who knows, this mechanism might
be a good way to implement it.

see
    http://xp.c2.com/DoTheSimplestThingThatCouldPossiblyWork.html
and
    http://xp.c2.com/YouArentGonnaNeedIt.html

randy