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

From: [email-masked]
Date: Fri, 14 Jun 2002 09:42:00 -0400

On Friday, 06/14/2002 at 02:13 ZE7, Robert Elz <[email-masked]> wrote:
>   | Exactly.  The entire IPv6 code base would be reduced in size and more
>   | importantly the decision constructs and data struct lookups which is
a
>   | big win.
>
> Can you actually justify that, or is this just more nonsense?
>
> Remember that as long as link locals stay, and as long as their are
> apps that use them (doesn't BGP peering use LL's these days?) then all
> of the system support for scoped addresses has to remain, including the
> data structs, API's, ...
>
> What you would gain by removing them is the change from testing
> fe80::/9 into testing fe80::/10 when deciding if the address you
> have is one that also needs a scope.   Beyond that it is essentially
> all the same if scopes are involved - are the scopes for source &
> destination the same, etc - regardless of whether it is fe80::/10 or
> fec0::/10 that the address happens to be.
>
> So, just where is this saving?

I can think of plenty of savings in my protduct if I restrict it so that
it only supports a single site.  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.  Support for this takes new configuration (to
define the multiple sites) and new code within the stack.

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 and resolver, routing daemons, and potentially applications.  While
I have no doubt all of this can be architected and made to work, but it
isn't here today and it isn't going to be free and, I suspect, neither is
it going to be easy.

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.  I no longer need to support multiple "logical"
routing tables, and my DNS resolver doesn't need to understand which
interfaces are connected to which sites.  I don't have to update RIP and
OSPF to add support for multiple sites.  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.

Link-local, on the other hand, is different.  I don't need to use the
routing table in selecting where to send the packet, as the destination
must (by default) be on a directly attached link.  I simply need to
identify the link onto which to place the packet, and can use the scope
zone to index into the link on which the outgoing packet needs to be sent.
No route table lookups are used or required, and no changes to the routing
table are needed.

So, from my perspective, the complexity of site-local and link-local are
quite different.  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.

Roy

---

From: Robert Elz <[email-masked]>
Date: Fri, 14 Jun 2002 21:48:11 +0700

Date:        Fri, 14 Jun 2002 09:42:00 -0400
    From:        [email-masked]
    Message-ID:  <[email-masked]>

  | 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-masked]
--------------------------------------------------------------------

---

From: Bill Sommerfeld <[email-masked]>
Date: Fri, 14 Jun 2002 11:57:49 -0400

> where the biggest savings from eliminating or restricting site locals

Hosts have routing tables, too.

A host connected to multiple sites needs nearly all of the mechanisms
that a multi-site router needs.

   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.

I don't think such a requirement will be meaningful because "node" is
underspecified -- someone will argue that you can meet this
requirement in a single box running a single OS image by supporting
two virtual nodes connected by a virtual DMZ, and we're back to where
we started.

					- Bill

---

From: Randy Bush <[email-masked]>
Date: Fri, 14 Jun 2002 09:02:35 -0700

> then the approach to SL's that required a DMZ between sites (no
> nodes in 2 sites) may become the standard way to operate.

nice way to sell un-needed extra routers

randy

---

From: Robert Elz <[email-masked]>
Date: Fri, 14 Jun 2002 23:24:32 +0700

Date:        Fri, 14 Jun 2002 11:57:49 -0400
    From:        Bill Sommerfeld <[email-masked]>
    Message-ID:  <[email-masked]>

  | Hosts have routing tables, too.

Yes, but it is the routing protocols where the worst of the extra
mechanism is required I believe, and hosts generally don't, or
shouldn't, be running those.

  | I don't think such a requirement will be meaningful because "node" is
  | underspecified -- someone will argue that you can meet this
  | requirement in a single box running a single OS image by supporting
  | two virtual nodes connected by a virtual DMZ, and we're back to where
  | we started.

I didn't mention requirement - in general unless there's a good reason,
I don't like requirements, I like flexibility.

If someone wants to set up something like that (or simply support what
we currently define as the way SL's work) then fine - the issue here
remember is the apparent implementation complexity of making all that
work properly.   Anyone who can cope with all of that ought to be free
to do so, they're not going to harm anyone else.  Whether they do it
using a virtual DMZ, or any other way, shouldn't bother us.

kre

---

From: Randy Bush <[email-masked]>
Date: Fri, 14 Jun 2002 09:47:40 -0700

> Hosts have routing tables, too.

hosts have forwarding tables.  a very few end hosts have routing
tables.  of those which have routing tables, a very few of those,
usually researchers' boxes, learn more than default.

randy

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 14 Jun 2002 14:23:26 -0400

>shouldn't, be running those.

There is additional complexity in a multi-sited host, even if it doesn't
forward or run routing protocols.

Even if a multi-sited host has no routing protocols and a primitive
forwarding table (i.e. an ICMP redirect cache), there will still be
increased implementation complexity.  The multi-sited host will
need to maintain multiple forwarding tables (one for the global 
scope, and one for each attached site), will need to choose the
correct table as part of the next-hop lookup for outbound traffic,
and will need to make sure that ICMP redirects are applied to the
correct table when received.

And what do we actually get for this added complexity?

Margaret

---

From: Robert Elz <[email-masked]>
Date: Sun, 16 Jun 2002 08:29:10 +0700

Date:        Fri, 14 Jun 2002 14:23:26 -0400
    From:        Margaret Wasserman <[email-masked]>
    Message-ID:  <[email-masked]>

  | Even if a multi-sited host has no routing protocols and a primitive
  | forwarding table (i.e. an ICMP redirect cache), there will still be
  | increased implementation complexity.  The multi-sited host will
  | need to maintain multiple forwarding tables (one for the global 
  | scope, and one for each attached site), will need to choose the
  | correct table as part of the next-hop lookup for outbound traffic,

Yes, and it also needs to do that for link local addressing as well.

That's the point I am trying to make - not that site locals are free,
but that they're not all that expensive given that almost all the same
mechanism is required for link locals anyway.   The insides of the
routing processes are the one major exception (as link locals never
participate in those).

  | and will need to make sure that ICMP redirects are applied to the
  | correct table when received.

I'm not sure it isn't possible in some obscure setups to get redirects
for link locals, which would require just the same - but in any case,
the interface (which is a more specific form of the scope) needs to be
checked when processing redirects in all cases, to make sure that a
redirect is coming from a router on the link that you're sending the
packets to for the destination involved (the redirect will be from a
link local addr, which should normally be the same one as the LL
addr of the next hop for the route, and the LL addr has scope already,
and is a subset of a site scope).

  | And what do we actually get for this added complexity?

I think this has been answered enough.    People are ignoring the
benefit as no-one is actually being made to renumber their IPv6
sites currently.

When Bob Fink made a suggestion on the 6bone list to change the
6bone addresses (the prefix length actually) I suggested also taking
back all the current assigned prefixes, and reassigning them using the
new rules, just so everyone (using 3ffe::/15 anyway) would actually
experience renumbering their nets - from which we could perhaps learn
something.

But people are still pretending (hoping) that no-one is ever going to
have to renumber their nets, and so don't want to actually test any of
this part of IPv6.    The desire to do away with SL is based upon much
the same misconception.   The costs are obvious to implementors, and
the benefits are currently invisible.

kre

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 17 Jun 2002 11:09:28 -0400

>Yes, and it also needs to do that for link local addressing as well.

This does not match my understanding.  

A link-local address is incomplete, as a destination for traffic, without 
including the zone ID.  That zone ID unambiguously identifies which 
interface should be used to send the traffic, so there is no need to 
perform any sort of routing look-up for link local traffic -- just send 
it out the indicated interface.

>for link locals, which would require just the same - but in any case,

I don't think that its ever valid to send a redirect for a link-local 
address.  I'm not quite sure, though, what you are supposed to do if you 
receive one.

Margaret

---

From: Robert Elz <[email-masked]>
Date: Tue, 18 Jun 2002 00:28:16 +0700

Date:        Mon, 17 Jun 2002 11:09:28 -0400
    From:        Margaret Wasserman <[email-masked]>
    Message-ID:  <[email-masked]>

  | A link-local address is incomplete, as a destination for traffic, without 
  | including the zone ID.

As is a site local, yes.

  | That zone ID unambiguously identifies which 
  | interface should be used to send the traffic,

Does it, always?   I would have agreed, but I have seen comments from
others about links to which there are multiple interfaces connected,
so I'm not sure this is actually correct.   That is, assuming what
I understood from those messages is anything like correct.

There's a draft on that stuff, isn't there?  Actually, "was" seems to
be more correct, it looks to have expired a couple of weeks ago.

kre

---

From: Robert Elz <[email-masked]>
Date: Tue, 18 Jun 2002 00:24:19 +0700

Date:        Mon, 17 Jun 2002 09:03:08 -0700
    From:        Arthur Kepner <[email-masked]>
    Message-ID:  <[email-masked]>

  | - The ICMP Target Address is either a link-local address (when
  |   redirected to a router)

That parenthesized restriction is the interesting case, when a
redirect redirects to a host, rather than a router.

kre

---

From: Arthur Kepner <[email-masked]>
Date: Mon, 17 Jun 2002 09:03:08 -0700

On Mon, 17 Jun 2002, Margaret Wasserman wrote:

> ....

From 2461, Section 8.1:

8.1.  Validation of Redirect Messages

A host MUST silently discard any received Redirect message that does not
satisfy all of the following validity checks:

....

- The ICMP Target Address is either a link-local address (when
  redirected to a router) or the same as the ICMP Destination
  Address (when redirected to the on-link destination).

--

Arthur

---

From: JJ Behrens <[email-masked]>
Date: Tue, 18 Jun 2002 15:11:38 -0700

<snip/>
> benefit as no-one is actually being made to renumber their IPv6
<snip/>

Please correct me if I'm wrong, but doesn't DNS help here a lot?  It's trivial
to update the prefix of a bunch of boxes in DNS.  Perhaps the only critique of
this approach concerns very long-term connections.

Best Regards,
-jj

-- 
Users of C++ should consider hanging themselves rather than shooting their 
legs off--it's best not to use C++ simply as a better C.
--------------------------------------------------------------------
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, 18 Jun 2002 20:04:16 -0400

> Please correct me if I'm wrong, but doesn't DNS help here a lot?  

DNS is only part of the picture.  prefixes and addresses are stored
in lots of places besides DNS - e.g. running applications, stacks, 
host configuration files, routers, firewalls, network management 
stations, and traffic monitors.    There's no good mechanism for
updating all of these, and DNS can only solve part of the problem.

for instance there's an inherent conflict between a host or server
needing to assert its identity or service name (as many server 
hosts do) and the network trying to assign addresses (or even
prefixes) to hosts (as many networks do).  a reasonable renumbering
solution needs to support some hybrid of these - neither 
extreme is inherently the right approach.

Keith