Subject: RE: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...))

From: Margaret Wasserman <[email-masked]>
Date: Mon, 31 Mar 2003 12:57:29 -0500

>Which actually poses an interesting question: when should an application
>just give up? IMHO, there is only one clear-cut case, i.e. when the
>application actually contacted the peer and obtained an explicit
>statement that the planned exchange should not take place -- the
>equivalent of a 4XX or 5XX error in SMTP or HTTP.

Of course, in the case of site-local addresses, you don't know for
sure that you reached the _correct_ peer, unless you know for
sure that the node you want to reach is in your site.  So, when
working from a list of addresses that includes a site-local, an
explicit refusal from the node that you reach at the site-local
address (i.e. connection reset, port unreachable, or an
application-level refusal) might not be a reason to stop working
down the list.

This is one case where the ambiguity of site-local addresses
causes problems that would not be caused by using addresses that
are globally unique, but unreachable.

I understand that a collision of site-local addresses will be
rare in autoconfigured networks.  But, in non-autoconfigured
networks, I'd still expect some proliferation of subnet == 1,
IID == 1.

Margaret

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 31 Mar 2003 11:51:10 -0800

Margaret Wasserman wrote:
> Of course, in the case of site-local addresses, you don't 
> know for sure that you reached the _correct_ peer, unless you 
> know for sure that the node you want to reach is in your 
> site.  

Since the address block is ambiguous, routing will assure that if you
reach a node it is the correct one. This FUD needs to stop!

> So, when working from a list of addresses that 
> includes a site-local, an explicit refusal from the node that 
> you reach at the site-local address (i.e. connection reset, 
> port unreachable, or an application-level refusal) might not 
> be a reason to stop working down the list.

Your argument applies to global scope addresses, not ambiguous SL as
currently defined.

> causes problems that would not be caused by using addresses 
> that are globally unique, but unreachable.

It does not, routing explicitly breaks in the presence of ambiguous
addresses. That is the feature of ambiguity that many network managers
want. What others want and we haven't provided is a stable address block
that is unambiguous and unrelated to any providers they may be attached
to. 

> networks, I'd still expect some proliferation of subnet == 1, 

This is not a problem, it is seen by many as a feature since it prevents
unintended exchange of routing information.

Tony

---

From: Eliot Lear <[email-masked]>
Date: Mon, 31 Mar 2003 12:17:44 -0800

> reach a node it is the correct one. This FUD needs to stop!

Right up till the point where two companies start communicating with one 
another directly with site-locals.  Even if there is a router frob to 
keep the scopes scoped, you can bet it won't be used until someone 
realizes that the above problem occurred.

Eliot

---

From: [email-masked]
Date: Mon, 31 Mar 2003 15:51:49 -0500

> realizes that the above problem occurred.

Well.. the same thing is true for 2 companies that get merged and both have
their 10/8 and 192.168/16 nets - then the router frobs get used.  I've heard
of one poor network engineer that had *5* 1:1 NATs separating one end of the
company from the other.

And of course, we all know that all RFC1918 users are conscientious about
filtering at their border routers.

"It's deja vu all over again" -- Yogi Berra

---

From: Måns Nilsson <[email-masked]>
Date: Mon, 31 Mar 2003 23:00:01 +0200

> realizes that the above problem occurred.

In every network (well, larger than a single subnet behind a firewall, that
is) I've seen, where there were RFC1918 addresses routed on the inside,
these things happened, although in v4-land. 

It is madness. It must stop. With v6, we can make it stop. So, SL must go
away, for it is an invitation to madness. 

All things SL is claimed to solve are solveable with unique addresses too,
as long as you've got enough of them. The rest is just simple (perhaps
tedious) work that every operations-aware person I know of would prefer to
madness. 

-- 
Måns Nilsson    http://vvv.besserwisser.org

---

From: "Stephen Sprunk" <[email-masked]>
Date: Mon, 31 Mar 2003 15:07:06 -0600

Thus spake "Eliot Lear" <[email-masked]>
> Right up till the point where two companies start communicating with
> one another directly with site-locals.  Even if there is a router frob to

I've dealt with many companies interconnecting where both use RFC1918
space -- NAT is the first thing discussed.  You forget, these people are
connecting for a _business reason_ and there is real money to be lost if
they mess up.  It's a totally different engineering model than the public
Internet.

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: Margaret Wasserman <[email-masked]>
Date: Mon, 31 Mar 2003 16:08:56 -0500

Hi Tony,

>reach a node it is the correct one. This FUD needs to stop!

I believe that you have misunderstood my point...  I'll try to explain
further, although our friends in the applications area may be able
to give better examples.

Let's assume that there is a FooBar server in SiteA.  If another
node in SiteA (NodeA) is communicating via a multi-party application
to a node in SiteB (NodeB), and wants to refer NodeB to the FooBar
server in SiteA, what does it do?

If this is IPv6 with site-local addressing, NodeA may be speaking
to the FooBar server using a site-local address.  What happens if
NodeA sends that site local address to NodeB?

NodeB tries to reach the FooBar server at the SL address that
points to the FooBar server in SiteA.  But, within SiteB, that
same address may point to a non-existent subnet, to a non-existent
node or to an existing node in SiteB.  Scoped routing doesn't stop
NodeB from reaching the wrong node, it guarantees that NodeB
_will not_ reach the right node and _may_ reach the wrong node.

The type of failure that NodeB will receive is different in each case.
If the address points to a non-existent subnet or node, an ICMP error
may or may not be generated and no connection will be established
(timeout), but if there is an existing node in SiteB with the same
address, NodeB will receive some type error from that node (the node
that NodeB _thinks_ is the FooBar server), such as port not
available, connection reset, or an application-level error. Or,
worse yet, NodeB may not receive any error at all, and may never
know that it was speaking to the wrong node.

Now, what if NodeA has a list of addresses for the FooBar server
(perhaps obtained through the use of split DNS) that includes
both site-local and global addresses?  Perhaps NodeA will send
the whole list of addresses to NodeB.  If NodeB tries the
site-local address first (as current IPv6 address selection rules
indicate) it will not reach the FooBar server.  However, it could
have reached the FooBar server using a global address.

Perhaps, you believe that NodeA should include intelligence inside
the application that knows NOT to send site-local addresses to NodeB
if NodeB is not in the same site?  If so, how does NodeA find out that
NodeB is not in the same site?

One proposal is that NodeA should only send addresses to NodeB that
are of the same or larger scope as the IP address that NodeA is currently
using to reach NodeB.  But, this has problems, too:

         - It requires some fairly complicated changes to existing
                 applications to make them work properly on IPv6.
         - It requires applications to make address selection
                 choices based on the addresses in use at the
                 network layer.  Since there is an increasing desire
                 for applications to be unaware of the addresses used
                 at the network layer, and to survive changes in
                 those addresses (see SCTP, SIP, Mobile IP, etc.), this
                 is not an architecturally sound mechanism.
         - It doesn't give a good answer for what the application
                 should do if it only has one address available
                 for the referral, and it is not of sufficient scope.
         - It may not interact well with access control mechanisms
                 that depend on using a site-local address to
                 reach services, as it errs on the side of not
                 sending site-local addresses, even when they
                 may be valid.

There are, IMO, three major problems (and several minor problems)
with the use of site-local addressing on globally connected networks:

         (1) Routing protocol issues/complexity, such as the need to
                 handle ambiguous addresses in routing exchanges and
                 the need to maintain site "convexity".  These problems
                 can be avoided by avoiding site-border routers and
                 site-border nodes (as in the "moderate" proposal),
                 AND by placing site borders on OSPF/IS-IS area
                 boundaries or on AS boundaries.
         (2) Institutionalizing the need for split DNS.  I understand
                 that some network administrators choose to use split
                 DNS today, but that doesn't meant that we want to build
                 a requirement for split DNS it into the IPv6 architecture.
                 IMO, requiring the DNS infrastructure to be aware of and
                 enforce topology boundaries is a poor architectural choice.
         (3) The need for upper-layer protocols (transport, session and
                 application-layer protocols) to include address
                 selection logic to decide when to pass (and not to pass)
                 site-local addresses in upper-layer communications.  This
                 requires modification to existing application protocols
                 and implementations, and is an unnecessary source of
                 added complexity and cost for IPv6 implementations.

We have yet to come up with any workable model for the use of
site-local addressing on connected networks that does not exhibit
problems (2) and (3).

Thoughts?

Margaret

---

From: Keith Moore <[email-masked]>
Date: Mon, 31 Mar 2003 16:25:48 -0500

On Mon, 31 Mar 2003 11:51:10 -0800

> reach a node it is the correct one. This FUD needs to stop!

NO, Tony.  The addresses get passed around in other places than the IP
header, where routers cannot block it.  This isn't FUD, it's reality. 
And the disinformation needs to stop.

Keith

---

From: "Matt Crawford" <[email-masked]>
Date: Mon, 31 Mar 2003 15:43:38 -0600

> All things SL is claimed to solve are solveable with unique
> addresses too, as long as you've got enough of them. The rest is
> just simple (perhaps tedious) work that every operations-aware
> person I know of would prefer to madness.

All right, how do you make internal site communications completely
oblivious to a change in your externally-visible routing prefix?

(Not everyone accepts that this is something necessary to achieve,
but some insist that it is.)

---

From: "Matt Crawford" <[email-masked]>
Date: Mon, 31 Mar 2003 15:49:03 -0600

> server in SiteA, what does it do?

I thought we agreed, completely outside of IPv6 concerns, that
shipping addresses in application data was bad. So NodeA refers
NodeB to foobar-server.sitea.org. Q.E.F.

---

From: Keith Moore <[email-masked]>
Date: Mon, 31 Mar 2003 17:01:57 -0500

On Mon, 31 Mar 2003 15:43:38 -0600

> oblivious to a change in your externally-visible routing prefix?

You declare that any app that keeps connections around for more than
some time period T (say for 30 days) have a mechanism for
detecting and recovering from prefix changes. That solves the
problem for all apps, not just for local apps.

---

From: Keith Moore <[email-masked]>
Date: Mon, 31 Mar 2003 17:03:26 -0500

On Mon, 31 Mar 2003 15:49:03 -0600
"Matt Crawford" <[email-masked]> wrote:

> shipping addresses in application data was bad. 

what's this "we" stuff?  some individuals may have thought this was bad,
but there's never been widespread agreement.  actually it's bad to force
all apps to use DNS names - which are often less reliable, slower, less
correct, and more ambiguous than IP addresses.

---

From: [email-masked]
Date: Mon, 31 Mar 2003 17:08:48 -0500

> NodeB to foobar-server.sitea.org. Q.E.F.

Yeah, we can agree all we want, but RFC959 still has a PORT command in it.

And until we've managed to move *all* the dain-bramaged applications to
Historical status, we're stuck with it.

And sometimes you have no *CHOICE* - if you're not shipping addresses around,
what *do* you put on a DNS A record?  This isn't facetiousness - it's a
real concern.  You can pass a hostname around instead of an address, and
when you look it up, you get back either a unique address (which you can
run with) or a site-local address (which you can't).  That's why RFC1918
has the prohibition against leaking private addresses into the DNS.

And let's face it guys - site-local is nothing but 1918 space on anabolic
steroids.  You thought it was hard to handle now, wait till it comes back
with a full blown case of "roid rage"....

---

From: "Matt Crawford" <[email-masked]>
Date: Mon, 31 Mar 2003 16:12:51 -0600

> problem for all apps, not just for local apps. 

Ah, well, if we're allowed to solve problems by fiat, let's just
declare that everyone "do the right thing" about site-local
addresses, automatically drop unauthorized packets, end hunger and
violence, and brush their teeth.

---

From: John C Klensin <[email-masked]>
Date: Mon, 31 Mar 2003 17:13:27 -0500

Margaret,

I can't disagree with any of this. As others have pointed out, 
most of these problems can, and regularly have, occurred when 
RFC1918 addresses are used in networks that are also connected 
to the public Internet and when private 1918 networks are 
interconnected.  NATs can be used to solve some of the problems 
while introducing other problems of their own.  And, with IPv6, 
the potential of having several addresses associated with each 
of those hosts, some SL and some public, would seem to increase 
the overall complexity.  All of that is complicated by our not 
really knowing how to define "site" (or address-scopes more 
generally) in many situations in which enterprise subnets are 
nested within other enterprise subnets, sometimes several layers 
deep, before the packets emerge into an environment that is 
unambiguously "public Internet".

I also find Dave Crocker's argument about what applications can 
and cannot be expected to do, and some other correspondence 
today, immensely persuasive: if we want applications to start 
shuffling around addresses, and having knowledge about which 
ones represent what sorts of locality, we are going to need some 
fairly major changes to TCP and/or ICMP.  There are some 
economic issues involved as well: if we make it significantly 
more complex to create applications that work acceptably well, 
we will reduce one of the factors --the ability to rapidly 
develop and deploy new applications-- that has contributed 
significantly to the growth of the Internet.   If IPv4 offers 
that characteristic, and IPv6 does not, or does so even slightly 
less well, it will bias decision-makers strongly against IPv6 
deployment.

All of those things are excellent reasons for getting rid of SL 
and relying on unique addresses.  At the same time, there seems 
to be ample reason for spaces that are scoped as private or 
local by filtering.   One example is transparency of internal 
networking and connectivity to external prefix changes, another 
is outlined below, and I think there are many more.

Consequently the other thing that has become clear to me over 
the last several days is that, if we are not going to have SL, 
or something else 1918-like, we need to be able to allocate 
unique blocks of addresses for private use.  It seems to me that 
we don't have a plan for doing that.  The RIR plans for IPv6 
allocations appear to focus on the IPv4 distinction between PI 
and PD space and on very large blocks and intensive 
justifications for PI space.

In the current IPv4 environment, if I go to my local ISP and say 
"I'm going to have a really smart house, and I need an IP 
address for every light socket in addition to the dozen or so I 
need for traditional hosts, even thought the light sockets won't 
be exposed to the public network", the ISP will laugh.  Part of 
that laughter will come from technologically-odd business 
reasons such as the desire to sell me an entirely different (and 
more) expensive type of connection if I really need more than 
one address.  But part of it will come because they know that 
they had better not go back to their RIR, looking for more 
space, and presenting a model that justifies an additional 
allocation on the basis of thousands of electrical fixtures that 
are not accessed directly from the public network and that, 
indeed, are firewalled off from it by devices that authenticate 
commands from the outside and filter out traffic to or from the 
fixtures themselves.

As far as I can tell, the announced RIR policies toward IPv6 
allocations are basically the same as the IPv4 ones: my ISP is 
going to have no incentive, and considerable disincentive, to 
give me large blocks of addresses that won't be routed onto the 
network. And the ISP is probably the wrong answer anyway.  If 
one of my reasons for wanting "internal" address space is to 
make communications within my LAN robust against changes imposed 
by the ISP, or changes of ISP, then having space that the ISP 
has the right (obligation?) to take back doesn't help.

So, it seems to me that, while "drop SL" is desirable, it only 
half-solves the problem and might create a worse one unless the 
other half-problem is solved.   It seems incumbent on those who 
want to get rid of SL to propose some rational scheme, one which 
can be administered at reasonable costs and bureaucracy levels, 
for allocating blocks of private-use unique addresses.  If we 
don't solve that problem, but still take out SL, we will 
arguably be encouraging people to "squat" on random addresses 
and hope they can keep them from leaking and that they never 
conflict with real addresses they want to reach.  And 
address-squatting for private use is probably the worst of all 
of the possibilities --been there, tried that, got killed by it.

Thanks to the several people whose (mostly off-lists) notes have 
helped to clarify my thinking about this.

regards,
    john

--On Monday, 31 March, 2003 16:08 -0500 Margaret Wasserman 
<[email-masked]> wrote:

>> > know for sure that you reached the _correct_ peer, unless
>> > you know for sure that the node you want to reach is in your
>> > site.
>>
>> Since the address block is ambiguous, routing will assure
>> that if you reach a node it is the correct one. This FUD
>> needs to stop!
>
> I believe that you have misunderstood my point...  I'll try to
> explain further, although our friends in the applications area
> may be able to give better examples.
>
> Let's assume that there is a FooBar server in SiteA.  If
> another node in SiteA (NodeA) is communicating via a
> multi-party application to a node in SiteB (NodeB), and wants
> to refer NodeB to the FooBar server in SiteA, what does it do?
>
> If this is IPv6 with site-local addressing, NodeA may be
> speaking to the FooBar server using a site-local address.
> What happens if NodeA sends that site local address to NodeB?
>...

---

From: Keith Moore <[email-masked]>
Date: Mon, 31 Mar 2003 17:22:26 -0500

On Mon, 31 Mar 2003 16:12:51 -0600

> violence, and brush their teeth.

well, it's about like declaring by fiat that all apps should always use
DNS names, that apps should never use IP addresses, and that DNS should
be aware of network topology -- without bothering to consult with apps
writers to see whether this will actually work.

look, we've basically got three choices for address stability.  either 

(a) sites never renumber, 
(b) they renumber occasionally, or
(c) they NAT.  

we haven't figure out how to make (a) work and allow routing to scale,
or to allow enterprise networks to split or merge, etc.  we have tried
very hard to work around the problems with (c) and failed miserably. 
(b) is the only remaining option.  so it's not so much a matter
of declaring 'by fiat' that apps need to be able to survive renumbering,
as setting expectations for which apps need to be able to survive
renumbering while they're running.  and it appears feasible to set
expectations in such a way that most apps need not worry about it.

Keith

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 31 Mar 2003 14:30:56 -0800

Margaret Wasserman wrote:
> I believe that you have misunderstood my point...  I'll try 
> to explain further, although our friends in the applications 
> area may be able to give better examples.
> 

Send a name.

> What happens if NodeA sends that site local address to NodeB?

Any app that sends topology locator information without understanding
the topology is broken.

> points to the FooBar server in SiteA.  But, within SiteB, 
> that same address may point to a non-existent subnet, to a 
> non-existent node or to an existing node in SiteB.  Scoped 
> routing doesn't stop NodeB from reaching the wrong node, it 
> guarantees that NodeB _will not_ reach the right node and 
> _may_ reach the wrong node.

In simple two party apps there will be no such confusion. If
applications insist on passing around information that they don't
understand, they will create the confusion you suggest.

> 
> The type of failure that NodeB will receive is different in 
> each case. If the address points to a non-existent subnet or 
> node, an ICMP error may or may not be generated and no 
> connection will be established (timeout), but if there is an 
> existing node in SiteB with the same address, NodeB will 
> receive some type error from that node (the node that NodeB 
> _thinks_ is the FooBar server), such as port not available, 
> connection reset, or an application-level error. Or, worse 
> yet, NodeB may not receive any error at all, and may never 

It is very likely that no error will be received, because most site
network managers block ICMP at the border anyway. 

> 
> Now, what if NodeA has a list of addresses for the FooBar 
> server (perhaps obtained through the use of split DNS) that 
> includes both site-local and global addresses?  Perhaps NodeA 
> will send the whole list of addresses to NodeB.  If NodeB 
> tries the site-local address first (as current IPv6 address 
> selection rules
> indicate) it will not reach the FooBar server.  However, it 
> could have reached the FooBar server using a global address.

If NodeB doesn't walk the list, it is broken. If the application on
NodeA passed topology locator information without understanding the
topology, it is broken.

> 
> Perhaps, you believe that NodeA should include intelligence 
> inside the application that knows NOT to send site-local 
> addresses to NodeB if NodeB is not in the same site?  If so, 
> how does NodeA find out that NodeB is not in the same site?

Since it didn't get a SL back for NodeB, there is no reason to provide
NodeB with a SL address. Those addresses are defined to be filtered, and
from the information that NodeA has, NodeB is on the outside of the
filter.

> 
> One proposal is that NodeA should only send addresses to 
> NodeB that are of the same or larger scope as the IP address 
> that NodeA is currently using to reach NodeB.  But, this has 
> problems, too:
> 

Changes that should be required anyway. Applications MUST NOT pass
around topology locator information without understanding what they are
doing.

>                  is not an architecturally sound mechanism.

If applications work from names, there is no need for a layer violation.
The stack is perfectly capable of figuring out the correct address to
use if it has a name to work from. Passing topology locator information
without a firm grasp of the topology is the architecturally unsound
issue here.

>                  for the referral, and it is not of sufficient scope.

It absolutely does. When an app knows there is an insufficient scope, it
also knows that the connection is designed by the network manager to
fail. If the app developer can't figure out what to do when it is known
that a prospective member can't participate, it is not our job to spell
that out.

>                  sending site-local addresses, even when they

I can't parse this. In any case if an application is passing topology
locator information, it has to understand the topology. 

> 
> There are, IMO, three major problems (and several minor 
> problems) with the use of site-local addressing on globally 
> connected networks:
> 
>                  the need to maintain site "convexity".  

Either the addresses are ambiguous to the routing protocol, or it can
deal with them. If they are ambiguous, there is no way to pass them
around, so the 'need' is fabricated at best.

> These problems

DNS passes around topology locators. Keeping it ignorant of the real
topology is the poor architectural choice. If the app developers really
want to keep the apps simple, they must pass around names, and let the
infrastructure component tasked with keeping track of reality do the
work. If apps insist on passing around topology locators rather than
relying on DNS, they must understand the reality of the network they are
describing.

>                  added complexity and cost for IPv6 implementations.

Applications that pass around topology locators without understanding
topology are broken, and need modification. Cost is their burden for
choosing a broken approach.

> site-local addressing on connected networks that does not 
> exhibit problems (2) and (3).

Two party apps don't have any problem here. It is only the multiparty
apps that insist on passing information they don't understand that have
these problems. 

> Thoughts?

The IAB really needs to take a hard look at the disconnect between the
DNS as defined for the network of 20 years ago, and the real networks
deployed today. No matter which prefix is used, there are addresses that
have a scope limited by the filtering rules of the network manager.
Passing these around only serves to confuse apps, because DNS claims
that the node is accessible by a particular topology locator, but there
is a filter that prevents it. If the DNS were to return an NX, the
application would immediately know that it couldn't get there.

Tony

---

From: "Jeroen Massar" <[email-masked]>
Date: Tue, 1 Apr 2003 00:46:55 +0200

> > to refer NodeB to the FooBar server in SiteA, what does it do?

Not all addresses are published in DNS.
DNS isn't a requirement for IP either.

> Any app that sends topology locator information without understanding

<SNIP>

Thus RFC959 is broken? There goes my favourite transfer proto :)
And there are enough applications that are broken then.
Actually all the applications that need special processing
when traversing a NAT as those apps 
If those apps didn't pass an IP(/port) combo inside then
they wouldn't need special treatment by the NAT either.

We are actually getting to:
  Use a unique identifier that is topology independent.
Wasn't that where IP Addresses where meant for? A unique
address independent of topology...

Greets,
 Jeroen

---

From: Keith Moore <[email-masked]>
Date: Mon, 31 Mar 2003 18:28:40 -0500

> DNS isn't a requirement for IP either.

nor is DNS reliable enough or fast enough or unambiguous enough.

> > Any app that sends topology locator information without
> > understanding the topology is broken.
> 
> <SNIP>
> 

fortunately, Tony doesn't get to decide what is broken.   by now it's
pretty obvious to almost everyone that SL is unworkable, and that
deprecating them is the Right Thing.  so apps won't have to deal
with SLs.  this is the best thing that could happen to IPv6.

Keith

---

From: Dave Crocker <[email-masked]>
Date: Mon, 31 Mar 2003 16:44:35 -0800

Tony,

>> to refer NodeB to the FooBar server in SiteA, what does it do?

TH> Send a name.

Some sort of identifier, perhaps. The details are something we all need
to discuss (and define) separately, quietly, and carefully.

It is actually orthogonal to Site Local, though Site Local has
engendered the discussion.

In any event, please note that the suggestion that applications are
required to use names, rather than IP addresses, is new.

Completely new.

As in, it has not been part of the Internet architecture for the past 25
years.

So we all should be a tad careful about claiming that failure to use
that enhancement represents a failure.  A new idea that is good is good,
but failure to use that idea previously is not "broken".

>> What happens if NodeA sends that site local address to NodeB?

TH> Any app that sends topology locator information without understanding
TH> the topology is broken.

If it is trying to use it in terms of the topological information, you
are right.

However it is usually just carrying it as an opaque identifier. This is
not such an unusual or broken behavior as one might think. Using an
upper layer for context storage of strings that are meaningful to a
lower layer -- but not to the higher one -- is a well-accepted practise.

So, we now get an unusual opportunity for network layer folk and apps
layer folk to again consider the difference between naming and
addressing. Maybe we can get John Shoch to remind us of the
fundamentals. (The URI/URN confusion on this point has been a continuing
source of frustration.) The problem is that addresses are (transient)
unique identifiers, so we sometimes use them without knowing they are
addresses.

>>                  for the referral, and it is not of sufficient scope.

TH> It absolutely does. When an app knows there is an insufficient scope,

I guess the point that it is a new requirement -- to expect an app know
about topology -- is not registering clearly enough. Perhaps it is a
reasonable requirement, but it is a major one and it is one that is
certainly not well enough understood.

There is nothing obvious, simple or historical about this requirement.

So discussion of it needs to be on a rather different basis than
inventing a new kind of IP address and then, belatedly, passing up the
requirement to apps that they deal with it differentially.

TH> I can't parse this. In any case if an application is passing topology
TH> locator information, it has to understand the topology.

Tony, I could be wrong, but I suspect that constantly repeating the same
mantra will not help any of us who are not yet enlightened to achieve
the nirvana that you are espousing.

On the other hand, it is certainly effective at making clear that our
own efforts to enlighten YOU of our own nirvana are falling far short.

>>                  the need to maintain site "convexity".  

TH> Either the addresses are ambiguous to the routing protocol, or it can
TH> deal with them. If they are ambiguous, there is no way to pass them
TH> around, so the 'need' is fabricated at best.

Clearly that is not true for Site Local addresses, or they would not be
called Site Local. Clearly the idea behind Site Local is that two
different sites can use the same addresses, while both sites are able to
reach each other. If that were NOT intended, there would be no need for
a special mechanism.

So in the context of the global Internet, those addresses are ambiguous.
Yet they are expected to be routable (within the scope of their
respective sites.)

TH> DNS passes around topology locators. Keeping it ignorant of the real
TH> topology is the poor architectural choice.

Topology changes very fast.  DNS changes very slow.

How do you propose to handle this mismatch?

TH>  If the app developers really
TH> want to keep the apps simple, they must pass around names, and let the
TH> infrastructure component tasked with keeping track of reality do the
TH> work. If apps insist on passing around topology locators rather than
TH> relying on DNS, they must understand the reality of the network they are
TH> describing.

Hmmmm.  There IS a rather interesting thought this suggests to me, namely that
an app should be able to query some service by saying something
like "I want to give destination X a reference to destination Y, please
give me the reference to Y that I should use."

The nature of that service and of the reference(s) then becomes the
discussion.

TH> The IAB really needs to take a hard look at the disconnect between the
TH> DNS as defined for the network of 20 years ago, and the real networks
TH> deployed today. No matter which prefix is used, there are addresses that
TH> have a scope limited by the filtering rules of the network manager.

Oh boy.

About 10 years ago, or so, I suggested that the IAB consider adjusting
the Internet architecture to the reality of administrative boundaries
for more than addressing. Firewalls were already a factor and NATs were
coming up fast.

Perhaps we are now ready for that topic.

TH> Passing these around only serves to confuse apps, because DNS claims
TH> that the node is accessible by a particular topology locator,

Strictly speaking, the DNS does not signal reachability.

It simply gives a strong hint about an address that stands some chance
of being reachable.

d/
--
 Dave Crocker <mailto:[email-masked]>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>

---

From: S Woodside <[email-masked]>
Date: Mon, 31 Mar 2003 20:32:48 -0500

>> to refer NodeB to the FooBar server in SiteA, what does it do?

What if the address has no name? Suddenly running a DNS becomes a 
pre-requisite to running a network connected to the internet?

simon

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 31 Mar 2003 18:29:08 -0800

Dave Crocker wrote:
> TH> Send a name.
> 
> Some sort of identifier, perhaps. The details are something 
> we all need to discuss (and define) separately, quietly, and 
> carefully.

Any other identifier will need to have all the properties of the FQDN,
as well as have a secure mechanism for the owning node to update the
binding to the current set of topology locators. 

> 
> It is actually orthogonal to Site Local, though Site Local 
> has engendered the discussion.
> 
> In any event, please note that the suggestion that 
> applications are required to use names, rather than IP 
> addresses, is new.
> 
> Completely new.

It is derived from the position that applications shouldn't know about
topology. In general I agree, but that means they need to stop dealing
with topologically significant entities.

> 
> As in, it has not been part of the Internet architecture for 
> the past 25 years.

That is not clear, but in any case the deployed Internet is not the same
as it was 25 years ago. From RFC 791;
    A distinction is made between names, addresses, and routes [4].   A
    name indicates what we seek.  An address indicates where it is.  A
    route indicates how to get there.  The internet protocol deals
    primarily with addresses.  It is the task of higher level (i.e.,
    host-to-host or application) protocols to make the mapping from
    names to addresses.   The internet module maps internet addresses to
    local net addresses.  It is the task of lower level (i.e., local net
    or gateways) procedures to make the mapping from local net addresses
    to routes.
Mapping names to addresses is a simple task. One could argue that it was
so simple that apps took the shortcut of using the 'where' to also
define the 'what'. That does not mean the requirement for apps to keep a
clear context for 'what' is a new requirement. 

> 
> So we all should be a tad careful about claiming that failure 
> to use that enhancement represents a failure.  A new idea 
> that is good is good, but failure to use that idea previously 
> is not "broken".

In the Internet of 25 years ago, there were no filters that limited
scope, so an app could get away with passing around mixed 'what'/'where'
tags. The current world exposes that shortcut, and arguably identifies
its failures. 

> speaking to 
> >> the FooBar server using a site-local address.
> TH> Any app that sends topology locator information without 
> TH> understanding the topology is broken.
> 
> If it is trying to use it in terms of the topological 
> information, you are right.
> 
> However it is usually just carrying it as an opaque 
> identifier. This is not such an unusual or broken behavior as 
> one might think. Using an upper layer for context storage of 
> strings that are meaningful to a lower layer -- but not to 
> the higher one -- is a well-accepted practise.

I understand the intent here, but passing information outside its realm
of applicability is broken. Turn on the wayback machine and consider the
effect of passing a bitnet address across the gateway, or an internet
address back. The receiver must have a context or the identifier is
meaningless. The same is true with passing IP addresses outside of a
filtering router, no matter which prefix is being used.

> 
> So, we now get an unusual opportunity for network layer folk 
> and apps layer folk to again consider the difference between 
> naming and addressing. Maybe we can get John Shoch to remind 
> us of the fundamentals. (The URI/URN confusion on this point 
> has been a continuing source of frustration.) The problem is 
> that addresses are (transient) unique identifiers, so we 
> sometimes use them without knowing they are addresses.

The multi6 list recently had a long discussion on this point.
Unfortunately that effort is all about creating yet another layer of
mapping between names and addresses, but misses the point that it
requires all of the binding security and update processes that are
already defined for DNS.

> TH> It absolutely does. When an app knows there is an insufficient 
> TH> scope,
> 
> I guess the point that it is a new requirement -- to expect 
> an app know about topology -- is not registering clearly 
> enough. Perhaps it is a reasonable requirement, but it is a 
> major one and it is one that is certainly not well enough understood.

I am not arguing that all apps need to know about topology, just those
that insist on passing around topology locators. Basically, the app
needs to know what it is doing.

> There is nothing obvious, simple or historical about this requirement.

Again from 791;
    Care must be taken in mapping internet addresses to local net
    addresses; a single physical host must be able to act as if it were
    several distinct hosts to the extent of using several distinct
    internet addresses.  Some hosts will also have several physical
    interfaces (multi-homing).
If apps didn't keep straight how to deal with hosts with multiple
physical interfaces, they would fail to operate. To some degree, that
means keeping track of topology. I agree the filtering came later, but
the basic requirement has been there all along.

> 
> So discussion of it needs to be on a rather different basis 
> than inventing a new kind of IP address and then, belatedly, 
> passing up the requirement to apps that they deal with it 
> differentially.

It is not a new kind of address, it is RFC 1918 in a single block. In
general apps should not need to treat SL differently. The only time it
becomes a problem is when the app passes an address rather than a name.
As long as the source of name to address mapping is providing
topologically correct answers, the app can be oblivious. 

> 
> 
> TH> I can't parse this. In any case if an application is passing 
> TH> topology locator information, it has to understand the topology.
> 
> Tony, I could be wrong, but I suspect that constantly 
> repeating the same mantra will not help any of us who are not 
> yet enlightened to achieve the nirvana that you are espousing.

Sorry for the repetition. It has become habit in response to the
repetitive FUD on the SL discussions.

> 
> On the other hand, it is certainly effective at making clear 
> that our own efforts to enlighten YOU of our own nirvana are 
> falling far short.

I understand the desire for the apps to simply pass information to a
peer, and in the network of 25 years ago that worked. Unfortunately for
the network of today it doesn't. Something needs to keep the information
consistent with the deployed network, and if apps don't want to do that
then they should use names and let the name resolution process sort out
reality.

> TH> Either the addresses are ambiguous to the routing protocol, or it 
> TH> can deal with them. If they are ambiguous, there is no 
> way to pass 
> TH> them around, so the 'need' is fabricated at best.
> 
> Clearly that is not true for Site Local addresses, or they 
> would not be called Site Local. Clearly the idea behind Site 
> Local is that two different sites can use the same addresses, 
> while both sites are able to reach each other. 

This is part of the FUD & confusion propegated through the presentation
to the apps area, as well as those who simply want to pretend that local
scope addresses don't exist. The reality is that two networks that use
ambiguous addresses can't just route to each other, because the routing
protocol can't sort out the ambiguity. Where the multiparty app issue
comes in is when the networks have both SL & global addresses, and the
global addresses are routed to each other. In this case, the name to
address mechansim needs to keep the SL mappings in the correct realm of
applicability, and apps that pass addresses need to do the same.

> If that were 
> NOT intended, there would be no need for a special mechanism.

In the general case there is no need, but the FUD makes it sound like
every app will have to change.

> 
> So in the context of the global Internet, those addresses are 
> ambiguous. Yet they are expected to be routable (within the 
> scope of their respective sites.)

This is the intent, and as long as the address references stay within
the appropriate scope, applications can treat them as any other address.
Also, having a well-known prefix allows apps that want to stay on the
inside of a known filter to figure that out. For example, the file
sharing process can choose to only bind to the filtered address so that
it is not globally reachable, while other processes on the same machine
can use an available global scope address. Some argue that this can be
done with appropriate router filters, which it can as long as the router
can do fast deep packet inspection to find the port #, and that the
network manager knows all the possible port #'s for apps that should be
filtered. It is much simpler to put the policy decision at the endpoint
where it is needed. 

> How do you propose to handle this mismatch?

Topology changes quickly, but the topology locator currently does not.
There have been discussions about changing locators more rapidly than
DNS can handle, but whatever happens there will have to deal with the
need to securely update the globally distributed caches, so it won't
happen much faster than DNS could with appropriate operational
adjustments.

> TH> want to keep the apps simple, they must pass around 
> names, and let 
> TH> the infrastructure component tasked with keeping track of 
> reality do 
> TH> the work. If apps insist on passing around topology 
> locators rather 
> TH> than relying on DNS, they must understand the reality of 
> the network 
> TH> they are describing.
> 
> Hmmmm.  There IS a rather interesting thought this suggests 
> to me, namely that an app should be able to query some 
> service by saying something like "I want to give destination 
> X a reference to destination Y, please give me the reference 
> to Y that I should use."
> 
> The nature of that service and of the reference(s) then 
> becomes the discussion.

Agree, but why do that rather than tell X to look up Y? For you to
figure out who to ask would be a big deal, but X already knows how to
resolve names that are appropriate for its perspective.

> 
> 
> TH> The IAB really needs to take a hard look at the 
> disconnect between 
> TH> the DNS as defined for the network of 20 years ago, and the real 
> TH> networks deployed today. No matter which prefix is used, 
> there are 
> TH> addresses that have a scope limited by the filtering rules of the 
> TH> network manager.
> 
> Oh boy.
> 
> About 10 years ago, or so, I suggested that the IAB consider 
> adjusting the Internet architecture to the reality of 
> administrative boundaries for more than addressing. Firewalls 
> were already a factor and NATs were coming up fast.
> 

Ready or not, it needs to happen.

> It simply gives a strong hint about an address that stands 
> some chance of being reachable.
> 

I agree that a record doesn't indicate reachability, so I wasn't crisp
because the part you cut off was my point. In the X, Y example above, if
there wasn't a record for Y available to X, it would know that without
waiting. 

Tony

---

From: Dave Crocker <[email-masked]>
Date: Mon, 31 Mar 2003 19:01:28 -0800

Tony,

I am going to wait on replying to the "debate" aspect of this exchange, to
see if others have comments.  I am posting now only to offer a

>> while both sites are able to reach each other. 

TH> This is part of the FUD & confusion propegated through the presentation
TH> to the apps area, as well as those who simply want to pretend that local
TH> scope addresses don't exist. The reality is that two networks that use
TH> ambiguous addresses can't just route to each other, because the routing
TH> protocol can't sort out the ambiguity.

Sorry for the confusion:

Site Local means that two sites need to be able to each use the same
addresses.  If the two sites interact, they need to use some other set
of addresses.  However Site Local is only an interesting construct if it
operates while a site that is using one is attached to the Internet and,
therefore, talking to others sites.  When this occurs, obviously it is
essential that a site local address stay... local to that site.

However from the context of the larger Internet, the Site Local address
is ambiguous. (Your reply agrees to this point, so this is here only for
completeness.)

d/