Subject: RE: Fwd: Minutes / Notes

From: "Christian Huitema" <[email-masked]>
Date: Sun, 20 Jul 2003 16:41:30 -0700

> But don't mistake these questions for the first question - of whether you do
> the separation.

I would contend that modern applications already separate identity and location. Take three different example, the web, SIP, and P2P file sharing networks. In web applications, the objects are identified by an http URL; in SIP, end points are identified by a SIP URL; in P2P networks files are identified by their names and attributes. All of these applications treat IP addresses strictly as locations -- some place from which you can get a web page, to which you can send voice packets, from which you can get a slice of a file. The specific IP addresses vary over time, depending upon load balancing in web farms, transient registrations in SIP, or which of the file publishers happens to be on-line with P2P file sharing networks. P2P and the web, combined, represent the bulk of current Internet traffic.

In current networks, the identifier role of IP addresses is very limited. The most visible in the current discussion is the use of addresses to identify TCP connections, but we should add IPSEC associations, and filtering rules encoded in some firewalls or similar products. I would agree that these are problems, but they are limited in scope. In fact, the market is responding to these issues when needed: firewall traversal is now mostly based on VPN products, using explicit identification of users and computers; IPSEC sessions often require the exchange of identification tokens, independent of the IP address. 

The question is  not whether we want to separate the location and identity function of IP addresses. Clearly, application developers have voted on that one. They just use the location function, and rely on other systems for identity. IP addresses should be locators, period. The question is whether we want to pay an identifier tax at the IP layer. The tax will be significant: additional resolution procedures, additional overhead in the packets. The main justification of that tax would be to keep alive some long duration TCP connections, or some IPSEC sessions. This may benefit some applications, but the tax would have to be payed by everybody, whether they need the functionality or not. I would much rather not pay the identifier tax, and use a combination of application level sessions, TCP improvement, IPSEC fast rekeying, or maybe mobile-IP. There is no reason that everybody pays the tax when just a few benefit.

-- Christian Huitema

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 21 Jul 2003 16:28:22 +0200 (CEST)

> I would contend that modern applications already separate identity and
> location. Take three different example, the web, SIP, and P2P file sharing
> networks. In web applications, the objects are identified by an http URL; in
> SIP, end points are identified by a SIP URL; in P2P networks files are
> identified by their names and attributes. All of these applications treat IP
> addresses strictly as locations -- some place from which you can get a web
> page, to which you can send voice packets, from which you can get a slice of
> a file. The specific IP addresses vary over time, depending upon load
> balancing in web farms, transient registrations in SIP, or which of the file
> publishers happens to be on-line with P2P file sharing networks. P2P and the
> web, combined, represent the bulk of current Internet traffic.

Christian,
I'm trying to reconcile the above with other things we are hearing:
1. the lack of a multihoming solution in IPv6 is a hindrance to deployment
2. the lack of PI space in IPv6 (whether or not multihoming) is
   a hindrance to deployment

If the folks concerned about #1 shared your view then presumably the only
thing we would need would be multiaddressing and a fix for the
interaction between source address selection and ingress filtering and we
would have solved #1.
However, there might be strong perception out there that IPv4 multihoming
handles applications that do not have their own identifier hence folks want 
to see IPv6 supporting the same thing, even if applications are moving towards
their own identifier space and application layer retries upon failures.

Even if we believed that a fix in source address selection + ingress filtering
was sufficient for #1 it doesn't seem to address the perception of #2.
I get the feeling that folks have been burned by renumbering when switching
ISPs in IPv4 and they never want to do that again, so convincing them
that the renumbering tools in IPv6 plus applications having their own
identifiers and retry logic is a good enough solution seems like a hard
sell. [Not that ID/loc separation makes everything use the PI identifiers; 
there will presumably still be filtering in firewalls etc applied to loctors.
But it sure would reduce the pain of renumbering.]

So do you think that fixing source address selection + ingress filtering
would be sufficient to address perception 1 and 2?

> The question is  not whether we want to separate the location and identity
> function of IP addresses. Clearly, application developers have voted on that
> one. They just use the location function, and rely on other systems for
> identity. IP addresses should be locators, period. The question is whether
> we want to pay an identifier tax at the IP layer. The tax will be
> significant: additional resolution procedures, additional overhead in the
> packets. The main justification of that tax would be to keep alive some long
> duration TCP connections, or some IPSEC sessions. This may benefit some
> applications, but the tax would have to be payed by everybody, whether they
> need the functionality or not. I would much rather not pay the identifier
> tax, and use a combination of application level sessions, TCP improvement,
> IPSEC fast rekeying, or maybe mobile-IP. There is no reason that everybody
> pays the tax when just a few benefit.

Good point.
Presumably applications that don't need the benefits of the identifiers
can operate on the locators and not incur any overhead at the IP layer.

  Erik

---

From: Keith Moore <[email-masked]>
Date: Sun, 20 Jul 2003 20:49:33 -0400

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>[email-masked] and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

> > But don't mistake these questions for the first question - of whether you
> > do the separation.
> 

The examples you cited have identifiers for resource names that are in a
separate space from that used for identifiers for locations.  This isn't at
all the same thing as separating host identity from host location.  Neither 
the web nor SIP do this, and the p2p file sharing networks with which I'm 
familiar don't really do this either (though some have a hack that attempts 
to tolerates the endpoints having different views of IP addresses).  Offhand
I don't recall that either the web or SIP need to identify hosts, as opposed
to resources, so it seems that both of them are irrelevant as examples.

So your conclusions do not follow.  

Having helped write an application that does this, it's a major pain to expect
apps to define their own set of identities for hosts.  Unfortunately, neither DNS 
names (as deployed) nor IP addresses (as deployed) are up to the job - both are 
ambiguous, both are often only usable from limited realms, DNS names are slow 
and too-often unreliable.

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 24 Jul 2003 12:31:51 +0859 ()

[Charset iso-8859-1 unsupported, filtering to ASCII...]
> I would contend that modern applications already separate identity and location.

Of resources or hosts?

> Take three different example, the web, SIP, and P2P file sharing networks. In web applications, the objects are identified by an http URL;

> in SIP, end points are identified by a SIP URL;

> in P2P networks files are identified by their names and attributes.

URL locates, not identifies, resource, not host.

> All of these applications treat IP addresses strictly as locations

Wrong. With URL, you can identify resource on a host, only if you
can identify the host.

If a host holding a resource is, at the same location, replaced
by another host holding different resource, URL now points to
resource with different identity.

						Masataka Ohta