Date: Fri, 14 Jun 2002 09:42:00 -0400
From: [EMAIL PROTECTED]
Message-ID: <[EMAIL PROTECTED]>
| I can think of plenty of savings in my protduct if I restrict it so that
| it only supports a single site.
Yes, a router with multiple connected sites is certainly the case
where the biggest savings from eliminating or restricting site locals
would be found.
| Support for simultaneous connectivity to
| multiple sites requires updates to my routing table, so that I now support
| multiple "logical" routing tables, one for each site I'm connected to and
| one for global addresses.
That's one usable technique I imagine. Another might be to simply
have one routing table/algorithm, and mark the addresses with a site
flag (essentially make them 128+n bits long, with the extra n bits at
the most significant end). With that, SL's look to the routing table
just like globals, except (because the marks are only added this way)
you can only ever see routes to them out the appropiate interfaces,
and there's implicit filtering of them when sending routes.
Which method would work out to be more effective/easier I don't know,
but most likely the multiple routing table approach would be better
as it seems to offer more room for better flexibility and control.
| Support for this takes new configuration (to
| define the multiple sites) and new code within the stack.
Yes, that's certainly going to be true, but just how much in comparison
to all the other code that's there, and are there really no other benefits
from cleaning up/enhancing the code? My expectation would be that simply
having done the work to allow multiple routing tables might be a benefit
worth having, regardless of whether they're used for site locals or not.
| But the TCP/IP stack changes are just the tip of the iceberg. Support for
| simultaneous connections to multiple sites requires changes to the DNS name
| server
Please *NO*. The very last thing I want is any mention of a site local
address in any (globally reachable) nameserver, anywhere. If we can't
find a better way to manage them than that, then I'd agree, ditch the things.
But I believe that we can.
| and resolver,
Perhaps some there, yes, but nothing very difficult I suspect.
| routing daemons,
Yes, routing code needs to know about them (that's the same as above isn't it)
| and potentially applications.
Yes, but for the vast majority of applications the extra code they're
going to need is going to be there anyway, as they need to support link
locals, and they're also addresses that need a scope indicator.
Routing has the special property that the meaning of the address needs
to be understood, not just its syntax, for other apps, that's not true,
and any address with a scope is an address with a scope, and needs to
be dealt with in essentially the same way.
Apps need the ability to use link local addresses, even if it is just
so I can "telnet fe80::1%link" or similar, when they have that, they can
also handle scopes in site locals.
Keith's examples of apps that send addresses around, and will get confused
if they're sending addresses to places where they might not be meaningful
are the few cases where the app might care - but again, it needs to care
about LL addresses just as much as SL - the general rule should probably be
to send an address to another node only if its scope is at least as large
as (and the same value if it is limited) the address you're using to talk
to the other node - so it is OK to send a SL to someone if "someone" is
identified by a SL in the same site as the address, but not if they're
identified by a global. I haven't analysed this, but at first glance
it looks safe.
Not many applications are going to care however.
| If I only support connecting to a single site, then I no longer need the
| configuration, nor do I need a site zone index to differentiate between
| two site-local addresses.
That's true, but you need it for LL addresses. Routing would simplify
as LL's don't get routed, but the rest of the complications largely
remain.
| I still need to run a two faced
| DNS, but that is business as usual for customers who want to use a mixture
| of private and public addressing.
It may be, but that is evil - let's just create a better way (not easily
possible for v4 I suspect, but the "magic" properties we have given SL's
in v6 make things much easier).
| And, while it wouldn't pain me to see SL simply
| disappear, restricting hosts to connecting to a single site would
| alleviate much of the complexity surrounding the use of private addresses.
If the complexity is too much to deal with, just supporting a single site
only in your product (whatever it is) would be just fine as far as I'm
concerned. If that becomes common, then the approach to SL's that required
a DMZ between sites (no nodes in 2 sites) may become the standard way to
operate. As I said in an earlier message, I half recollect (but might be
mistaken) that that was the approach I initially supported when SL's were
first created, but now I'm not sure that the savings are really worth the
limitations it imposes.
On the other hand, if common consensus among implementors is that that's the
only way to make things work reasonably, so that's all that gets implemented
in most implementations, then that's going to be enough evidence I think...
kre
--------------------------------------------------------------------
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 PROTECTED]
--------------------------------------------------------------------
