Subject: [RAM] candidate properties of some new name types

From: RJ Atkinson <[email-masked]>
Date: Tue, 16 Jan 2007 16:17:16 -0500

Some candidate properties of names, for consideration.

Locators:
- A Locator names a single sub-network, not an interface or node
   (This is similar to a "routing prefix" in current parlance.)
- A node may have multiple Locators at the same time (e.g. due
   to multi-homing of some sort).
- A Locator is only used for routing and forwarding packets,
   except that the last-hop router uses both the Locator and
   the Identifier to look up the destination link-layer information
   (e.g. MAC address) in the ARP/ND cache inside the router.

Identifiers:
- An Identifier names a node ("stack" in IRTF NSRG parlance)
   and is not tied to a specific interface or location.
- A node may have multiple Identifiers concurrently.
- A node may use multiple Identifiers concurrently,
   however a given single transport session must not change
   Identifier during the lifetime of that transport session.
- An Identifier is not necessarily globally unique, but has
   a very high probability of being globally unique.
- An Identifier is unique within the scope of a given Locator
   that it is used with.
- Identifiers, and not Locators, are included in transport-layer
   session state.

Ran

NB:  This is *different* than SHIM6.  In SHIM6, the semantics of
      an IPv6 address are even more overloaded than before SHIM6.
      In this concept, Locators have crisp semantics and Identifiers
      have different crisp semantics -- no overloading of the same
      namespace for multiple purposes.

_______________________________________________
RAM mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ram

---

From: Tony Li <[email-masked]>
Date: Tue, 16 Jan 2007 14:12:21 -0800

>   (This is similar to a "routing prefix" in current parlance.)

Clarification question: What is a sub-network?  I'm guessing that you  
mean an L2 broadcast domain.

>   (e.g. MAC address) in the ARP/ND cache inside the router.

Related clarification: Does the locator specify the sub-network and  
then the identifier indexes into the link-layer address cache for  
that sub-network?  Your wording seems to imply that the cache  
necessarily spans sub-networks, which I don't think you actually mean.

> - Identifiers, and not Locators, are included in transport-layer

Is an identifier bound to a particular link layer address?  If so,  
for how long?

If an identifier is bound to a node, is it possible to migrate a  
transport session?  Suppose I have a TCP connection and I suspend the  
process.  It now pops up on a different virtual machine on the same  
physical hardware.  Does that work?  What about on different  
hardware?  What about within a different locator?

Is the destination locator removed by the last hop-router?

Tony

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 16 Jan 2007 17:28:15 -0500

On  16 Jan 2007, at 17:12, Tony Li wrote:
> Clarification question: What is a sub-network?  I'm guessing that  
> you mean an L2 broadcast domain.

Yes.  For example, a single Ethernet VLAN.

> necessarily spans sub-networks, which I don't think you actually mean.

Locator specifies the sub-network.
Identifier indexes into the link-layer cache for that given Locator.

Sorry if the wording was confusing.

> Is an identifier bound to a particular link layer address?  If so,  

Hmm.  I'm not sure I follow the question.

A node might have some Identifier (Ix).  The node might use Ix
with traffic over a wireless Ethernet interface having MAC address A
and also with traffic over a wired Ethernet interface having MAC
address B -- concurrently.

> transport session?  Suppose I have a TCP connection and I suspend  
> the process.  It now pops up on a different virtual machine on the  
> same physical hardware.  Does that work?  What about on different  

This gets into what one means by "node" or "virtual machine" or
"distributed system" or "different hardware".

One can imagine a single distributed system built out of 3 different
x86 chassis.  If there is a common stack for that single distributed
system, then the TCP connection might be moved (internally to the
distributed system) from chassis 1 to chassis 3.

One can imagine a multi-level secure system having several different
virtual machines, each with its own "stack", on a single piece of
physical hardware.  In this case, for OS reasons unrelated to  
networking,
the TCP process is unlikely to migrate from the TS virtual-machine
to the U virtual-machine.

If the TCP session is on Node X with Identifier Ix, then if that node
moves from location Y (Locator Ly) to location Z (Locator Lz), then
the TCP session stays up because it is bound to the Identifier only,
so the Locator can change without affecting the TCP session's liveness.

> Is the destination locator removed by the last hop-router?

It does not have to be removed.  Normally, one would imagine
that the last-hop router would not remove it, simply to conserve
ergs.

Ran
[email-masked]

---

From: Tony Li <[email-masked]>
Date: Tue, 16 Jan 2007 14:43:25 -0800

> so the Locator can change without affecting the TCP session's  

So, if I'm following you, the session is strongly bound to the  
identifier for the lifetime of the session.  The identifier is  
strongly bound to the node.  The node is loosely bound to the  
hardware address for the duration of the ARP entry.

I have no problems with any of this, I just wanted to make sure that  
we are clear on the architectural limitations that come along with  
these definitions.

Tony

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 16 Jan 2007 17:45:53 -0500

On  16 Jan 2007, at 17:43, Tony Li wrote:
> identifier
> for the lifetime of the session.  The identifier is strongly bound  
> to the
> node.  The node is loosely bound to the hardware address for the  
> duration
> of the ARP entry.

Yes.

> I have no problems with any of this, I just wanted to make sure
> that we are clear on the architectural limitations that come along
> with these definitions.

Clarity is good.

:-)

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 17 Jan 2007 00:29:25 +0100

I just subscribed and I'm still catching up, but I have to interject  
here...

>   (This is similar to a "routing prefix" in current parlance.)

= incompatible with what we currently have

>   (e.g. MAC address) in the ARP/ND cache inside the router.

= incompatible with what we currently have

>   and is not tied to a specific interface or location.

= incompatible again

>   Identifier during the lifetime of that transport session.

who are we to tell transports what they can and can't do?

> - An Identifier is not necessarily globally unique,

Ugh!

> - An Identifier is unique within the scope of a given Locator

This isn't easy to do and pretty much ends up requiring global  
uniqueness anyway.

>      namespace for multiple purposes.

Irrespective of shim6, in my opinion the ability to overload is a  
feature. Removing that feature just because it doesn't conform to the  
contemporary notion of architectural cleanliness is a big mistake,  
especially in the context of this list, which isn't about coming up  
with new architectures but rather, solve a specific problem.

The good thing about the blurry line between locators and identifiers  
is that one can be up/downgraded to the other when necessary, so we  
can create room for ourselves to accomplish our goals. For instance,  
in a "jack up" model, most routing/forwarding decisions will be done  
based on the new lower-level locators, but near the source, where the  
locators aren't present yet, and near the destination, where they're  
already stripped off, routing/forwarding can happen based on the  
identifiers. A clear separation between the two means that routers  
must be upgraded to know the difference, and take both into account  
on the destination link. While this isn't a bad idea in and of itself  
(surely IPX is now extinct for other reasons) mandating this type of  
change for the entire internet creates more problems than it solves.

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 16 Jan 2007 18:46:43 -0500

On  16 Jan 2007, at 18:29, Iljitsch van Beijnum wrote:
> Irrespective of shim6, in my opinion the ability to overload
> is a feature. Removing that feature just because it doesn't conform
> to the contemporary notion of architectural cleanliness is a big  
> mistake, ...

The idea that such semantic overloading is undesirable goes back
at least as far as Shoch.  Calling that desire for crisp, clear
semantics "contemporary" seems curious.

As to your other comments, I think the concepts I've proposed
could be implemented in a way that is entirely backwards compatible
with IPv6/IPv4.  Someone assuming that compatibility is impossible
is not identical with it actually being impossible.

Yours,

Ran

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 17 Jan 2007 01:00:50 +0100

> semantics "contemporary" seems curious.

It's the "overloading is bad" thing that I would call contemporary.  
It has worked quite well for us for the better part of the 25 years  
that IPv4 has been around. As I said, IPX/CLNP type link handling  
isn't bad per se, but I'd rather hang on to the existing way of doing  
things until it's clear that an alternative is essential in solving  
the problem at hand.

> is not identical with it actually being impossible.

You may have overestimated some of us by leaving coming up with that  
part up to the reader.  :-)

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 16 Jan 2007 19:29:30 -0500

> It's the "overloading is bad" thing that I would call contemporary.

Shoch and others suggested such overloading was a bad idea MANY years  
ago.
So the thought that semantic overloading is bad simply is not a new one.
Whether one agrees with the notion or not, it isn't "contemporary"
but instead is long-standing within the Internet community.

Yours,

Ran

---

From: Roland Dobbins <[email-masked]>
Date: Tue, 16 Jan 2007 17:48:52 -0800

On Jan 16, 2007, at 4:00 PM, Iljitsch van Beijnum wrote:

> isn't bad per se, but I'd rather hang on to the existing way of  
> doing things until it's clear that an alternative is essential in  
> solving the problem at hand.

I strongly disagree with this - the 'existing way of doing things' is  
the result of design deficiencies in TCP/IP (both in IPv4, which is  
understandable, given its origins and the lack of experience with  
widely-deployed packet-switched networks at the time it was designed;  
more unforgivably, in IPv6, by which time folks should've known  
better) which have caused untold difficulties over the last 25 years,  
and has resulted in many Rube Goldbergian-types of 'solutions' which  
don't scale and are an operational nightmare today, on the networks  
we all use every day.  It has also resulted in the set of problems  
we're specifically trying to solve on this list.

-----------------------------------------------------------------------
Roland Dobbins <[email-masked]> // 408.527.6376 voice

                     Technology is legislation.

                         -- Karl Schroeder

---

From: Thomas Narten <[email-masked]>
Date: Tue, 16 Jan 2007 20:58:21 -0500

Ran,

>    (This is similar to a "routing prefix" in current parlance.)

Based on some of the followups, is this really the same thing as "IPv6
link"? That is, at any point that connects to the "sub-network", the
router can do some sort of address resolution (ARP/ND) to map the
identifier into a link-layer address, and then deliver the packet at
the link layer? (This is close, but not quite the same as L2 broadcast
domain).

Thomas

---

From: Geoff Huston <[email-masked]>
Date: Wed, 17 Jan 2007 13:51:57 +1100

>we're specifically trying to solve on this list.

Any engineered system makes trade-offs of some form or another. The 
overloaded semantics of an IP address are not in and of themselves 
deficient or forgiveable or otherwise - they were and are tradeoffs. 
The problem that we see now is that the deployed network is placing 
more emphasis on aspects of address semantics that appear to have a 
negative effect on routing scaleability. I wouldn't call that "bad", 
or necessarily "good". The point of this posting, however, is 
somewhat different. Having identified a shortcoming that does not 
mean that you have also identified the most appropriate solution 
space. i.e. while the problem may well be expressed as overloaded 
address semantics, the solution may not necessarily directly involve 
disambiguating the various semantic properties of an address. Other 
forms of approach, such as in various forms of overlays and adding 
layers of indirection are also feasible here.

regards,

     Geoff

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 17 Jan 2007 08:42:57 -0500

> the link layer? (This is close, but not quite the same as L2 broadcast

(Thomas educated me a bit off-list about what "IPv6 link" means,
from RFC-2460.)

If I understand that term correctly, the answer is yes,
a "Locator" names an "IPv6 link".  This does not imply a
link-layer with native broadcast facility.  For example,
a Frame Relay or ATM subnetwork could qualify, as could
a link-layer with a native broadcast facility, such as
wired Ethernet or wireless Ethernet or HF radio.

Ran

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 17 Jan 2007 15:17:25 +0100

On 2007-01-17 01:29, RJ Atkinson wrote:
> Shoch and others suggested such overloading was a bad idea MANY years ago.

I can't claim the seniority of Shoch, but when Yakov, Jon and I
wrote RFC 2101, we certainly didn't think we were describing
*good* developments. One sentence in that RFC apparently remains
true: "The exact nature of these identifiers requires further study."

In answer to a comment of Noel's, I think we're discussing this
here because achieving clarity on the loc/id question will allow
clarity on what is feasible to change in routing.

     Brian

---

From: Russ White <[email-masked]>
Date: Wed, 17 Jan 2007 15:42:37 -0500

> deficient or forgiveable or otherwise - they were and are tradeoffs. 

I think the problem here might be the folks designing the routing system
didn't specifically choose the overloading, and probably wouldn't have
if they had the choice.

Applications writers made the choice, I think, in reality to overload
more heavily on the IP address, over time. Since they don't feel the
pain of overloading more heavily (rather than less), it's logical
they're going to push more work on routing so they can do less work
(which is, to some degree, what heavy overloading provides--less work
for applications).

Maybe we need to figure out a way to join the pain of overloading with
the gain from overloading so people can actually see all the tradeoffs,
and make intelligent choices about it (?)....

:-)

Russ

- --
[email-masked] CCIE <>< Grace Alone

---

From: Russ White <[email-masked]>
Date: Wed, 17 Jan 2007 15:45:43 -0500

> wired Ethernet or wireless Ethernet or HF radio.

Perhaps the connection between the penultimate hop in the network and
the final destination (?).... In all cases, the penultimate device is
(or should be) the last device to handle the packet with the destination
layer 3 address intact.

This might be getting too esoteric, though. Just trying to think of
another idea for describing it without "smuggling in" the idea of a
broadcast link, etc.

:-)

Russ

- --

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 17 Jan 2007 23:29:02 +0100

> and make intelligent choices about it (?)....

Let's do a little thought experiment: what if we get all the  
application writers to change their applications within, say, the  
next two years, to completely remove any references to IP addresses  
and strictly use APIs that handle FQDNs. So we get to do whatever we  
want below the FQDN. Would that allow us to solve the routing  
scalability problem?

---

From: Russ White <[email-masked]>
Date: Wed, 17 Jan 2007 20:17:38 -0500

> Let's do a little thought experiment: what if we get all the application
> writers to change their applications within, say, the next two years, to
> completely remove any references to IP addresses and strictly use APIs
> that handle FQDNs. So we get to do whatever we want below the FQDN.
> Would that allow us to solve the routing scalability problem?

So, what you're saying is: If solving the locator/ID problem could
actually have a positive impact on routing, then we should see that
impact on routing today.

I think it depends on what you think the problem is.

To speculate.... If applications never ever contained an IP address,
then the application state could be transferred between two different IP
addresses. This is, in essence, what we're discussing here, anyway.

Consider shim6. In reality, once you think about it, this is all shim6
does, only rather than making the IP address invisible to the
application, it makes all possible IP addresses visible to the
application, and introduces signaling/tools to keep a session running
when the address changes. You're continuing to overloading the ID and
locator in the network, and doing the separation at the host. Today, I
would argue, there's no separation even at the host.

We can argue about where the intelligence required to switch IP
addresses on the fly should be, whether it's in the host, or in the
network (IE, whether we do the locator/ID split in the network, at some
edge, or on the host), but let's not, for the moment, and just assume
that since we've opened the door for such magic to exist, it just does.

The primary thing you've done with this is destroy the case for PI
space. This could collapse the table by making aggregation effective
again--modulo longer prefixes advertised for traffic engineering.

Looking back at this chain of logic (or illogic, perhaps), it seems to
me to all come down to this:

Do you believe traffic engineering is the problem? Then we don't care
about locator/ID separation.

Do you believe PI space is the problem? Then we care about the
locator/ID split.

Do you believe both are elements of the problem? Then we care to the
degree we think "solving" multihoming will make the routing table
stabilize, modulo the degree we think traffic engineering is the problem.

I'm not claiming to know the answer, just trying to figure out how we
can find common ground, and a good structure to wrap around this stuff.
We need a razor to apply occam's rule to, perhaps, so we can start
making progress.

:-)

Russ

- --

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 18 Jan 2007 12:50:38 +0100

On 18-jan-2007, at 2:17, Russ White wrote:

>> application

> actually have a positive impact on routing, then we should see that

No, I don't think I said that... As some of you may know I'm more  
skeptical about the virtues of a locator/identifier split than some/ 
most. Obviously the fact that applications deal with IP addresses  
makes renumbering and some other things harder, but I'm far from  
convinced that NOT having applications deal with locators will  
magically solve everything. Then again, it may solve enough to get us  
to a more affordable neighborhood on the growth curve. But that will  
require some new lookup and security stuff. I'm interested to know  
what others think about this.

> addresses. This is, in essence, what we're discussing here, anyway.

Right.

> application,

???

> and introduces signaling/tools to keep a session running
> locator in the network,

Right. Note that the shim6 protocols could easily be adapted to work  
with a full loc/id split, but this makes backward compatibility a  
nightmare and we'd need some way to map from the identifier to the  
locator set which means complexity and session startup delays.

> space.

Really? It's not just the applications that love to handle IP  
addresses, it's also all the firewalls and other access restrictions.  
I don't think this will be enough to wean enterprises off of PI.

> This could collapse the table by making aggregation effective

This is one thing I missed in the meeting report draft: we should be  
exploring better ways to do traffic engineering. (And also see if we  
can increase the average packet size on the network.)

> Do you believe both are elements of the problem?

Yes.

> Then we care to the

I thought we were solving multihoming in multi6/shim6 but apparently  
it needs some more solving...

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 18 Jan 2007 13:14:33 +0100

>> application, it makes all possible IP addresses visible to the

Iljitsch means, I think "That is the exact opposite of what
shim6 does." This isn't the shim6 list, but I think it's impotrtant
to clarify this. shim6 presents exactly one identifier-address
to the upper layer protocol, regardless of how many locator-addresses
are in use at network level.

     Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 18 Jan 2007 13:18:27 +0100

> Would that allow us to solve the routing scalability problem?

The problem with that thought experiment is that it fails even in
thought. There are lots of client/server scenarios where the FQDN of
the client is unknown or non-existent. It's the identifier (sic)
presented by the transport layer that is known by the server, and which
the server may need to refer to 3rd party servers.

     Brian

---

From: Russ White <[email-masked]>
Date: Thu, 18 Jan 2007 09:04:09 -0500

> locator set which means complexity and session startup delays.

Looking at it from a "higher level," IMHO, SHIM6 does exactly what NAT
does at the firewall (not PAT, NAT). You have:

o More than one IP address per host. In the case of NAT, you have one
per exit point. In the case of SHIM6, you have... One per exit point.

o If an IP address changes, you must have some way to transfer session
state from one host ID (since the IP address is the host ID in this
case) to another. NAT doesn't really have this capability, while SHIM6
does this at the host.

So, from the network's point of view, these two are doing the same
thing, it's just a matter of where you are doing it. Don't look at the
technical details--consider the traffic flow at the next hop beyond the
set of NATs--can you tell the difference between multiple NATs and
SHIM6? No.

> Really? It's not just the applications that love to handle IP addresses,
> it's also all the firewalls and other access restrictions. I don't think
> this will be enough to wean enterprises off of PI.

Perhaps, perhaps not. Today, most Enterprises use NAT to "solve" this
problem--they keep their locators consistent within their networks by
rewriting them at the edge of their network. This is specifically what
Roland was stating--when you put NAT on the host, you end up having to
rework all of your access control, security, etc, within the network to
rely on identifiers, rather than locators. This is one part of the
problem with overloading the two.

The real question, IMHO, comes down to:

o Should NAT be done at the host?
o Should NAT be done in the network someplace?
o Should NAT not be done at all?

We're probably going to have NAT with us always, so I don't think the
third option is very "real."

If we put NAT at the host, then we don't really care about the
locator/ID split, because NAT's being done at the host. In essence,
we've put the locator/ID split in the host, and we have to figure out a
way to do all of our network security and traffic engineering/QoS based
on the ID, not the locator.

If we put NAT in the network, then we care about the locator/ID split
within the network--making both visible in the network, because that
enables the tools needed to move state between two ID's among various
locators, and the tools to relate the two things, from a security/TE/QoS
perspective.

I'm not saying one is easier, or more preferred, I'm just trying, again,
to see how all these things interact, and bringing things out of the
"SHIM6 vs xxxx" world. Abstracting the problem into black boxes, so we
can see how this thing works, and how we can (realistically) change it.

It could be, though, that I'm the only person in the world that sees the
similarity here, and how it interplays with the locator/ID split.... :-)

> I thought we were solving multihoming in multi6/shim6 but apparently it
> needs some more solving...

I'm not certain SHIM6 has been accepted as the solution.... (?) Beyond
this, do we really understand, for certain, how "NAT on the host"
interrelates to the network infrastructure?

:-)

Russ

- --

---

From: Russ White <[email-masked]>
Date: Thu, 18 Jan 2007 09:21:45 -0500

> this will be enough to wean enterprises off of PI.

BTW, I thought I'd also ask about this one.... Perhaps it's different in
Europe, but in the US, I don't know of any enterprises running their
hosts on PI space. The networks I've touched recently include
Disney/ABC, Cabelas, Walmart, Walgreens, Wachovia, WAMU, Citigroup, and
a few dozen others, and they're all running on nonroutable address space
behind a bunch of NATs.

All of these would be PI if it weren't for NATs. So, it seems to me that
splitting the location from the ID would have a large impact on the need
/desire for PI space.

Most of the enterprise folks I know have just a couple of requirements
in regards to IP addresses:

1. Don't change them.
2. Give me a lot.
3. Make it so I can reach things outside my network.

There's nothing in that list about having a globally routable IP address
on a specific host--reachability is the requirement, not routability.

Is other folk's experience really completely the opposite of this? Are
there a lot of enterprise's out there screaming for PI space who can't
get it? It would be interesting to actually look at the statistics for
PI space assigned over time, to compare the percentage of space being
assigned to enterprises/SP's.

:-)

Russ

- --

---

From: "Rui Campos" <[email-masked]>
Date: Thu, 18 Jan 2007 14:24:39 -0000

Hi all,

I have been following the discussions in this list and I just would like to 
comment this FQDN issue.

IMHO, even if FQDNs are used as identifiers for hosts things will not work 
properly, at least without modifying the way FQDN assignment works in the 
current Internet (probably that's the your idea, I'm not sure).

Let's consider a host H that attaches itself to different domains along the 
time. While H is attached to the same domain (e.g., domain1.com.) its FQDN 
does not change. Then, H can be uniquely identified by a peer host even if its 
IP address changes, assuming that the mapping FQDN <-> IP address is handled 
properly. However, when H moves between different domains the FQDN will change 
at the same pace. For instance, at instant 1 H gets connected to domain1.com 
and its FQDN is "H.domain1.com.", at instant 2 it connects to domain 2 and its 
FQDN becomes "H.domain2.com." and, finally, at instant 3 it connects to 
domain3 and its FQDN becomes "H.domain3.com". Therefore, every session bound 
to an FQDN will break when the host moves from one domain to the other. On the 
other hand, how does a peer host will get informed about the current host's 
FQDN?

If we consider multi-homed hosts (i.e., hosts with multiple network 
interfaces) the problem is even exacerbated. In fact, multi-homed hosts may 
have an FQDN per network interface. Then, what FQDN will a peer host use to 
contact a multi-homed host? There is not a single FQDN that uniquely 
identifies the host regardless of its location and number of network 
interfaces.

BR,
Rui Campos

-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]]
Sent: quinta-feira, 18 de Janeiro de 2007 12:18
To: Iljitsch van Beijnum
Cc: [email-masked]
Subject: Re: [RAM] candidate properties of some new name types

     Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 18 Jan 2007 15:32:40 +0100

On 2007-01-18 15:04, Russ White wrote:
...
> set of NATs--can you tell the difference between multiple NATs and

I believe they are isomorphic at that point. They are not isomorphic
to the upper layer protocol, because it sees the identifier preserved
in one case and munged in the other, and that is basically all that
is wrong with NAT.

Shim6 is reversible NAT. I think from an upper layer PoV, any kind
of reversible NAT is basically OK.

    Brian

---

From: Russ White <[email-masked]>
Date: Thu, 18 Jan 2007 09:42:46 -0500

> of reversible NAT is basically OK.

Right--so, if you put "magic" in the network to make all NAT reversible,
then it's all okay, correct?

Isn't this, in the end, the same thing any locator/ID split
accomplishes? That's what I was trying to get to.... Iljitsch asked what
the impact of having a locator/ID split would be, and my speculative
reply is--about the same as NAT, I'm guessing, because they are similar
in what they do, when you look at it from the network's point of view.

If we look at the impact of NATs today, it's large, so I'd guess a
locator/ID split would have a pretty large impact, as well.

:-)

Russ

- --

---

From: Peter Sherbin <[email-masked]>
Date: Thu, 18 Jan 2007 07:26:46 -0800 (PST)

>    and is not tied to a specific interface or location.

An Identifier names the ultimate communicating entity. At the top it is an
application. If an interface itself needs to communicate than it gets an ID (in
addition to a locator). Otherwise it has a locator only.

Thanks,
Peter 

>       namespace for multiple purposes.

____________________________________________________________________________________
Want to start your own business?
Learn how on Yahoo! Small Business.
http://smallbusiness.yahoo.com/r-index

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 18 Jan 2007 16:53:28 +0100

Just in case, the elevator RFC for shim6: sessions (also non-TCP)  
start normally but after some packets the shim layer between IP and  
the next layer negotiates extra addresses with the correspondent.  
Afer a failure source/destination addresses are rewritten at the  
source so the packet can now flow over a different path and at the  
receiver they're restored so upper layers and applications are none  
the wiser.

> then it's all okay, correct?

Can we please move away from using the term "NAT"? A butcher and a  
surgeon appear to do the same thing at first too, until it turns out  
that the surgeon sows everything back together at the end and the  
butcher doesn't.

But yes, any transformation that is later reversed is ok. Adding/ 
removing locators is also a lot like encapsulating layer 3 packets in  
layer 2 frames. The crucial difference is that in order to map the  
layer 3 identifiers to the layer 2 locators there needs to be a  
lookup service. The ones we currently use (ARP/ND) don't exactly  
scale to internet-wide dimensions.

> in what they do, when you look at it from the network's point of view.

Well, maybe it looks the same when you treat the IP address as a  
locator and include an identifier somewhere that isn't mangled by the  
NAT, for instance, with HTTP/1.1 (although this isn't the best  
example). This also looks remarkably similar to GSE: the site exit  
router / NAT box rewrites the source routing goop while the  
identifier stays intact.

But for protocols that need to use the IP address as an identifier,  
NAT is basically a man in the middle attack.

NAT is of course a good way to avoid having to renumber large numbers  
of clients, but it doesn't solve multihoming or the push for PI  
because you still want stable addressing for the servers. Also,  
renumbering clients isn't exactly a hard problem anymore without NAT.

So the question is: is the IP address an identifier, in which case  
NAT is evil and we need to add locators below the IP address (which  
shim6 does but then confuses things by compressing away the original  
identifiers), or is the IP address a locator, in which case NAT is  
inconsequential but we need to get applications and protocols to use  
"real" identifiers instead of IP addresses?

I guess this means that the current locator/identifier overload is  
indeed a problem.

Obviously there are some problems with using FQDNs as we know them  
today as identifiers for the reasons that Brian and Rui mention, but  
I don't see that as something fundamental. A more important issue  
with non-locator identifiers is that there must be some way to assert  
ownership of an identifier. Today, the routing system lends authority  
to address ownership claims: I receive the packet, therefore this is  
my address. This isn't perfect, of course, but it works reasonably  
well. We have HBA/CGA but those don't work with IPv4 and public key  
crypto methods but those require one of those pesky PKIs and  
significantly more computation than what's needed today.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 18 Jan 2007 17:03:54 +0100

Russ,

On 2007-01-18 15:21, Russ White wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> 

I totally agree, but maybe add

4. Make it work 100% without unexplained session failures

(In case it isn't obvious, loss of NAT state leading to
session failures is an almost undiagnosable occurrence,
which most IT departments seem unaware of.)

I don't mean to NAT-bash here, there's been enough of that,
but we need to have a goal to ameliorate the systemic issues
of NAT.

    Brian

---

From: Russ White <[email-masked]>
Date: Thu, 18 Jan 2007 11:32:30 -0500

> Well, maybe it looks the same when you treat the IP address as a locator
> and include an identifier somewhere that isn't mangled by the NAT, for
> instance, with HTTP/1.1 (although this isn't the best example). This
> also looks remarkably similar to GSE: the site exit router / NAT box
> rewrites the source routing goop while the identifier stays intact.
> 
> But for protocols that need to use the IP address as an identifier, NAT
> is basically a man in the middle attack.

Yes....

> NAT is of course a good way to avoid having to renumber large numbers of
> clients, but it doesn't solve multihoming or the push for PI because you
> still want stable addressing for the servers. Also, renumbering clients
> isn't exactly a hard problem anymore without NAT.

- From a host perspective, yes, but now we've dropped the entire security
problem out of the discussion, again. It's not hosts that are hard to
renumber, it's security and infrastructure that make this hard.

> So the question is: is the IP address an identifier, in which case NAT
> is evil and we need to add locators below the IP address (which shim6
> does but then confuses things by compressing away the original

Right.... Today we have the two overloaded both in the network and in
the host....

> Obviously there are some problems with using FQDNs as we know them today
> as identifiers for the reasons that Brian and Rui mention, but I don't
> see that as something fundamental. A more important issue with
> non-locator identifiers is that there must be some way to assert
> ownership of an identifier. Today, the routing system lends authority to
> address ownership claims: I receive the packet, therefore this is my
> address. This isn't perfect, of course, but it works reasonably well. We
> have HBA/CGA but those don't work with IPv4 and public key crypto
> methods but those require one of those pesky PKIs and significantly more
> computation than what's needed today.

Yes....

:-)

Russ

- --

---

From: Russ White <[email-masked]>
Date: Thu, 18 Jan 2007 11:42:58 -0500

> but we need to have a goal to ameliorate the systemic issues

Completely agree... The problem with a loc/ID split is you have to have
magic someplace to make the two interrelate. Whether that magic is in
the host (such as SHIM6), or in the network (such as mobile IP, to some
degree), is up one of the problems we have to figure out.

:-)

Russ

- --

---

From: John Leslie <[email-masked]>
Date: Thu, 18 Jan 2007 14:20:46 -0500

Brian E Carpenter <[email-masked]> wrote:
> the client is unknown or non-existent.

   Absolutely!

> It's the identifier (sic) presented by the transport layer
           ^^^^^^^^^^
   No.

   It's the _locator_ presented by the TCP API...

   It is specifically the locator used by the IP stack to respond to
the opening SYN with a SYN ACK to continue opening the TCP connection.

   Since we've never defined a standard way to pass an _identifier_,
this _locator_ is used as a substitute identifier. (It has worked
surprisingly well over the years. ;^)

> that is known by the server, and which the server may need to refer
> to 3rd party servers.

   Absolutely!

   If we want to accomplish a locator/identifier split, we will have
to standardize a way for the originator of a TCP connection to pass
the identifier by which it wishes to be known by the other end.

   (It wouldn't be hard...)

--
John Leslie <[email-masked]>

---

From: Geoff Huston <[email-masked]>
Date: Fri, 19 Jan 2007 08:44:13 +1100

>of reversible NAT is basically OK.

reversible _deterministic_ NAT.

There are two problems in NAT space that make life hard:

1 - the other end gets presented with a different packet header than 
was sent (i.e. NATs are asymmetric and occluded)

2 - NATs are all different. There is no single NAT behaviour specification

The combination of these two factors as what makes life hard for 
applications. SHIM6 alters this to make the action symmetric and 
uniform. Of course, tunnelling does the same, as does MPLS and many 
(if not all other) forms of overlays and indirection.

Geoff

---

From: Ross Callon <[email-masked]>
Date: Thu, 18 Jan 2007 22:51:01 -0500

>want below the FQDN. Would that allow us to solve the routing

I think that we need to map this solution to the reasons that people
in practice today deaggregate IP prefixes or use PI addresses. At a
minimum, it seems to me that we would need:

   - (to deal with multi-homed networks) The ability to map FQDNs to
     multiple IP addresses, plus the ability of the Network Layer (possibly
     in the host?) to deal with multiple IP addresses for their own
     addresses, and also the other end's IP addresses, where some
     might be temporarily not working at any given time. To me this
     implies some way to figure out which are working (perhaps ICMP
     Ping with each address combination?)

   - (to deal with topology changes) Easy ways for entire companies to
     change their IP addresses while leaving their FQDNs the same.
     Questions like how to set route filters come to mind (in companies
     and in service providers).

   - Ways to do traffic engineering between ASs without requiring
     deaggregation of prefixes, or at least with limiting the distance
     (in some sense) that deaggregated routes would be advertised
     (there are some BGP mechanisms related to this, but I don't
     know how widely used tFrom [email-masked] Thu Jan 18 23:26:02 2007
Date: Thu, 18 Jan 2007 22:51:01 -0500
To: Iljitsch van Beijnum <[email-masked]>
From: Ross Callon <[email-masked]>
Subject: Re: [RAM] candidate properties of some new name types
Cc: [email-masked]

>want below the FQDN. Would that allow us to solve the routing

I think that we need to map this solution to the reasons that people
in practice today deaggregate IP prefixes or use PI addresses. At a
minimum, it seems to me that we would need:

   - (to deal with multi-homed networks) The ability to map FQDNs to
     multiple IP addresses, plus the ability of the Network Layer (possibly
     in the host?) to deal with multiple IP addresses for their own
     addresses, and also the other end's IP addresses, where some
     might be temporarily not working at any given time. To me this
     implies some way to figure out which are working (perhaps ICMP
     Ping with each address combination?)

   - (to deal with topology changes) Easy ways for entire companies to
     change their IP addresses while leaving their FQDNs the same.
     Questions like how to set route filters come to mind (in companies
     and in service providers).

   - Ways to do traffic engineering between ASs without requiring
     deaggregation of prefixes, or at least with limiting the distance
     (in some sense) that deaggregated routes would be advertised
     (there are some BGP mechanisms related to this, but I don't
     know how widely used they are). This gets into things like the
     difference between "hot potato routing" (forward the packet to
     a peer AS as close to the source as possible), versus "cold
     potato routing" (forward the packet to the same peer AS, but
     closer to the destination). Engineers from network operators
     could talk about this sort of thing much better than I could,
     but I sort of suspect that this might be difficult.

I am also suspecting that the damage to the host stacks might be
more significant than all of these concerns combined.

Ross

---

From: [email-masked]
Date: Fri, 19 Jan 2007 12:29:54 +0100

> > Really? It's not just the applications that love to handle IP
addresses,
> a few dozen others, and they're all running on nonroutable address space

Yes, but look what I have found in ARIN:
- Citigroup (AS25883) CITIGROUP    25883
  Citigroup (AS22650) CITIGROUP-KNIGHT-FINANCIAL-AS22650    22650
  Citigroup (AS30284) CITIGROUP-BANAMEX    30284 - 30285
  Citigroup (AS32111) CITIGROUP-JAPAN    32111
  Citigroup (AS32287) SOLANA-CITIPLEX    32287
  Citigroup (AS33463) CITIGROUP-GLOBAL-ANYCAST-DNS    33463
  Citigroup (AS33464) CITIGROUP-BACKBONE    33464
- Cabela's (AS14527) CABELAS    14527
- WALMART.COM (AS17374) WALMART    17374
- Disney Worldwide Services, Inc. (AS25932) DWSI    25932
  Disney Worldwide Services, Inc. (AS29736) DWS-ORL    29736
  Disney Worldwide Services, Inc. (AS30311) DWS-LON    30311
  Disney Worldwide Services, Inc. (AS40051) DWS-HK    40051
  Disney Worldwide Services, Inc. (AS11812) DWS-UTAH    11812
- Walgreens Co (AS13626) WALGREESN    13626
- WACHOVIA CORP (AS4243) NC-FUNB-AS    4243
  Wachovia Operational Services Corporation (AS2011) WACHOVIA    2011

> splitting the location from the ID would have a large impact on the need

I have also queried the ARIN database for network addresses
assigned to those companies and the number of lines is too
big to include it in this note. They seem to have many
PI addressing already.

> 3. Make it so I can reach things outside my network.

Therefore, according to the ARIN database there is a 4th need:
  4. Give me multihoming.

... what is in line with the results presented by
G. Huston at the recent IAB Routing Workshop:
"The IPv4 network continues to get denser, with
finer levels of advertisement granularity. More
interconnections, more specific advertisements"

> on a specific host--reachability is the requirement, not routability.

I think routability is also a need. This is why they
too want multihoming. So IMHO they want NAT+PI at
the same time.

Regards,
Juanjo

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 19 Jan 2007 13:42:26 +0100

On 19-jan-2007, at 4:51, Ross Callon wrote:

>> completely remove any references to IP addresses

>     multiple IP addresses,

DNS.

> plus the ability of the Network Layer (possibly

Required in IPv6, also possible in many IPv4 implementations.

> and also the other end's IP addresses, where some

We came up with draft-ietf-shim6-failure-detection-07.txt to figure  
out which combination of source/dest addresses works.

>     and in service providers).

This is doable if you can have overlap between the old and the new  
addresses.

>     know how widely used they are).

This is one of the things I've been saying for a while now: we need  
better metrics in BGP, because we have none that work across multiple  
ASes. But TE doesn't need to be done in BGP. An obvious alternative  
is using DNS SRV records with different priorities for different  
addresses.

> more significant than all of these concerns combined.

I'm not too worried about the stack. SCTP works, TCP with multiple  
addresses has been implemented unless I'm mistaken, and we have a  
pretty good handle on shim6. The more challenging part is removing  
the addresses from the applications and the protocols. And host-based  
solutions aren't all that popular, so we'd need a way for middleboxes  
to do the address juggling. One way to do this is with a proxy, where  
the source sets up a lower-layer session towards a proxy and the  
proxy looks at the identifier and sets up a new session towards the  
real destination. Another solution is NAT where the identifier is  
carried in-band so call-backs and referrals are possible. In both  
cases, additional mechanisms to recover from middlebox failures would  
be required and using the reverse DNS won't work because the source  
address isn't the one held by the actual source.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 19 Jan 2007 06:55:44 -0600

> 1 - the other end gets presented with a different packet header than was 
> sent (i.e. NATs are asymmetric and occluded)
>

Based on discussions in BEHAVE, I believe that Geoff's statement here is 
both correct and understated. I can't find the quote in BEHAVE meeting 
minutes, but I remember vividly someone last year saying that they find new 
broken NAT behavior every time they test a new NAT device, and Cullen and 
Francois have both talked repeatedly about NAT devices that change behavior 
over the life of a binding, apparently based on either elapsed time or CPU 
load on the NAT device.

So it seems correct to say that there may not even be a single NAT behavior 
specification FOR A SPECIFIC NAT DEVICE OVER TIME, and that's what really, 
really reeks.

> applications. SHIM6 alters this to make the action symmetric and uniform. 
> Of course, tunnelling does the same, as does MPLS and many (if not all 
> other) forms of overlays and indirection.

I think this is correct as well.

Spencer

---

From: Russ White <[email-masked]>
Date: Fri, 19 Jan 2007 09:27:15 -0500

>   Wachovia Operational Services Corporation (AS2011) WACHOVIA    2011

Of course. Do you know if they use them for actually addressing hosts,
or for facing out to the Internet addresses at their NAT boxes? I
actually happen to know the answer to this question, but I'll let you
guess. :-)

Second question--did they get those addresses before, or after, they
started installing NAT boxes at their edges? In other words, when they
were allocated those addresses, were they actually using them to number
hosts, and has their policy changed since that time?

Don't assume a PI address assigned means the company is using that space
in the way you think.

> too want multihoming. So IMHO they want NAT+PI at

IMHO, if you gave them reversable NAT, you would kill off even much of
what you're seeing here in the table. Again, this comes from actual
discussions with the folks who run these networks, and many others, not
just examining the tables.... In fact, I'll make it a point to ask this
specific question next week, in a couple of meetings I have with some
folks, and then get back to the list with the answers.

:-)

Russ

- --

---

From: Russ White <[email-masked]>
Date: Fri, 19 Jan 2007 09:33:03 -0500

> minutes, but I remember vividly someone last year saying that they find
> new broken NAT behavior every time they test a new NAT device, and
> Cullen and Francois have both talked repeatedly about NAT devices that
> change behavior over the life of a binding, apparently based on either
> elapsed time or CPU load on the NAT device.
> 
> So it seems correct to say that there may not even be a single NAT
> behavior specification FOR A SPECIFIC NAT DEVICE OVER TIME, and that's
> what really, really reeks.
> 

Of course, we're not talking about current NATs--nor PATs, which many
people confuse for NATs. I'll venture to guess that most of the
behaviors you're seeing are on the PAT side, not the NAT side.

Second, the presumption was that if there some "magic" to make NAT's
reversable, then, from the network's perspective, NATs are the same as
something like SHIM6. As for the host, if the host is dealing with
identifiers, rather than locators, then changes in the locator shouldn't
make any difference. Like with a router, where changes above the IP
header shouldn't matter (I'm not saying they don't, I'm saying that, in
theory, they shouldn't), to a host, changes below the transport header
shouldn't matter.

That's the entire reason behind layering, isn't it? Isn't the base of
the problem we're dealing with here, in terms of loc/ID, really a big,
fat, layering violation? (Or, it could be that I'm insane, a possibility
my children would gladly endorse).

:-)

Russ

- --

---

From: "tom.petch" <[email-masked]>
Date: Fri, 19 Jan 2007 15:32:12 +0100

Russ

I know of one large international enterprise that used NAT exclusively, added up
all the PI addresses that they had been allocated around the world by various
registries, found it was way in excess of their requirements, and  ...

gave them back to the LIRs?  no way, they got rid of NAT.

Tom Petch

---

From: Marshall Eubanks <[email-masked]>
Date: Sat, 20 Jan 2007 11:54:27 -0500

> gave them back to the LIRs?  no way, they got rid of NAT.

I would regard this as a good thing, given the prevalence of the "NAT  
provides security"
meme.

Regards
Marshall