Subject: Re: Regarding site-local addresses

From: Tim Hartrick <[email-masked]>
Date: Mon, 29 Nov 1999 14:22:22 -0800 (PST)

All,

> 
> Yes, we could do that.  This is basically what the site-local prefix does
> today.  I see advantages to establishing it now (stated above) and no
> advantage to waiting.
> 
> In summary, I see many potential uses for site-local addresses.  Making
> renumbering easier is not the only (or maybe even a good use) of site-local
> addresses.  We should consider that they are most useful outside of the
> corporate workplace PC/workstation environment, where having global
> addresses is not a given.
> 

I agree with Brian on all counts.  Something like Net 10 will exist in the
IPv6 world.  By defining site-local addresses within the architecture we
have the opportunity to get it done right so that all of the problems which
exist in the IPv4 world with Net 10 won't exist at all, or will be lessened
substantially, in the IPv6 world.

The consensus of this working has been in favor of this feature for a long,
long, long time.  It is really disturbing that we can't move forward with
creating solutions around the existing architecture but instead keep fighting
the same battles over and over and over and over.  We need to move forward.

Tim Hartrick
Mentat Inc.
--------------------------------------------------------------------
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: Jim Bound <[email-masked]>
Date: Mon, 29 Nov 1999 17:57:44 -0500

>substantially, in the IPv6 world.

The reasons for net 10 in IPv4 do not exist in IPv6.

>the same battles over and over and over and over.  We need to move forward.

Consenus was we would like them in the architecture.  But after two
years we have no solutions.  In any research activity if there are no
solutions for something it is valid to re-check their merit.  That is
what is being done here and I will continue to do it on anything in IPv6
that is not being used or has been defined clearly.

What is being asked is there still consensus for this part of IPv6. You
francis, and Brian say yes.  3 of us say no.  So I guess we need to hear from
more folks.  

We do not have consensus.

if we do then this time lets find a solution before we go changing
things because of them.

/jim

---

From: "Matt Crawford" <[email-masked]>
Date: Mon, 29 Nov 1999 17:05:12 -0600

> The reasons for net 10 in IPv4 do not exist in IPv6.

True, but other reasons do exist.  We've discussed them before.  Can
we stop re-fighting the battles and move on?  Since you're counting,
I for one am in favor of keeping site-local addresses.

				Matt

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 29 Nov 1999 17:33:31 -0600

The sad fact is that there are many people "out there" who believe that
Net 10 and NAT is a security feature (e.g., see today on the IETF main list,
but it's a very widespread myth).

This myth is very hard to eradicate. Frankly it may be so deeply believed
that eliminating site-local addresses, while academically correct, would be
a tactical error ("IETF abolishes privacy feature of IPv6, allows anyone
to switch on your refrigerator light").

   Brian

---

From: Christian Huitema <[email-masked]>
Date: Mon, 29 Nov 1999 18:48:22 -0500

>I for one am in favor of keeping site-local addresses.

I tend to believe that the site-local addresses, as currently defined, will
come out to hurt us in the future. I agree with Brian Zill that we have to
provide a solution for the autoconfiguration of non connected sites, e.g. a
home network with a mix of wireless, firewire, IP over the electric mesh,
and what else. I am not sure, however, that the existence of the site
address per se solves the problem.  If I am not mistaken, a host will only
start configuring site addresses if a router advertizes a site address
prefix. This router will have to be somehow configured, and prefixes will
have to be allocated to the various LANs. From an operational point of
view, configuring the router with a "uniquely tagged" site local address
would be no harder than using a "zero-tagged" address. The specific
experiment I would like is to insert an optional site-id, or site
signature, in the site-local address format. 
-- Christian Huitema

---

From: "Matt Crawford" <[email-masked]>
Date: Mon, 29 Nov 1999 18:16:31 -0600

Christian says:
> ...  If I am not mistaken, a host will only
> have to be allocated to the various LANs.

If we accept the premise that site boundaries must be manually
configured, then I think the possibility of a self-organizing
multi-link site is not difficult.  Not quite trivial, but not
difficult.  An isolated router could assign random subnet numbers (or
do we have to say SLAs?) and advertise them with a short lifetime --
on the order of minutes.  Upon detecting another router (through
means not specified here) it would exchange routing information, but
not establish full connectivity until conflicting subnets are
renumbered and the conflicting prefizes have been timed out by
existing ND mechanisms.  The prefix lifetimes might gradually
increase with the size of the set of cooperating routers.

Some heuristic about certain types of links being presumed not to
extend the site (modems, and any other popular access medium of the
day) could even relax the assumption that site boundaries need manual
configuration.
					Matt
--------------------------------------------------------------------
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: Peter Tattam <[email-masked]>
Date: Tue, 30 Nov 1999 13:14:45 +1100 (EST)

> to switch on your refrigerator light").

Them's fighting words :)

But seriously, I use net 10.0.0.0, 192.168.0.0 and 172.16.0.0 regularly for
internal work. The primary reason is that I know that while I'm playing around,
even if packets leak out with the addresses, it's highly unlikely that anyone
outside our network can reach those addresses directly which achieves the
purpose.  The secondary reason is that v4 addresses for me are very difficult
to obtain, especially to use them expediently in my network research. 

As far as security goes, to me it's horses for courses.  If I want to run a
full blown firewall, I can do all the necessaries, spend the money and
whatever and very likely I'd use net 10 anyway just in case my firewall broke
for some stupid reason.

Peter

--
Peter R. Tattam                            [email-masked]
Managing Director,    Trumpet Software International Pty Ltd
Hobart, Australia,  Ph. +61-3-6245-0220,  Fax +61-3-62450210

---

From: Jim Bound <[email-masked]>
Date: Tue, 30 Nov 1999 00:56:54 -0500

>but it's a very widespread myth).

I hate putting stuff in architecture because of myths.  I am sorry it is
very distasteful.

>to switch on your refrigerator light").

This is unfortuneately a valid point.  We have had to put a lot of stuff
in IPv6 IMO for this reason; like 8 extra bytes.

But this is the best mail and most honest mail I have seen pro
site-local addresses.

/jim

---

From: Steve Deering <[email-masked]>
Date: Tue, 30 Nov 1999 09:02:28 -0800

Though I am not especially fond of site-local addresses myself,
the working group previously made the decision to keep site-locals
in the architecture, based on all the same pro and con arguments
that are being replayed now.  I have not seen any new observations
that would justify revisiting that decision, and to go back on that
decision would do much more harm than good at this point, in my opinion.

The same is true for the notion of embedding a site ID inside a site-
local address.

I feel badly about not paying more attention to the API specs when
they were first being written.  I had hoped that the few discussions
we had during IETF meetings (e.g., the discussions that clarified that
scope boundaries cut through nodes, not links), would have been
sufficient to make clear the consequences of scoped addresses on the
APIs, forwarding rules, routing data structures, user interfaces, etc.,
but that was wishful thinking on my part.  Clearly some people understood
these issues at the time, but others have had to spend a lot of time and
email discovering them, effort that could have been avoided if I had
delivered on my frequent promises to write up what I understood about
scoped addresses (something I *still* intend to do).

(As a weak defence, I'll point out that issues of APIs, UIs, data
structures, etc. have traditionally been considered out-of-scope for
the IETF -- our job has been to define the formats of packets and the
required/desired/allowed behavior of nodes as observable from the
outside, leaving maximum freedom to the implementors in how they
accomplish those behaviors.  We have more often been chastised for
over-specifying protocols, than for under-specifying them, when it
comes to node internals.)

Anyway, most of the implementors active on this list appear to have
worked out the consequences of scoped addresses and are doing the
right things to support them, and are sharing that knowledge.  The
one major area of uncertainty is name resolution, and on that topic
I must disagree with Jim that there is WG consensus that site-local
addresses must never appear in (any part of) the DNS.  Too few people
have commented on that, and there is insufficient agreement among those
who have commented, to conclude that there is any such consensus.  I
can well imagine that name resolution for site-locals would best be
handled by DNS servers within each site, and I think it is far too
premature to rule that out.

I also don't think the lack of a current agreement on how name resolution
will be done for site-locals represents any sort of major "flaw" in
IPv6.  Reaching agreement on, documenting, and standardizing all the
aspects of IPv6 has been a big job, of course, and it was quite
reasonable to defer this particular, relatively low-priority issue,
while working out other, more important issues.  After all, the lack
of an agreed way to do site-local name resolution does not prevent the
deployment and use of IPv6, as those who think site-locals ought
to be abolished must agree.  It just prevents user-friendly use of
site-local addresses at this point in IPv6's development.  And as
others have pointed out, it would easier to make progress on that
problem if we didn't have to spend so much time re-arguing issues
that have already been decided.

Steve