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

[Harald Tveit Alvestrand]

--On tirsdag, april 01, 2003 11:33:46 -0800 Bill Manning <[EMAIL PROTECTED]> 
wrote:

Are the apps for which IPv6 is enabled that -can not-
use address literals?  If so, then Steve is wrong and
the DNS has become critical infrastructure to the working
of the Internet.
anyone who believes that the DNS is not critical infrastructure for just 
about every single purpose the Internet is used for is either living in a 
fantasy world or has redefined the "Internet" to be something that's 
strictly at layer 3 and below.

there are advantages to being able to keep the layer 3 infrastructure 
running for a while (hours, I think) without referring to the DNS.
But for end-user purposes, the DNS being down equates to the Internet being 
down.

Infrastructure doesn't get much more critical than that.

 Harald

Re: Evolution in action (Re: Thinking differently)

[Pekka Savola]

On Wed, 2 Apr 2003, Harald Tveit Alvestrand wrote:
> --On tirsdag, april 01, 2003 12:31:06 -0800 Randy Bush <[EMAIL PROTECTED]> 
> wrote:
> >> During this discussion I've seen references to the "69/8 debacle".
> >> Can anybody explain what the debacle is/was? Is this a magic phrase
> >> for real insiders? Is is something that happened only on a local
> >> net? If not, why don't you explain to the rest of the world? What
> >> IS the argument hinted to with mentioning the "69/8 debacle".
> >
> > idiot isps who configured route filters but did not bother to maintain
> > them.  darwin at work.  the subject is uninteresting, as the study
> > of stupidity is an exceedingly target-rich environment.
> 
> for those of us who are endlessly fascinated by watching evolution in 
> action - what was the previous usage of 69/8 that led to those filters 
> being installed?

No such use.

Some folks just consider blocking *all* unallocated address ranges a good
idea to try reduce DoS attacks which forge addresses and the like.

An incredibly bad idea if you don't maintain them properly, really..

-- 
Pekka Savola "You each name yourselves king, yet the
Netcore Oykingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

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

[Pekka Savola]

On Tue, 1 Apr 2003, Bill Manning wrote:
>   Are the apps for which IPv6 is enabled that -can not-
>   use address literals?

There are a few.

Mostly cauzed by lazy porting, and optimizing at the first stage for the 
masses only (ie., changing the API to use getaddrinfo, but if there are 
some internal address-manually-typed-is-ok checks, those may or may not 
be modified).

> If so, then Steve is wrong and 
>   the DNS has become critical infrastructure to the working
>   of the Internet.  Otherwise, we should trapese down the
>   path of separation of topology locator from stack identifier.
> 
>   and then revisit the DNS to see if its best used as a lookup
>   service between these two things... :)



-- 
Pekka Savola "You each name yourselves king, yet the
Netcore Oykingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

addresses in referrals (Re: Thinking differently about names andaddresses)

[Harald Tveit Alvestrand]

--On tirsdag, april 01, 2003 18:49:13 -0500 Keith Moore <[EMAIL PROTECTED]> 
wrote:

- ii) pass the other party both the identifier and a current, working
address for that endpoint.
thus requiring me to continue to use IP addresses in referrals.
actually this is a fairly common tactic; the X.500 directory used to have 
that (binding a PSAP with the distinguished name of a remote MTA), and the 
DNS does it (delivering an A record, often derived from "glue", as 
additional data when sending back an NS record as a referral).

when done with care, the recipient of such a referral can handle all 3 
cases:

- this is an identity I know, and have communication with. Forget the 
address; I don't need it.

- this is an identity I know, where my current communication address 
doesn't work. Contact at the new address, and verify that you've reached 
the right endpoint.

- this is an identity I don't know. Contact at the given address, and 
verify.

I liked HIP the first time I saw it (a long time ago). I'm still waiting to 
see an application that uses it; if it's good enough to be successful at 
all, it should be able to be successful in a small market niche; if it's 
successful in a market niche, it could possibly take over the Internet.

but that first application can be a high hurdle.

 Harald

Evolution in action (Re: Thinking differently)

[Harald Tveit Alvestrand]

--On tirsdag, april 01, 2003 12:31:06 -0800 Randy Bush <[EMAIL PROTECTED]> 
wrote:

During this discussion I've seen references to the "69/8 debacle".
Can anybody explain what the debacle is/was? Is this a magic phrase
for real insiders? Is is something that happened only on a local
net? If not, why don't you explain to the rest of the world? What
IS the argument hinted to with mentioning the "69/8 debacle".
idiot isps who configured route filters but did not bother to maintain
them.  darwin at work.  the subject is uninteresting, as the study
of stupidity is an exceedingly target-rich environment.
for those of us who are endlessly fascinated by watching evolution in 
action - what was the previous usage of 69/8 that led to those filters 
being installed?

(parenthesis: similar things have reportedly happened to people using .info 
for email - there turns out to be a number of MTAs in the world who have 
hardcoded all the non-2-letter TLDs, assuming "there will be no more", and 
routinely toss mail from/to the newer ones. They, too, deserve the pain 
they get; unfortunately they, like the route filterers, don't get all the 
pain they cause.)

 Harald

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

[Michael Richardson]

-BEGIN PGP SIGNED MESSAGE-


> "Bill" == Bill Manning <[EMAIL PROTECTED]> writes:
Bill>   Are the apps for which IPv6 is enabled that -can not-
Bill>   use address literals?  If so, then Steve is wrong and 

  yes.
  Both IPv4 and IPv6 web browsers behave differently if you do,
for instance:
http://192.139.46.2/
vs  http://www.sandelman.ca/

  A different Host: header is sent, and therefore one gets a different 
(virtual) web site. Of course, we have no need of this in IPv6, since
2^64 web sites per LAN is plenty, but the protocol still exists to do it.
  Can we change this in IPv6? Maybe.

]   ON HUMILITY: to err is human. To moo, bovine.   |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[
] [EMAIL PROTECTED] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Finger me for keys

iQCVAwUBPopZtIqHRg3pndX9AQEc+wQA7lhFyoHXkIMopiYnh295B9R+8fpJxESt
dUGdIlbNUA6QwefQoHMkLo77teXn4cc2CxDI6RaE2t93FRxMOeJQUfgdT022UmQ/
co+cVhkyRXnweJb6DfwGfu3YHK/j+J7ScLw0TQ0FSAPFwGXHRbOmAppVD138hUJG
UXkPMLHDA/s=
=JyhG
-END PGP SIGNATURE-

Re: Thinking differently about names and addresses

[Keith Moore]

> > without a mechanism to map the endpoint identifier to an IP address,
> > such identifiers are useless in referrals between application
> > components. 
> 
> This is not so. Read again what I said before:
> 
>   If you construct the protocol interactions such that you don't *need* to
>   be able to look up the "identity->address" mapping (which is what HIP
>   does - in general, by providing the identity->address mapping used in any
>   given transaction as part of the initiation thereof), there's no problem.

that's like saying that if I write my protocols so that I never use referrals,
then there's no problem with the inability to do referrals.

of course, writing my protocols so that I never use referrals drastically
limits what I can do with the network.   for instance, DNS could not exist.
but never mind the lost functionality, we can at least pretend we have a clean
model.

> So if I have a system which doesn't provide a directory of mappings from
> endpoint identifier to addresses, then in the case you cite, when I refer
> one application component to another, all I need to do is either:
> 
> - i) provide some other name, one that can be mapped into both identifier
> and address, or

thus reducing the problem to a different unsolved problem.

> - ii) pass the other party both the identifier and a current, working
> address for that endpoint.

thus requiring me to continue to use IP addresses in referrals.

Keith

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

[Eric A. Hall]

on 3/31/2003 11:01 AM Bill Manning wrote:
>   Is may be worth noting that RIRs have -NEVER- made presumptions
>   on routability of the delegations they make.

Probably more accurate to say that they have never guaranteed routability.

They make all kinds of presumptions about routability. One of the reasons
they claim to refuse (say) private /24 is that it isn't going to be widely
routable. By default, this implies that larger delegations are presumed to
be routable, or else they wouldn't assign them either.

-- 
Eric A. Hallhttp://www.ehsco.com/
Internet Core Protocols  http://www.oreilly.com/catalog/coreprot/

Re: Thinking differently about names and addresses

[J. Noel Chiappa]

> From: Keith Moore <[EMAIL PROTECTED]>

> it does need to provide such mechanisms in order to provide useful
> endpoint identifiers.

I don't think you can make such a blanket statement without some more
analysis. For example:

> without a mechanism to map the endpoint identifier to an IP address,
> such identifiers are useless in referrals between application
> components. 

This is not so. Read again what I said before:

  If you construct the protocol interactions such that you don't *need* to
  be able to look up the "identity->address" mapping (which is what HIP
  does - in general, by providing the identity->address mapping used in any
  given transaction as part of the initiation thereof), there's no problem.

So if I have a system which doesn't provide a directory of mappings from
endpoint identifier to addresses, then in the case you cite, when I refer one
application component to another, all I need to do is either:

- i) provide some other name, one that can be mapped into both identifier and
  address, or
- ii) pass the other party both the identifier and a current, working address
  for that endpoint.


This is not to say I *advocate* a system which doesn't have such a directory
of identifier->address mappings; I don't have any religion one way or the
other on that. Maybe it's a good idea overall, maybe it's not.

I can't think of an example offhand of a complete transaction where I *have*
to have it, though.

Noel

Re: Thinking differently about names and addresses

[Keith Moore]

On Tue, 01 Apr 2003 13:08:26 -0800
Eliot Lear <[EMAIL PROTECTED]> wrote:

> Keith Moore wrote:
> > HIP only solves part of the problem.  It lets you use something
> > besides an address as a host identity, but it doesn't provide any
> > way of mapping between that identity and an address where you can
> > reach the host.
> 
> That's not entirely true.  It doesn't give you a very scalable way to
> do a reverse lookup, but forward lookups are quite possible with DNS.

nope.  DNS doesn't give you a way to map a HIP identifier into an IP
address.

Keith

Re: Thinking differently about names and addresses

[Keith Moore]

On Tue, 1 Apr 2003 16:26:47 -0500
"J. Noel Chiappa" <[EMAIL PROTECTED]> wrote:

> > From: Keith Moore <[EMAIL PROTECTED]>
> 
> > HIP only solves part of the problem ... it doesn't provide any
> > way of mapping between that identity and an address where you
> > can reach the host.
> 
> A system doesn't have to provide mechanisms to look up mappings from
>  to  to be useful; 

agreed.  but it does need to provide such mechanisms in order to provide
useful endpoint identifiers.  without a mechanism to map the endpoint
identifier to an IP address, such identifiers are useless in referrals
between application components.

Keith

Re: Thinking differently about names and addresses

[J. Noel Chiappa]

> From: Keith Moore <[EMAIL PROTECTED]>

> HIP only solves part of the problem ... it doesn't provide any way of
> mapping between that identity and an address where you can reach the
> host.

A system doesn't have to provide mechanisms to look up mappings from
 to  to be useful; just because I can't (in general)
look up the mapping from an Ethernet address to an IP address doesn't mean
there's a fatal flaw in IPv4.

A directorized mapping need only exist *when you need to look up that mapping
for some good reason*. If you construct the protocol interactions such that
you don't *need* to be able to look up the "identity->address" mapping (which
is what HIP does - in general, by providing the identity->address mapping
used in any given transaction as part of the initiation thereof), there's no
problem.

Now, maybe what you meant to say is "there are cases A, B and C in the use of
HIP that I have identified where you need to be able to look up that mapping,
having only the identity in hand", that would be something to examine.

But to merely say "the system doesn't provide all possible mappings" is, as
we can see from my inital example above, not really a useful critique.

Noel

Re: Thinking differently about names and addresses

[Eliot Lear]

Keith Moore wrote:
HIP only solves part of the problem.  It lets you use something besides
an address as a host identity, but it doesn't provide any way of mapping
between that identity and an address where you can reach the host.
That's not entirely true.  It doesn't give you a very scalable way to do 
a reverse lookup, but forward lookups are quite possible with DNS.

Re: Thinking differently about names and addresses

[Keith Moore]

> Egads. This list is still talking about the Identity Problem (i.e.,
> that IP addresses are semantically overloaded in that they
> simultaneously indicate (network interface) routing topology and
> (node) identity). I just can't believe how we can continually talk
> about this problem and then not embrace solutions to it such as Bob
> Moskowitz's HIP (Host Identity Payload). 

HIP only solves part of the problem.  It lets you use something besides
an address as a host identity, but it doesn't provide any way of mapping
between that identity and an address where you can reach the host.

Keith

Re: Thinking differently

[Randy Bush]

> During this discussion I've seen references to the "69/8 debacle".
> Can anybody explain what the debacle is/was? Is this a magic phrase
> for real insiders? Is is something that happened only on a local
> net? If not, why don't you explain to the rest of the world? What
> IS the argument hinted to with mentioning the "69/8 debacle".

idiot isps who configured route filters but did not bother to maintain
them.  darwin at work.  the subject is uninteresting, as the study
of stupidity is an exceedingly target-rich environment.

randy

RE: Thinking differently about names and addresses

[Fleischman, Eric]

Egads. This list is still talking about the Identity Problem (i.e., that IP addresses 
are semantically overloaded in that they simultaneously indicate (network interface) 
routing topology and (node) identity). I just can't believe how we can continually 
talk about this problem and then not embrace solutions to it such as Bob Moskowitz's 
HIP (Host Identity Payload). 

All this reminds me of the famous Mark Twain quote where he said "Everybody 
continually talks about the weather but nobody does anything about it!!"

-Original Message-
From: J. Noel Chiappa [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 01, 2003 10:25 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: RE: Thinking differently about names and addresses


> From: "Tony Hain" <[EMAIL PROTECTED]>

> your general perspective highlights the problem at hand. ..
> the routing community believes the address is the topology locator,
> while your & Dave's comments show the app community believes it is an
> identifier.

To paraphrase Clint Eastwood (in 'Unforgiven'), "Belief's got nothing to do
with it".

The address field is absolutely required in order to get the packets to where
they are going. Therefore, it has to contain information that is organized in
such a way as to make the routing work.

If the characteristics of that information are such that it's not what the
application community want, they really don't have any other choice but to
find something else.

(I shouldn't need to point out that unless the routing works, the packets
won't get there at all, and if the packets won't get there at all, all other
debates are moot.)


> I believe the multi6 discussion about creating a new identifier, to get
> the app community to stop camping on the topology locator, will end up
> creating a distributed database infrastructure almost identical to DNS.
> We don't need two of those, so we should fix DNS.

This point was bounced around in the NSRG fairly extensively. I used to
believe as you did, that we could use the DNS as a namespace for naming
end-end entities. I got a lot of pushback on that from knowledgeable parties,
which I am sure they will be happy to rehearse (I'll leave it to them, as they
can do a better job of it); I have no religion about the answer.

I will also note that the DNS does "name" things other than end-end entities;
e.g. some individual names (for popular services) get translated into the
addresses of many different end-end entities.


> I disagree with the perspective that subnetting or CIDR changed the
> character of the address.

Absolutely - not at this level. It only had to do with how it was organized
to make the routing work (see above).

Noel

Re: Thinking differently

[Bill Manning]

%   Mass Delusion is just that. Witness the 69/8 debacle.
% 
% During this discussion I've seen references to the "69/8 debacle".
% Can anybody explain what the debacle is/was? Is this a magic phrase
% for real insiders? Is is something that happened only on a local
% net? If not, why don't you explain to the rest of the world? What
% IS the argument hinted to with mentioning the "69/8 debacle".
% 
%   jaap


So sorry. Its an ARIN "insider" story.
The IANA recently delegated 69.0.0.0/8 to ARIN.
ARIN started subdelegations to its members from this space.
A number of ISPs, some of whom are recognized as significant
transit providers, had this address space filtered, e.g.
drop all packets in this prefix range.  ARINs members 
fussed and asked ARIN for routable space.  ARIN reiterated
that the address blocks they delegate have no inherent
routability.  Members continued to fuss and argue that
things like major search engines and TLD/root nameservers
be periodically renumbered into "new" ranges to encourage
ISPs to adjust their filters. 

This is not the first time, nor will it be the last that
ISPs are unwilling to do for themselves. Unfortunately, the
RIRs can not enforce routablity, -UNLESS- every ISP 
of their own freewill and volition, transfer all circuits,
routers and other IP transmission infrastructure to the
RIRs, thus giving the RIRs total control of both the
addressing and transmission of all IP datagrams.


--bill
Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).

Re: Thinking differently

[Jaap Akkerhuis]

Mass Delusion is just that. Witness the 69/8 debacle.

During this discussion I've seen references to the "69/8 debacle".
Can anybody explain what the debacle is/was? Is this a magic phrase
for real insiders? Is is something that happened only on a local
net? If not, why don't you explain to the rest of the world? What
IS the argument hinted to with mentioning the "69/8 debacle".

jaap

RE: Thinking differently about names and addresses

[J. Noel Chiappa]

> From: "Tony Hain" <[EMAIL PROTECTED]>

> your general perspective highlights the problem at hand. ..
> the routing community believes the address is the topology locator,
> while your & Dave's comments show the app community believes it is an
> identifier.

To paraphrase Clint Eastwood (in 'Unforgiven'), "Belief's got nothing to do
with it".

The address field is absolutely required in order to get the packets to where
they are going. Therefore, it has to contain information that is organized in
such a way as to make the routing work.

If the characteristics of that information are such that it's not what the
application community want, they really don't have any other choice but to
find something else.

(I shouldn't need to point out that unless the routing works, the packets
won't get there at all, and if the packets won't get there at all, all other
debates are moot.)


> I believe the multi6 discussion about creating a new identifier, to get
> the app community to stop camping on the topology locator, will end up
> creating a distributed database infrastructure almost identical to DNS.
> We don't need two of those, so we should fix DNS.

This point was bounced around in the NSRG fairly extensively. I used to
believe as you did, that we could use the DNS as a namespace for naming
end-end entities. I got a lot of pushback on that from knowledgeable parties,
which I am sure they will be happy to rehearse (I'll leave it to them, as they
can do a better job of it); I have no religion about the answer.

I will also note that the DNS does "name" things other than end-end entities;
e.g. some individual names (for popular services) get translated into the
addresses of many different end-end entities.


> I disagree with the perspective that subnetting or CIDR changed the
> character of the address.

Absolutely - not at this level. It only had to do with how it was organized
to make the routing work (see above).

Noel

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

[Bill Manning]

% > > 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?
% > 
% > Send a name.
% 
% Not all addresses are published in DNS.
% DNS isn't a requirement for IP either.
% 
% Greets,
%  Jeroen

Quoth Steve... "There are no urgent DNS problems"

Are the apps for which IPv6 is enabled that -can not-
use address literals?  If so, then Steve is wrong and 
the DNS has become critical infrastructure to the working
of the Internet.  Otherwise, we should trapese down the
path of separation of topology locator from stack identifier.

and then revisit the DNS to see if its best used as a lookup
service between these two things... :)


--bill
Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).

Re: Thinking differently

[Bill Manning]

% 
% 
% --On Monday, 31 March, 2003 09:01 -0800 Bill Manning 
% <[EMAIL PROTECTED]> wrote:
% 
% > Is may be worth noting that RIRs have -NEVER- made
% > presumptionson routability of the delegations they make.
% 
% I believe that, although I remember some arguments within ARIN 
% back when I was on the AC about whether it was legitimate or 
% rational to make allocations that were believed to be 
% unroutable.   But I've gotten several private notes that lead me 
% to believe that a lot of the community doesn't believe this or, 
% more specifically, believes that everyone will fall into line 
% and route any delegation that an RIR makes directly and, hence, 
% that any RIR allocation will, de facto, become routable.
% 
%  john

Mass Delusion is just that. Witness the 69/8 debacle.
presumptions of routability are in the eye of the 
router configuration.


--bill
Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).

Re: Thinking differently about names and addresses

[Keith Moore]

> And my point is that when you take that uninterpreted label out of its
> context of uniqueness, it can't be used as a meaningful name.

which is why addresses need to be unique.

> The real problem that the app community has with 1918 & SL is that
> they validly want a single namespace, but they also want to insist on
> using addresses as names. 

not exactly.  there are valid cases for apps using addresses even when
names exist.  sometimes you really do want to talk to a host that is at
a particular network location.  

as for 'apps insist on using addresses as names' - this is because the
architecture doesn't provide names that are good enough to use as
endpoint identifiers for all or even most cases.  you might think this
is unfortunate, and I might agree, but it doesn't follow that we should
force all apps to use DNS.  and fixing the architecture to have a
reliable endpoint identifier is a pipe dream.  nobody has demonstrated
how to make it workable.

also re: 'using addresses as names' -  this is a bogus distinction,
addresses *are* names to a large degree.  the prefix of an address is an
arbitrary bit pattern (i.e. a name), the suffix is an arbitrary bit
pattern. only the bits in the middle have anything to do with topology. 
maybe they're closer to names of locations than to names of hosts, but
they're still names.

> What the app community is indirectly saying is that we use topology
> locators as names, we have to have a single rooted name space,
> therefore the locators have to point at a unified topology. 

at least in the current IP architecture, and we're nowhere close to
having a workable new architecture that separates locators from names.

> The reality of deployed networks is that there will be routing
> filters, therefore we have a disjoint views of the address space. In
> addition, the app community expects their use of the topology locator
> as a name to be stable over a long period,

not just the app community.  TCP expects this; it cannot recover from
address changes. or does the routing community think that it's okay to
interrupt TCP connections at a whim?

> while the routing community
> wants the flexibility to change the locator as needed for significant*
> topology changes. These 'USES' are clearly at odds.

yes, there are competing concerns.  this calls for a compromise about
how stable addresses need to be, not for having infinitely stable
addresses nor for having addresses change at a whim. 

> > At this stage, I would want to hear the requirements (or 
> > probably better, the desired usage scenarios) before being 
> > certain that a modified DNS is the answer.
> 
> We agree that we need to understand the requirements before starting
> on a design.

the new namespace:

a) must to work underneath transport and other protocols, so that
those protocols' associations can survive address changes.
b) must provide quick, secure, reliable indirection
c) must provide for timely update and/or the ability to recover from
stale mapping information quickly and transparently to the application
d) must have appropriate granularity/precision - generally that of
a host/port, so that connections from multiple sources to the same
endpoint identifier reach the same process 
e) requirement c notwithstanding, there's some need for ability to do
redirects at connection setup time and possibly later, to support
process mobility and/or fanout within server farms
f) must have global scope so that referrals work

> Clearly the app community has taken advantage of using the 'where'
> identifier as a 'what' identifier. This worked fine until ~1987 when
> people started putting in routing filters which fragmented views of
> the'where' space. 

no, it still works fine in a global address space.  you are confusing 
address scope with address reachability.  apps aren't expected to be
able to reach hosts when there are explicit filters in place, so the
fact that those filters break apps is considered a feature.  however
apps are expected to accomodate private addresses, and the fact that
many apps cannot reasonably do this is considered a bug in the app.

> What the
> anti-SL camp is arguing is that if we only take one step back, we will
> rid ourselves of the problem of fragmented views.

what the consensus is arguing is that private addresses were a mistake.

> What they miss is
> that reintroduces the market demand for squatting, because we offer no
> alternative,

there is no demand for squatting until addresses are scarce.  v6
addresses are not scarce.

> We really need a big-picture perspective here before any knee-jerk
> reactions. I have one alternative for how to preallocate space to deal
> with the squatting issue, but even that doesn't solve the disconnect
> between the app community view of a unified 'where' space to be used
> as'whats', when the network managers will continue to install route
> filters and fragment the 'where' space. 

the route filters do not fragment the where space, so this 

RE: Thinking differently about names and addresses

[Tony Hain]

Dave Crocker wrote:
> TH>  The discussions on the multi6 mail list
> TH> have basically been about how the routing community believes the 
> TH> address is the topology locator, while your & Dave's 
> comments show 
> TH> the app community believes it is an identifier.
> 
> By definition, an address is a topology indicator.  Always.
> 
> The point that I was trying to make is that the uniqueness of 
> an address's bits permits its use as an uninterrupted label, 
> ie, a name. (Up a few layers, this is the basis for including 
> URL's in the set of
> URI's.)

And my point is that when you take that uninterpreted label out of its
context of uniqueness, it can't be used as a meaningful name. The real
problem that the app community has with 1918 & SL is that they validly
want a single namespace, but they also want to insist on using addresses
as names. The disjoint nature of the deployed address space precludes
both of those actions at the same time. 

> 
> So this is not about competing definitions of the bits, but 
> different USES of them.  IP needs to interpret those bits.  
> Hence, it MUST handle them as topological indicators.  Apps 
> that use IP addresses use them as simple labels.

Which I would call competing definitions, but that is not the point.
What the app community is indirectly saying is that we use topology
locators as names, we have to have a single rooted name space, therefore
the locators have to point at a unified topology. The reality of
deployed networks is that there will be routing filters, therefore we
have a disjoint views of the address space. In addition, the app
community expects their use of the topology locator as a name to be
stable over a long period, while the routing community wants the
flexibility to change the locator as needed for significant* topology
changes. These 'USES' are clearly at odds.

* I define significant in this context as disruption of an ISP/customer
interconnect, that would cause a prefix to become unusable. These are
relatively infrequent in relation to overall topology changes, but more
frequent than current procedures for DNS changes.

> 
> 
> TH>  Where the two communities agree
> TH> is that the DNS as currently deployed and operated is not 
> up to the 
> TH> task of handling the identifier role. My point is that 
> this is due 
> TH> more to implementation & operation than architecture.
> 
> Responding to this point takes us into the world of 
> solutions. I suspect we will all find this topic more 
> productive (and probably more pleasant) when we move into that mode.
> 
> 
> TH> Also I believe the multi6
> TH> discussion about creating a new identifier, to get the 
> app community 
> TH> to stop camping on the topology locator, will end up creating a 
> TH> distributed database infrastructure almost identical to DNS. We 
> TH> don't need two of those, so we should fix DNS.
> 
> That was my own view roughly 10 years ago, when Noel Chiappa 
> was pushing for use of an end-point identifier, as part of 
> what is now IPv6.
> 
> At this stage, I would want to hear the requirements (or 
> probably better, the desired usage scenarios) before being 
> certain that a modified DNS is the answer.

We agree that we need to understand the requirements before starting on
a design.

> 
> 
> TH> I disagree with the perspective that subnetting or CIDR 
> changed the 
> TH> character of the address.
> 
> Before:  IP addresses contained no topological information.
> 
> After:   IP addresses contained quite a bit of topological information
> AND that information was (is) used quite heavily.
> 
> A change that permits a routing table to be reduced massively 
> necessarily involves changing the character of something.
> 

You cut off the significant part. Since at least RFC 791, IP addresses
have always indicated the topology significance of local or remote
networks. What subnetting did was add structure as the definition of
'local' was reduced in geographic scope. What CIDR did was add structure
to the network identifier part to reduce the effort of finding the
proper next hop as the number of remote networks grew. Neither of those
acts changed the architectural nature of the address, just the bit
positions.  

Clearly the app community has taken advantage of using the 'where'
identifier as a 'what' identifier. This worked fine until ~1987 when
people started putting in routing filters which fragmented views of the
'where' space. The fragmented views became more widespread as sites that
had squatted on unallocated space interconnected without injecting
global routes. With 1597/1918, the fragmentation was formalized and the
market demand for squatting disappeared. What the anti-SL camp is
arguing is that if we only take one step back, we will rid ourselves of
the problem of fragmented views. What they miss is that reintroduces the
market demand for squatting, because we offer no alternative, as well as
the point that it doesn't really remove the original issue of fi

draft-rmcgowan-unicode-procs-02.txt

[Simon Josefsson]

One topic that is important to some people appears to be missing from
this document: what licensing scheme the Unicode Consortium uses for
their standards.  It would be useful to include a discussion on the
differences between how the Unicode standard and IETF documents can be
(re-)distributed and used by implementors.

Specifically: Some parts of the Unicode standards cannot be
redistributed, which has consequences for some implementors that want
to support Unicode with CJK in IETF protocols.

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

[Keith Moore]

> > 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.
> 
> This is like saying it's bad to force people to use
> cars/busses/whatever because they occasionally break, and everyone
> should walk everytime they need to go anywhere, because that's more
> reliable.

Nope.  Forcing apps to use DNS names is like telling people that they
must always give taxi drivers the names of the places where they want
to go, rather than the addresses of those places, and that those people
shouldn't mind when the taxi drivers take them to the wrong places, or
run up fares and delays looking for those places.

> We have multiple namespaces, each with different characteristics for
> the names, for very good reasons. If we really need a name with
> characteristic A, and we instead wind up using one with characteristic
> ~A "because it's more reliable", then that's not good.

Indeed, but let's look at this more closely.  We essentially have two
name spaces of concern here: DNS and IP.  DNS is slow, imprecise, not
terribly reliable, not always available, not always in sync with
reality. IP is fast, precise, reliable, but tied to location, which is
often the wrong thing in theory and occasionally the wrong thing in
practice. I suspect we agree that neither one is well-adapted for naming
connection endpoints, and that in an ideal world there would be a
separate namespace for this that provided fast, precise, reliable,
secure indirection that was not tied to location(assuming, of course,
that the cost of maintaining a separate name space and the extra mapping
layers would be justified by the additional utility - something that has
not been demonstrated).  But Tony's argument is that we should *always*
use DNS instead of IP even when IP works better for our purposes -
merely in order to preserve a dubious feature of IPv6.

> If we have a need for a name, and the optimal characteristics for that
> name are those of an address (i.e. the topological location of an
> interface to the network), then fine, use an address. If not, don't.
>
> If the system for mapping from one namespace to another has problems,
> we ought to fix it, not say "oh, we'll just stop using it".
>
> Don't try and make everything into a nail because the hammer is the
> most reliable tool you have.

That applies equally to DNS and IP.  Just because IP is not ideal for
some purpose does not mean that DNS is the right tool for the job, or
that it's appropriate or even feasible to "fix" it for that job. 
And based on consideration of various factors, I'm firmly convinced that
endpoint identifers should look like IP addresses instead of DNS names.

Re: Thinking differently about names and addresses

[Dave Crocker]

Tony,

TH>  The discussions on the multi6 mail list
TH> have basically been about how the routing community believes the address
TH> is the topology locator, while your & Dave's comments show the app
TH> community believes it is an identifier.

By definition, an address is a topology indicator.  Always.

The point that I was trying to make is that the uniqueness of an
address's bits permits its use as an uninterrupted label, ie, a name.
(Up a few layers, this is the basis for including URL's in the set of
URI's.)

So this is not about competing definitions of the bits, but different
USES of them.  IP needs to interpret those bits.  Hence, it MUST handle
them as topological indicators.  Apps that use IP addresses use them as
simple labels.


TH>  Where the two communities agree
TH> is that the DNS as currently deployed and operated is not up to the task
TH> of handling the identifier role. My point is that this is due more to
TH> implementation & operation than architecture.

Responding to this point takes us into the world of solutions. I suspect
we will all find this topic more productive (and probably more pleasant)
when we move into that mode.


TH> Also I believe the multi6
TH> discussion about creating a new identifier, to get the app community to
TH> stop camping on the topology locator, will end up creating a distributed
TH> database infrastructure almost identical to DNS. We don't need two of
TH> those, so we should fix DNS.

That was my own view roughly 10 years ago, when Noel Chiappa was pushing
for use of an end-point identifier, as part of what is now IPv6.

At this stage, I would want to hear the requirements (or probably
better, the desired usage scenarios) before being certain that a
modified DNS is the answer.


TH> I disagree with the perspective that subnetting or CIDR changed the
TH> character of the address.

Before:  IP addresses contained no topological information.

After:   IP addresses contained quite a bit of topological information
AND that information was (is) used quite heavily.

A change that permits a routing table to be reduced massively
necessarily involves changing the character of something.

d/
--
 Dave Crocker 
 Brandenburg InternetWorking 
 Sunnyvale, CA  USA , 

Re: Thinking differently about names and addresses

[Dave Crocker]

Harald,

>> In any event, please note that the suggestion that applications are
>> required to use names, rather than IP addresses, is new.
...
>> As in, it has not been part of the Internet architecture for the past 25
>> years.

HTA> RFC 1958, June 1996:

HTA> 4. Name and address issues

HTA> yes, "required" is new, and IMHO unspportable.

whimsical:  ok, so only *20* years...

serious: the "required" was intended as the only significant point.
(this is worth emphasizing, since it is key to the question of whether
apps are "broken" or whether we have a new problem to solve.)

Obviously, names have been a part of the Internet architecture dating
back before there was an Internet architecture. (My decrepit memory
thinks Hosts.txt was present in 1972. If not, it was certainly very
quickly thereafter.)

d/
--
 Dave Crocker 
 Brandenburg InternetWorking 
 Sunnyvale, CA  USA , 

Re: Thinking differently about names and addresses

[Keith Moore]

> I am not going to comment on each point, but your general perspective
> highlights the problem at hand. The discussions on the multi6 mail
> list have basically been about how the routing community believes the
> address is the topology locator, while your & Dave's comments show the
> app community believes it is an identifier.

it's clear that it is both of these, and furthermore that this was a
deliberate design compromise for the sake of reduced complexity.

> Where the two communities
> agree is that the DNS as currently deployed and operated is not up to
> the task of handling the identifier role. My point is that this is due
> more to implementation & operation than architecture.

disagree.  it's largely a consequence of the design decision to make the
DNS namespace federated and the lookup widely distributed across the
network.  if DNS didn't work this way, it wouldn't be nearly as usable
for the things we use DNS for.  the fact that DNS doesn't solve all
naming problems shouldn't bother us any more than the fact that IP
doesn't solve all naming problems.

> Also I believe
> the multi6 discussion about creating a new identifier, to get the app
> community to stop camping on the topology locator, will end up
> creating a distributed database infrastructure almost identical to
> DNS. 

if what you claim is true (I haven't followed multi6) it's clearly
unworkable.

to ease transition, any new identifier needs to use the same structure
as an IP address; and indirection is far better handled as a side-effect
of sending a packet than by requiring an explicit lookup.  also,
proactive propagation of updates (replication) is far better at
producing reliable results than retroactive propagation (cacheing). IOW,
mobile IP is a lot closer to a reasonable solution to this problem than
DNS.

> We don't need two of those, so we should fix DNS.

DNS could certainly be improved in various ways, but you can't fix DNS
to serve the purpose you want it to serve.

Keith

Re: Fw: Welcome to the InterNAT...

[Paul Vixie]

> > heck, TCP breaks if you change an address out from under it, so it's
> > hardly surprising that apps using TCP break under similar conditions.
> ...
> hosts could advertise static loopback addresses. Bind TCP to the
> static loopback address.

we do this.  however, it only works inside a routing domain of a /32 (or /128)
route.  in our case we can move hosts anywhere we want within what i think is
being called here a "site", without changing dns or upsetting tcp.  (i often
move my laptop from location to location within the routing domain, without
having to restart any of my suspended tcp sessions.  once we even moved a 
server from redwood city to palo alto, since it was alone on its UPS.)

injecting /32 (or /128) routes into the internet core to make tcp portability
work world wide seems like it wouldn't scale very well.
-- 
Paul Vixie

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

[J. Noel Chiappa]

> From: [EMAIL PROTECTED]

>> Effectively this could be resolved by having one globally
>> unique identifier per node.

> Paging Noel Chiappa Paging Noel Chiappa ;)

Ah, one moment, if I may:

  "his books, he always said, contained the teachings of his master,
  Socrates; ... what [Plato] had to teach could only be learned as fire is
  kindled, by the touch of the flame itself."

- Mary Renault, 'Fire From Heaven'

The heart of all my knowledge on this matter I got from Jerry Saltzer, in
particular the paper that was reprinted as RFC-1498, "On the Naming and
Binding of Network Destinations". I have merely been repeating what seemed to
me a good idea.

Noel

The IETF_Censored mailing list

[Super-User]

The IETF_Censored mailing list
   
   At times, the IETF list is subject to debates that have little to do
   with the purposes for which the IETF list was created. Some people
   would appreciate a "quieter" forum for the relevant debates that take
   place, but the IETF's policy of openness has so far prevented the IETF
   from imposing any censorship policy on the [EMAIL PROTECTED] list.
   
   To give people an alternative, there is a list called
   "[EMAIL PROTECTED]".
   
   This list is a sublist (that is, it gets the same messages as) the
   open IETF discussion list. However, this list will not forward all
   messages; in particular, the filters have been set so that persons and
   discussions that are, in the view of Raffaele D'Albenzio, irrelevant
   to the IETF list are not forwarded.
   
   Because this filter is automated, the criteria include:
 * Well known troublemakers
 * Well known crosspostings
 * Subjects that have led to recent non-conclusive exchanges
 * Some ways to say "unsubscribe"
 * Some "out-of-office-reply" messages
   
   To join the list, send the word "subscribe" in the BODY of a message
   to [EMAIL PROTECTED] (the URL here is an RFC
   2368 mailto URL that does the Right Thing).
   
   To unsubscribe, send the word "unsubscribe" in the BODY of a message
   to [EMAIL PROTECTED] Do not send to the list
   - your message will be filtered!
   (members of the main IETF list itself must follow instructions for
   that list, of course. You are only a member of ietf_censored if there
   is a comment on the bottom of your IETF list mail saying that the
   message has been sent through the ietf_censored list.)
   
   For fun, there is a special list for the rejected messages:
   [EMAIL PROTECTED] - subscribe in the same
   fashion, by mail to [EMAIL PROTECTED]
   
   By public request, the current set of filters are listed at
   http://vesuvio.ipv6.tilab.com/cgi-bin/ietf_censored-filters
   
   This page is http://carmen.ipv6.cselt.it/ietf_censored.html, and is
   posted monthly in text form to [EMAIL PROTECTED]
 _
   
   Raffaele D'Albenzio < [EMAIL PROTECTED]>

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

[J. Noel Chiappa]

> From: Keith Moore <[EMAIL PROTECTED]>

> 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.

This is like saying it's bad to force people to use cars/busses/whatever
because they occasionally break, and everyone should walk everytime they need
to go anywhere, because that's more reliable. That works in an agrarian
society, but not an industrialized one.

We have multiple namespaces, each with different characteristics for the
names, for very good reasons. If we really need a name with characteristic A,
and we instead wind up using one with characteristic ~A "because it's more
reliable", then that's not good.

If we have a need for a name, and the optimal characteristics for that name
are those of an address (i.e. the topological location of an interface to the
network), then fine, use an address. If not, don't.

If the system for mapping from one namespace to another has problems, we
ought to fix it, not say "oh, we'll just stop using it".

Don't try and make everything into a nail because the hammer is the most
reliable tool you have.

Noel

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

[John Stracke]

Stephen Sprunk wrote:

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.
 

And how much real money do they lose by having to work around those NATs?

--
/\
|John Stracke  |[EMAIL PROTECTED] |
|Principal Engineer|http://www.centive.com   |
|Centive   |My opinions are my own.  |
||
|"God does not play games with His loyal servants." "Whoo-ee,|
|where have you *been*?" --_Good Omens_  |
\/

RE: Thinking differently about names and addresses

[Tony Hain]

John,

I am not going to comment on each point, but your general perspective
highlights the problem at hand. The discussions on the multi6 mail list
have basically been about how the routing community believes the address
is the topology locator, while your & Dave's comments show the app
community believes it is an identifier. Where the two communities agree
is that the DNS as currently deployed and operated is not up to the task
of handling the identifier role. My point is that this is due more to
implementation & operation than architecture. Also I believe the multi6
discussion about creating a new identifier, to get the app community to
stop camping on the topology locator, will end up creating a distributed
database infrastructure almost identical to DNS. We don't need two of
those, so we should fix DNS.

I disagree with the perspective that subnetting or CIDR changed the
character of the address. It continues to indicate on the local network
or not, and anything not is handed to a node tasked to figure out the
next hop. I think what has changed since RFC 791 is the geographic scope
of the local network, not the architectural concepts.

Tony


> -Original Message-
> From: John C Klensin [mailto:[EMAIL PROTECTED] 
> Sent: Monday, March 31, 2003 10:13 PM
> To: Dave Crocker; Tony Hain
> Cc: 'Margaret Wasserman'; [EMAIL PROTECTED]
> Subject: Re: Thinking differently about names and addresses
> 
> 
> --On Monday, 31 March, 2003 16:44 -0800 Dave Crocker 
> <[EMAIL PROTECTED]> wrote:
> 
> > Tony,
> >
> >>> 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?
> >
> > TH> Send a name.
> >...
> > 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".
> 
> Hmm.  Maybe some clarification is in order, since at least three 
> different, and contradictory, claims have been made about this 
> principle.
> 
> The "use names and not addresses to facilitate the transition to 
> IPv6" principle was articulated some years ago, I'm pretty sure 
> back when I was still Apps AD.   It was discussed at the time, 
> and should not now come as a surprise to anyone.   However, my 
> understanding --then and now-- was that what we agreed to was to 
> try to move away from the presentation form of IP addresses on 
> the user interface side of applications.  For example, we wanted 
> to strongly discourage the use of addresses in URLs, we wanted 
> to see an address in a telnet command or in setting up an FTP 
> command channel only for debugging (if that) and so on.
> 
> Today's implied claim that the principle extends to use of names 
> within and between applications is new to me.  There are all 
> sorts of reasons why I think it is impractical. Certainly it is 
> not something I would have consciously agreed to at any time in 
> the last decade or so.  In addition to the reasons that have 
> been given, there is the small matter that DNS resolvers use 
> timeout logic that is measured in seconds -- tolerable for 
> one-time use when an application starts up, and maybe every 
> half-hour or so thereafter, but almost inconceivable each time 
> an application needs to look at an address or pass an address 
> reference to a machine with which it is already conducting a 
> dialogue.  Worse, some applications are likely to get very 
> confused if they go back to the DNS a second time and get very 
> different address information (or even a different ordering of a 
> set of addresses) to be used in conjunction with connections 
> that are already open.
> 
> Now, this may suggest that we need new facilities.  Or perhaps 
> we just need a way to say "use this address, but the same prefix 
> you already have for me" or "look the name up again, and pick 
> the address you get back that matches the prefix you see for 
> me".  I don't know.  I am pretty sure that no one has discussed 
> those issues with the applications area at any time since IPv6 
> started to gell.
> 
> I'm equally concerned about statements like:
> 
> TH> Any app that sends topology locator information without
> understanding
> TH> the topology is broken.
> 
> and
> 
> > 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 rou

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

[John Stracke]

Tony Hain wrote:

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.
That's backwards: Since the address block is ambiguous, routing *cannot* 
assure that if you reach a node it is the correct one.  Nobody can, 
because we equate addresses with identities.

Consider a  peer-to-peer conferencing session, with three participants 
A, B, and C.  A and B are at the same site; C is at a separate site; 
both sites use the same range of site-local addresses.  Each has two 
addresses, AG, BG, CG and AL, BL, CL (Global and Local).  A initiates 
the session by connecting to B and C (assume for the moment that this is 
not a problem).  B and C provide A with their addresses; to complete the 
mesh, A tells B to connect to C at CG or CL.  Now, B isn't going to 
connect to *both*, so it'll have some heuristic to pick one.  Suppose it 
picks CL (*).  But, whoops, B's site has some host D, with DL==CL.  So B 
winds up connecting to the wrong host, and doesn't realize it.

(*) Not an unreasonable supposition.  If the app is looking at the 
addresses, it might well notice that CL is on a locally attached subnet, 
and use that.  Or the app might connect to both in parallel 
(non-blocking connect()), and use the address it reaches first, as a 
first cut at discovering the most efficient path (that's what I did when 
I implemented this some time back).  Being on the same network, D will 
probably respond before C.

--
/\
|John Stracke  |[EMAIL PROTECTED] |
|Principal Engineer|http://www.centive.com   |
|Centive   |My opinions are my own.  |
||
|"God does not play games with His loyal servants." "Whoo-ee,|
|where have you *been*?" --_Good Omens_  |
\/

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

[John C Klensin]

--On Monday, 31 March, 2003 09:01 -0800 Bill Manning 
<[EMAIL PROTECTED]> wrote:

Is may be worth noting that RIRs have -NEVER- made
presumptionson routability of the delegations they make.
I believe that, although I remember some arguments within ARIN 
back when I was on the AC about whether it was legitimate or 
rational to make allocations that were believed to be 
unroutable.   But I've gotten several private notes that lead me 
to believe that a lot of the community doesn't believe this or, 
more specifically, believes that everyone will fall into line 
and route any delegation that an RIR makes directly and, hence, 
that any RIR allocation will, de facto, become routable.

john

Re: Thinking differently about names and addresses

[Harald Tveit Alvestrand]

--On mandag, mars 31, 2003 16:44:35 -0800 Dave Crocker <[EMAIL PROTECTED]> 
wrote:

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.
RFC 1958, June 1996:

4. Name and address issues

  4.1 Avoid any design that requires addresses to be hard coded or
  stored on non-volatile storage (except of course where this is an
  essential requirement as in a name server or configuration server).
  In general, user applications should use names rather than addresses.
yes, "required" is new, and IMHO unspportable.

   Harald