Subject: site-local != NAT

From: Ofer Inbar <[email-masked]>
Date: Tue, 29 Apr 2003 18:14:05 -0400

Disclaimer: I started out reading the whole thread, but lately I've
had to skim.  I might have missed it if someone already said this.

If people want to use private addresses to avoid having to renumber
when their provider renumbers, and they use addresses their provider
won't route, then they need to NAT those addresses if they want the
hosts using them to be able to talk to the rest of the world.  Fine.

In the old days, we recommended that sites register blocks of
addresses whether they were connecting them to the net or not, if they
ever intended to connect them to the net in the future.  That way,
each address could be globally unique, since they were all going
through a central registry.

For several reasons, we began to have to put more stringent conditions
on granting address blocks out of the pool.  People stopped being able
to just ask for a /24 for their own use, and get it.  Partly this was
because we saw the address space running out if we kept letting anyone
get address space, and partly it was because people expected routing
for the addresses they were granted.

RFC1918 was a solution to the problems in the last paragraph.  The
drawbacks of RFC1918 are obvious.  If an address leaks, it might make
its way to somewhere where it looks locally valid, by coincidence.
And when networks merge, they may have collisions.  We live with it
because we need it.

If the IPv6 address space is big enough, we should be able to revert
to the old ways.  We should be able to make a policy for the RIRs that
allows, once again, for people to ask for unique address space.  Do we
have enough address space that everyone can get a reasonable amount
just by asking for it?  If so, people can NAT their private nets to
their heart's content, without requiring anything like RFC1918 or
site-local.  I've done the same thing with IPv4 with old portable
address blocks.

I think today's implied identity of "private address space" and
"locally scoped addresses" is really muddying the discussion.  If we
have a world where anyone who asks can get a unique address block
assigned to them to use for their private network... THEN what are the
remaining reasons why people would want to use site-local addresses?

  --  Cos (Ofer Inbar)       --   [email-masked]  http://cos.polyamory.org/
   "OSI is a beautiful dream, and TCP/IP is living it!"
     -- Einar Stefferud <[email-masked]>, IETF mailing list, 12 May 1992

---

From: "Tony Hain" <[email-masked]>
Date: Tue, 29 Apr 2003 17:02:05 -0700

Ofer Inbar wrote:
> ...
> I think today's implied identity of "private address space" 
> and "locally scoped addresses" is really muddying the 
> discussion.  If we have a world where anyone who asks can get 
> a unique address block assigned to them to use for their 
> private network... THEN what are the remaining reasons why 
> people would want to use site-local addresses?

First,
http://www.ietf.org/internet-drafts/draft-hain-ipv6-sitelocal-00.txt is
offered with the intent to grow into an answer to the last part. 

Second, the IPv6 SL mechanism exposed the fundamental architectural
discrepancy between the traditional application world viewpoint that an
address was a valid identifier, and the deployed network where addresses
are topology locators and have different visibility in different regions
(aka: scopes). Almost all of the complaints against SL will persist even
with a non-ambiguous address space (the exception being connecting to
the wrong node, which was arguably unlikely to begin with given mac
based IIDs). At their core, these complaints are about bringing apps
(actually every process that resolves a data structure into a topology
locator) into the world of reality where they need to recognize that
various members in a list of potential addresses for a node may not be
equally accessible from every other node in the network. The fact that
IPv6 nodes can simultaneously have addresses of mixed scopes makes the
problem more acute, but it is no different than a multi-homed IPv4 node
where one or more of its addresses are not visible in the same scope of
the routing system, or there are different access controls placed on the
set by the network manager. The system as a whole needs to be revisited
in the context of making sure every node can resolve a given data
structure into a topologically appropriate locator. 

The IPv6 WG discussion about a specific prefix is probably best dealt
with there, but the broader issue about assumptions of a flat routed
space vs. the reality of limited topology scopes is something the IETF
as a whole needs to deal with, because it exposes many historically
invalid assumptions. 

Tony

---

From: Keith Moore <[email-masked]>
Date: Tue, 29 Apr 2003 22:08:21 -0400

> address was a valid identifier,

The address *is* a valid identifier in the IP architecture.  There is
no architectural discrepancy, only an explicit engineering compromise
to use the same bit string as both a host identifier and a location
identifier.  Your repeated assertions that this is an invalid assumption
are incorrect.  For better or worse, this is the way IP was designed to
work.  The only invalid assumption is that it's acceptable for the network
to fail to support this model, without considerable re-design of not just
IP but the entire architecture.

---

From: Michael Thomas <[email-masked]>
Date: Tue, 29 Apr 2003 21:00:51 -0700 (PDT)

Keith Moore writes:
 > The address *is* a valid identifier in the IP architecture.

   Er, um, well of an interface maybe. But what you
   really want is a host identifier, which is the source
   of lots of trouble...

      Mike

---

From: Keith Moore <[email-masked]>
Date: Wed, 30 Apr 2003 00:04:14 -0400

>    really want is a host identifier, which is the source

it is well-understood and generally agreed that the overloading of IP 
IP addresses to be both host identifers and location identifers
causes some trouble.  what is less well-understood is how much trouble
the alternatives cause - either lack of a suitable endpoint identifier,
or the trouble associated with providing suitable endpoint identifiers.

Keith

---

From: Randy Bush <[email-masked]>
Date: Wed, 30 Apr 2003 04:34:33 -0700

> really want is a host identifier, which is the source

want != have

and keith is trying to focus on the pragmatic reality

randy

---

From: Michael Thomas <[email-masked]>
Date: Wed, 30 Apr 2003 06:54:49 -0700 (PDT)

> and keith is trying to focus on the pragmatic reality

Well, the pragmatic reality is to avoid using IP
addresses as substitutes for endpoint
identitifiers. Or maybe that's not pragmatic, but
tough noogies; using IP addresses as endpoint
identifiers is sloppy and generally a bad idea.

	       Mike

---

From: Keith Moore <[email-masked]>
Date: Wed, 30 Apr 2003 10:03:20 -0400

> identifiers is sloppy and generally a bad idea.

...and at this point the argument repeats, without your having acquired
any additional clue.

---

From: Michael Thomas <[email-masked]>
Date: Wed, 30 Apr 2003 07:09:05 -0700 (PDT)

> ...and at this point the argument repeats, without your having acquired

Maybe if you and Randy stopped playing elliptical
word games we could have some communication
here. If you have a point, make it.

	Mike

---

From: Randy Bush <[email-masked]>
Date: Wed, 30 Apr 2003 07:11:40 -0700

> identifiers is sloppy and generally a bad idea.

so are war and hunger

---

From: Randy Bush <[email-masked]>
Date: Wed, 30 Apr 2003 07:13:52 -0700

> here. If you have a point, make it.

keith did.  it's just that you didn't like it.

the reality is that today, identifiers are addresses are routing.
we may or may not like this, but it is fact.

randy

---

From: Keith Moore <[email-masked]>
Date: Wed, 30 Apr 2003 10:26:36 -0400

> here. If you have a point, make it.

sorry if I wasn't clear enough.  what I was saying is that it's pointless for
us to repeat the same things over and over.  and it's pointless for me to try
to explain this to you or anyone else who isn't willing to re-evaluate his
views in light of someone else's experience.

Keith

---

From: Michael Thomas <[email-masked]>
Date: Wed, 30 Apr 2003 07:35:59 -0700 (PDT)

> we may or may not like this, but it is fact.

Fine. The reality is NAT and RFC1918 too. That
doesn't mean that we should just give up. And
unlike the intractable set of problems that drive
NAT's, it's trivial to djinn up collision
resistant names which can be used in lieu of the
abdication of thought implicit in recvfrom() as
the Bearer of Names. Diffie Hellman is your
friend.

		Mike

---

From: John C Klensin <[email-masked]>
Date: Wed, 30 Apr 2003 11:26:58 -0400

--On Wednesday, 30 April, 2003 07:09 -0700 Michael Thomas 
<[email-masked]> wrote:

>  > ...and at this point the argument repeats, without your
> having acquired  > any additional clue.
>

Mike,

I disagree that they are playing word games.  But let me try a 
different approach to the issue, partially to try to explain to 
you, at a bit more length, what I think they are talking about.

One of the key issues in this discussion has been whether it is 
reasonable to remove a previously-defined and standardized 
feature, especially one that has been widely deployed for some 
time, without strong justification.  I think there is fairly 
wide agreement that is a bad idea, even if reasonable people 
might disagree as to which of those considerations apply to SL 
and to what degree.

Now, like it or not, we have a number of widely-distributed 
applications and other things, including some security 
protocols, that use IP addresses as endpoint identifiers.  They 
do that, in part, because there is no more satisfactory 
candidate for an endpoint identifier.  Certainly DNS names, with 
the current definition of the DNS, do not qualify as a 
satisfactory alternative and the number of standards-track 
alternatives that have received even moderate acceptance is, 
well, very small.   Comparatively speaking, the number of 
network-seconds (or almost any other plausible measure you can 
think of) consumed by the collection of applications and other 
things that use IP addresses as endpoint identifiers 
significantly exceeds the number of network-seconds used for 
either referencing IPv6 addresses or using other types of 
standardized endpoint identifiers... keep in mind that, from at 
least one perspective on the situation, TCP is one of those 
things that uses IP addresses as endpoint identifiers.

And, of course it is trivial to make up names, and maybe even to 
pass them around.  But there is quite a difference between that 
statement and a protocol that really uses such names as endpoint 
identifiers, carefully defines what those names are bound to and 
how and when they are unbound or refreshed, how they are exposed 
to the routing infrastructure without unacceptable layering 
violations, etc.  Try doing some serious I-D writing and working 
through of the cases and transition issues.

So...

(i) If you want to get rid of the use of IP addresses as 
endpoint identifiers, let's see an I-D that describes a 
reasonable alternative, and how to get there from there, 
processed along the standards track.  Asserting that IP 
addresses are not very good endpoint identifiers is not 
especially useful -- almost everyone agrees with you, but many 
of us are concerned about an operational network, and not, when 
it conflicts, philosophy.

(ii) Don't bother arguing that SL should be retained because it 
is standardized and entrenched and then turn around and argue 
for getting rid of IP addresses as endpoint identifiers without 
recognizing that usage are even more standardized and entrenched.

I continue to believe that there are serious and significant 
architectural issues underlying this discussion, ones that we, 
as a community, need to address and address soon.  But, IMnvHO, 
complaining about those nasty applications that use IP addresses 
in ways that are, retrospectively, problematic is not only not a 
solution to the problems, but adds a lot of noise that gets in 
the way of looking at the architectural issues.

We now return you to your regularly-scheduled word games, 
sniping, name-calling, hyperbole, and flights of fancy :-(

     john

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 30 Apr 2003 09:44:08 -0700

Michael Thomas wrote:
>  > the reality is that today, identifiers are addresses are 
> routing.  > we may or may not like this, but it is fact.
> 

What many are missing here is that this is not about 1918 style
addressing. This is about the fact that addresses do not have the same
visibility and accessibility throughout the network. This operational
reality causes the affect we have labeled scoping. 

Many on this list 'don't like' to acknowledge that scoping exists in the
network, and some claim that the network has failed because it doesn't
support a global flat routing space. We should not be focused on likes &
dislikes (as some recent voting has done), we are here to do
engineering. Shooting the messenger does not solve the problem.

The network has always had the operational capability to limit where any
particular address is accessible from. This coupled with the application
shortcut that an interface topology locator equals an endpoint
identifier has been the reason that supporting multihomed nodes has been
difficult. With the rollout of IPv6, every node becomes multihomed (in
this context that means the node actually has multiple topology locators
simultaneously). The debate over the last few months on the IPv6 list
has been about trying to restrict any given node to having addresses of
a single scope. This attempt to force an operational model that doesn't
exist in the network today, simply to preserve an invalid (granted
longstanding, but still invalid) assumption that any address can be used
equally throughout the network, has met with resistance from the
operators of the edge networks.

Our task is to look at the overall system the way that network managers
really run (or want to run) it, then figure out what it will take to
make that happen. The first thing one will realize is that any process
that passes an address outside its scope of relevance as defined by the
local network manager is not working to achieve that goal. One class of
processes that do this today are name to address resolution services,
another class are multi-party apps that pass a topology locator rather
than an label that can be turned into a topology appropriate locator. 

At the same time we are working on making the system work the way
network managers want to run it, we need to find ways to keep the
applications as simple as possible. The combination of those will likely
result in a more complex infrastructure than we have today, but no more
complex than it should have been for the last 15 years.

I don't know what a solution looks like, but I do know that continuing
to bury our collective head in a dark place will not make the problem
that needs solving go away. 

Tony

---

From: Keith Moore <[email-masked]>
Date: Wed, 30 Apr 2003 13:04:32 -0400

> visibility and accessibility throughout the network.

no, it's not just about that.  you are the only one who keeps insisting
that.  you seem to be trying to conflate two different notions of scope.
IMHO it's clearer if you talk about those kinds of scope in separate
terms; which is why I prefer to talk about ambiguous addresses on one
hand vs. packet filtering on the other.   It happens that SLs combine
the two, but there's no inherent need to do so.

> Our task is to look at the overall system the way that network
> managers really run (or want to run) it, then figure out what it will
> take to make that happen. 

funny, I thought our primary task was to design a network that could
support useful applications.   of course, managability is an important
aspect of being able to support useful applications, but it is not
reasonable to constrain the v6 network design to only permit things that
are compatible with network managers' assumptions about how to operate
v4 networks.  v6 is more different than v4 than most people realize.

so no, I don't accept your definition of "our task"; in fact I
fundamentally disagree with it as stated. 

> that needs solving go away. 

And as long as that's the way you characterize users and applications
writers with genuine needs, you're not going to be able to contribute
to solving the problem.

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 30 Apr 2003 10:48:14 -0700

Keith Moore wrote:
> no, it's not just about that.  you are the only one who keeps 
> insisting that.  you seem to be trying to conflate two 
> different notions of scope. IMHO it's clearer if you talk 
> about those kinds of scope in separate terms; which is why I 
> prefer to talk about ambiguous addresses on one

There were several proposals to remove the ambiguity in the current SL,
so continued dislike of them shows that is not the underlying issue. The
real issue is that highlighting different reachability perspectives in
different parts of the network has exposed invalid assumptions. On top
of that, scoping is about more than packet filtering, scoping happens
simply by filtering out some topology information in the routing
protocols. I agree we need to be clear about terms, but continuing to
mix ambiguity with scoping is not getting us there. 

> support useful applications.  

No that is the network managers task. One could argue that many of the
problems in making progress in the IETF are about this confusing of
roles. 

>  of course, managability is an important
> aspect of being able to support useful applications, but it 
> is not reasonable to constrain the v6 network design to only 
> permit things that are compatible with network managers' 
> assumptions about how to operate v4 networks.  

Network managers don't assume, they define how the network operates. The
IETF is the one that assumes they can dictate ...

> v6 is more different than v4 than most people realize.

I would argue that it simply takes advantage of many of the latent
capabilities that already exist in IPv4.

> 
> so no, I don't accept your definition of "our task"; in fact 
> I fundamentally disagree with it as stated. 

I understand that, but that doesn't change the reality that the IETF is
not in the business of designing networks. The IETF is in the business
of defining the standards that allow the network manager to acquire the
tools to accomplish his role as the network designer. 

> And as long as that's the way you characterize users and 
> applications writers with genuine needs, you're not going to 
> be able to contribute to solving the problem.
> 

How else does one characterize the explicit refusal to deal with a known
problem for 15+ years?

Tony

---

From: Keith Moore <[email-masked]>
Date: Wed, 30 Apr 2003 14:11:27 -0400

> There were several proposals to remove the ambiguity in the current
> SL, so continued dislike of them shows that is not the underlying
> issue. 

I don't think this conclusion is valid.  What I am certain of is that
our ability to evaluate the subtle differences between these proposals,
and the advantages and disadvantages of each, is compromised by a
widespread failure to respect the diversity of experiences and the
diversity of users' legitimate needs.  Under such circumstances, people
are forced to shoot down half-baked ideas, just as a means of damage
control, rather than trying to refine them.

As a result, I don't think any of the various proposals for unique
non-PA addresses have received adequate scrutiny.

> > > managers really run (or want to run) it, then figure out 
> > > what it will take to make that happen.
> > 

Network managers don't design IP protocols, nor do they implement IP
stacks or routers.  If the protocols we design don't support what users
need from the Internet, there's nothing a network manager can do to fix
this. 

Keith

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 30 Apr 2003 14:28:16 -0400

Hi Tony,

>reality causes the affect we have labeled scoping.

There are three ways in which a particular address can be non-global:

         - Unreachable:  The address can be unreachable from some
                 portions of the network (due to filtering, network
                 failures, etc.).

         - Not Globally Routed:  There can be no route to the address
                 from some portions of the network.

         - Not Globally Unique (AKA Ambiguous): A single address can
                 indicate one node when it is used in one part of
                 the network, and a different node when it is used
                 in other parts of the

It is an inevitable fact of physics that some addresses will be
unreachable from some parts of the network.  The widespread
use of filtering/firewalls makes this both intentional and common.
Applications must deal with this (either well or badly), because
there is no other choice.

If the only way to get a globally routable address is to get it
from your provider, people may choose to use addresses that are
not globally routed for some purposes, such as convenience or
provider-independence.

I have not heard any compelling operational requirement for
ambiguous addresses in IPv6.

The IPv6 scoped addressing architecture defines addresses that
have all three of these properties, and this is what I hear when
you say "scoped addressing".  There could be types of local
addressing, though, that don't have all of these properties.

If you are using the term "scoped" addressing to refer to
something other than the type of addressing defined in the
IPv6 scoped addressing architecture, could you define your
term?

Thanks,
Margaret

P.S. There were some proposals to remove (or lessen the
likelihood of) ambiguous site-local addresses, but none of
those proposals removed the restrictions from the IPv6 scoped
addressing architecture that are only required because addresses
are ambiguous (sites can't be nested or overlap, zone IDs are
needed to disambiguate, etc.).

---

From: Ofer Inbar <[email-masked]>
Date: Wed, 30 Apr 2003 15:09:22 -0400

Keith Moore <[email-masked]> wrote:
> [Tony Hain writes:]

For what it's worth, I've been watching this discussion for a while,
not as a proponent of any particular side, and I completely agree with
Keith on this point.  I've seen Tony Hain repeatedly make the assertion
that this discussion is about the fact that not all addresses can be
reached from everywhere, or that we don't have a "flat routing space",
or any number of related restatements... but I have seen nothing other
than Tony's assertions that would make me think this dicussion is
about any of those things.  It puzzles me that he keeps repeating them.

Tony, *why* do you think this discussion is about reachability?

Everyone else: Do any of you believe that's what this is about, aside
  from Tony's assertions and peoples responses to those assertions?

From what I have seen, those who think "local scope" is harmful, are
concerned about the ambuity of addresses, as Keith says here again.
They are NOT concerned about the fact that a given address may not be
reachable from some places, or may be reachable via different routes
from different places.  Or, rather, whether they're concerned about
that or not, it has nothing to do with their objections to locally
scoped addresses.  All of their objections to locally scoped addresses
seem to be about the fact that the addresses are ambiguous, not unique.
They have no objections to globally unique addresses that remain
"local" as far as routing and reachability.

  --  Cos (Ofer Inbar)  --  [email-masked] http://cos.polyamory.org/
  --  WBRS (100.1 FM)   --      [email-masked] http://www.wbrs.org/
  Romkey's Law: all unanimous decisions are wrong.  Proof: "They can't ALL
   be right.  So if they're all saying the same thing, it must be wrong."

---

From: Keith Moore <[email-masked]>
Date: Wed, 30 Apr 2003 15:52:44 -0400

> from different places. 

There are multiple problems.

One problem is simply that ambiguous addresses are a pain; to use
them in any kind of referral (including DNS), you have to keep track of
the context in which they're valid, and without a global scheme for
naming those contexts there's no way to do that.   This is a primary
reason why we haven't been able to identify any good workarounds for
NATs in IPv4 - the very use of ambiguous addresses by those NATs removes
the one way we had of uniquely identifying not just hosts, but
also networks or realms.

(it's scary to think about, but we might actually be able to develop a
reasonable NAT-tolerant architecture if we still had globally unique
names for the realms)

Another problem is that the existence of addresses that have limited
reachability, _coupled with_ the expectation of multiple prefixes per
host, immediately begs the problem of how the host is going to choose
between those prefixes, especially if there's no obligation of the
network to make something like longest prefix match work if the hosts
are allowed to talk to one another.  (it also begs the problem of how
how apps can do referrals in that environment - yes, they can pass
around all of the addresses but that's a pain).

Both problems exist, and both are serious.  Only the first problem is
specific to SL (I don't consider v6 LL an issue).  We don't pretend that
getting rid of SL will address the second problem, but it helps because
the absence of SL provides less incentive for networks to use addressing
tricks as a means of filtering traffic. 

Keith

---

From: "Stephen Sprunk" <[email-masked]>
Date: Wed, 30 Apr 2003 14:56:53 -0500

Thus spake "Ofer Inbar" <[email-masked]>
> but I have seen nothing other than Tony's assertions that would make
> me think this dicussion is about any of those things.  It puzzles me that
> he keeps repeating them.
>

Well, I think there was some confusion while we sorted out exactly what
"scope" means, as one camp seems to define it as a reachability problem
while the other camp defines it as an identity problem.

Any time you pass locators across a "scope" boundary, using either
definition above, things break.  I think we all agree on that, so the exact
definition of "scope" doesn't seem so important.

There is a related issue, which was until recently confused with the first,
and that is whether ambiguous addresses should be allowed/encouraged for
local use.  It seems to be established that this is a bad idea, but unless
there is a workable mechanism to establish unique addresses for all networks
_without relying on topology_, I don't see the concept going away.

S

Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 30 Apr 2003 22:56:02 +0200

On woensdag, apr 30, 2003, at 20:28 Europe/Amsterdam, Margaret 
Wasserman wrote:

> unreachable from some parts of the network.

More like an inevitable fact of economics... Thanks to Paul Baran we 
know how to build reliable networks.

> there is no other choice.

We really don't want this dealing to happen in the applications, for 
three reasons:

1. Doing all the work again for each application is not a good use
    of resources

2. It is much harder (or rather: impossible) to get something as
    tricky as this right in so many places

3. The failure can happen over the course of a session, in which case
    applications can't do anything to fix it short of implementing a
    large amount of transport logic

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 30 Apr 2003 13:31:50 -0700

Ofer Inbar wrote:
> For what it's worth, I've been watching this discussion for a 
> while, not as a proponent of any particular side, and I 
> completely agree with Keith on this point.  I've seen Tony 
> Hain repeatedly make the assertion that this discussion is 
> about the fact that not all addresses can be reached from 
> everywhere, or that we don't have a "flat routing space", or 
> any number of related restatements... but I have seen nothing 
> other than Tony's assertions that would make me think this 
> dicussion is about any of those things.  It puzzles me that 
> he keeps repeating them.
> 

Below

> From what I have seen, those who think "local scope" is 
> harmful, are concerned about the ambuity of addresses, as 
> Keith says here again. They are NOT concerned about the fact 
> that a given address may not be reachable from some places, 
> or may be reachable via different routes from different 
> places.  Or, rather, whether they're concerned about that or 
> not, it has nothing to do with their objections to locally 
> scoped addresses.  All of their objections to locally scoped 
> addresses seem to be about the fact that the addresses are 
> ambiguous, not unique. They have no objections to globally 
> unique addresses that remain "local" as far as routing and 
> reachability.

We have several proposals for removing the ambiguity in the current SL,
so while we may not agree on a specific one, we have examples of
technically how to do that. Therefore the effort to eliminate SL can't
be about ambiguity, because we could simply fix that component of the
current SL with little effort. 

The reason I say this is about reachability is that even with unique
addresses, applications will fail when they choose to pass 'an opaque
identifier' around, while they simultaneously assume that the content is
a valid topology locator at the receiver. The arguments claim the need
for opaqueness as an application simplifier on one hand, at the same
they insist that the topology match their perspective of a flat routing
space. The real network is not a single flat routing space.

Given a list of addresses for a target, how would an application pick
one that is assured to work at the receiver? Answer: it can't without
knowing the topology. The only way to keep the app from knowing
topology, and make the app work in the presence of a list is to pass the
label that was used to get the initial list, so the receiver can get its
own that is topologically appropriate. This has nothing at all to do
with ambiguity in the allocations, and everything to do with the fact
that topology locators have different utility in different parts of the
network. For example:

     ---- A ----
       |      I
       |      n
       |      t
       I      e ---- C
       2      r
       |      n
       |      e
       |      t
     ---- B ----

There are no ambiguous addresses here, just a list of potential topology
locators. If B wants to tell C to connect to A, it either has to pass a
label that C can use to figure it out, or know enough about the topology
to know which locator C needs. This simple example of why routing is not
globally flat is why I have been saying that an assumption by
applications that they can simply pick any member of the list and the
result will be useful at C is invalid. 

Replace I2 in the above diagram with one of the globally unique versions
of SL, and the issues are exactly the same. If B hands C the
non-Internet address of A, there will be no valid route in the public
net.

Replace I2 with the current version of SL, and the only difference is
that C might be in a site which uses the same subnet prefix in its local
use, so the bits will head toward a router inside the C site rather than
being dropped in the public net (people that pay by volume on the ISP
link actually consider this a feature). If the A & C sites chose to
manually allocate IIDs 1, 2, 3 ... there is a possibility that the
address handed by B would point to a different host in the C site. If
either site chose to use just about any other scheme for generating
IIDs, the likelihood of any given IID pattern being at the other site,
let alone having the same subnet prefix, is so close to 0 it is not
worth discussing. Note, this is not an argument for keeping the
ambiguity of the current SL.

Ambiguity is not the cause of the problem here, it is just the red
herring used to bolster support for shooting the SL messenger. The
fundamental problem is that processes exist that refuse to acknowledge
the network is not a single flat routing space. They do this by passing
around topology information with the explicit assumption that the
'opaque contents' will be a valid topology locator at the receiver.
Until we deal with this, there will continue to be lengthy discussions
about removing limited scope addresses from the architecture. Since
scoping through limiting routing information is an operations issue,
removing them will not happen. 

We can choose to set aside a prefix to easily identify the limited scope
addresses or not. If we don't we will have exactly the I2 case above and
no way for sorting the list of possibilitie. If we put them all in a
well-known prefix, the public net can use that in the bogon filter, and
any app that chooses to look might decide one or the other type is most
likely to work for its purposes.

Tony

---

From: "Theodore Ts'o" <[email-masked]>
Date: Wed, 30 Apr 2003 17:40:22 -0400

>   from Tony's assertions and peoples responses to those assertions?

I certainly agree that it's all about ambiguous addresses and not about
about reachability.  And it's why I have to agree with Keith that Site
Local addresses are a bad idea, and why ditching them is absolutely
the right thing.

Perhaps if we were doing things all over again, we would have two
entirely different addresses; one which is appropriate for identifying
the end-point, and which would be used by the IP layer and up (i.e.,
IP, TCP/UDP), and application level protocols, and another address
which is used for the purpose of routing the packet from one location
to another, and which would be used by the IP layer and below.
Hmm.... why does this remind me of the 8+8 proposal?  Shear
coincidence, I sure.  :-)

Anyway, for better or for worse, we don't have two separate addresses,
and protocols above and below the IP layer have been using the single
IP address for multiple different things.  As some have pointed out,
one can consider TCP as using the IP address as an end-point
identifier, which means that we can't renumber without breaking the
TCP connection.  So if we say that applications are "broken" when they
use IP addresses in this fashion, such that NAT's need to know about
the about the low-level details about the protocol when they perform
their charming man-in-the-middle attack^H^H^H^^H^H^H^Hpacket rewriting
function, this applies as much to TCP as it does to FTP.   

For whatever reason that I've not been able to understand we've
decided not to do the architecturally clean thing and either used two
fixed-length addresses, one for routing and one for end-point
identifications, *or* required that TCP connections store and utilize
DNS names in TCP headers in order to specify the source and
destination end-points.  That way, NAT boxes wouldn't need to modify
TCP (psuedo-) headers and TCP checksums when they did their magic.  

But given that we've not decided to go down this path, we have to live
with the consequences of our using a perhaps "unclean" architecture.
It means that applications should avoid trying to using IP addresses
when it can't, but at the same time, routing folks can't claim that
the IP address is only a routing entity and that no other assumptions
of the IP addresses should ever be used by applications.  For better
or for worse, applications need a reliable end-point identifier, and
while IP addresses aren't perfect, DNS names are not appropriate for
various reasons either.  So applications and end users will continue
to muddle along, and that's just life in the big, muddled, "unclean",
city.

					- Ted

---

From: S Woodside <[email-masked]>
Date: Wed, 30 Apr 2003 17:26:51 -0400

On Wednesday, April 30, 2003, at 01:48  PM, Tony Hain wrote:

> On top of that, scoping is about more than packet filtering, scoping 
> happens
> protocols.

That may be true, but there are many people who are talking about the 
internet being flat and reachable ... or not. And "not" includes both 
packet filtering and scoping, even though they are different!

simon

--
www.simonwoodside.com -- 99% Devil, 1% Angel

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 30 Apr 2003 15:55:00 -0700

Margaret Wasserman wrote:
> It is an inevitable fact of physics that some addresses will 
> be unreachable from some parts of the network.  The 
> widespread use of filtering/firewalls makes this both 
> intentional and common. Applications must deal with this 
> (either well or badly), because there is no other choice.

The point is they don't when they claim to be passing around 'opaque
identifiers', at the same time they are explicitly assuming the content
of that opaque object is a valid topology object at the receiver.

> 
> If the only way to get a globally routable address is to get 
> it from your provider, people may choose to use addresses 
> that are not globally routed for some purposes, such as 
> convenience or provider-independence.
> 

According to the definition above, anycast is one such case. Given that
anycast is in daily operational use, there must be a requirement for
addresses to refer to different physical devices in different parts of
the network.

> 
> The IPv6 scoped addressing architecture defines addresses 
> that have all three of these properties, and this is what I 
> hear when you say "scoped addressing".  There could be types 
> of local addressing, though, that don't have all of these properties.
> 
> IPv6 scoped addressing architecture, could you define your term?

I have been attempting to be very explicit about separating the third
point from the other two. As my note to Ofer showed, the issues raised
by a mismatch in expectations, about the validity of different members
in list of addresses, apply independent of any discussion about multiple
networks using the same prefix. 

> addressing architecture that are only required because 
> addresses are ambiguous (sites can't be nested or overlap, 
> zone IDs are needed to disambiguate, etc.).

They didn't propose an end to world hunger either. Personal drafts don't
necessarily reflect community thought and input on a topic, and may fail
to cover all possible edits needed in other documents. We have technical
examples of ways to remove ambiguity from the discussion, but there is
still a group that wants to eliminate SL. By taking item 3 off the
table, that desire must be related to the other two. 

There is a strong desire to kill anything that is related to the first
two since they collectively expose the bogus assertion that the 'opaque
identifiers' have an unknown value by the application, but (wink, wink)
we really know they contain a topology locator that the receiver will
use because resolution services are too slow. I have no problem with
applications passing these around as long as they make sure the 'opaque
contents' matches the network topology. If they don't want to go the the
effort required to do that right, they need to be passing around labels
so the receiver can construct a topologically correct list. 

Tony

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 30 Apr 2003 16:47:23 -0700

> packet filtering and scoping, even though they are different!

I don't know how to parse this. 

My point was that there are topology locators that are only viable
within a scope defined by the local network manager. That network
manager may choose to implement the boundary of the local scope through
routing protocols or through access controls. It really doesn't matter
which technique is used, the result is the same. Local scope addresses
that are passed outside the defined boundary are useless. 

The argument for passing addresses around is that doing so is faster
than passing the label used to get the initial mapping. While it is
probably faster in the case where the topology is consistent between the
sender & receiver, in the case where the topology doesn't match the
argument fails. How is passing a useless value faster than a label that
could be used to construct a useful one? If it is recognized that the
address failed, the only recovery is to try another member of the list,
or go back to the original label.

Tony