Subject: [arch-d] thoughts

From: RJ Atkinson <[email-masked]>
Date: Tue, 14 Nov 2006 15:21:08 -0500

An Identifier should name a node, rather than naming an
interface of a node, a point of attachment, or a location.

A given node will have one or more Identifiers at a given
point in time.

An Identifier has a high probability of being globally unique,
but is not guaranteed to necessarily always be globally unique.

An Identifier will be unique within the context of a
given Locator.

A typical node should easily be able to determine its Identifier(s)
without consulting external sources of information.  Some special
case kinds of nodes might need to consult external information,
but such special cases, if any, should be rare.

A Locator should name a single sub-network, rather than
naming a node or an interface.

A given node will have at least one Locator for each
different upstream connection.

	Example: a node with 2 interfaces where each interface
	connects to a different sub-network will have at least
	2 Locators while those 2 interfaces are up and working.

	Example: If one has multiple logical sub-networks on a
	single physical link, then a node with only 1 interface
	(where that 1 interface were attached to that multi-netted
	link) might have more than one Locator concurrently.

A transport-layer protocol will not be aware of the Locator(s)
in use by any endpoint of any transport-layer session.  Instead,
transport-layer protocols will only include endpoint Identifiers
in their session state.

	EXAMPLE:  TCP pseudo-header checksum will include Identifiers,
	but not Locators.

	NOTA BENE:  If one looks at real implementations, even
	"stateless" transport protocols such as UDP have some
	session state (e.g. the Protocol Control Block in 4.4 BSD).

One ought to be able to learn a node's current set of
Identifiers and current set of Locators if one knows
the Fully Qualified Domain Name of that node.

One need not be able to directly learn the FQDN of a node
given only the Identifier of the node.

	NOTA BENE:  This might sound unworkable, but consider
	that one might be able to first query a node to ask
	what its FQDN is (e.g. ICMP), then use a separate
	mechanism (e.g. DNSsec) to authenticate that answer.

A non-cryptographic authentication mechanism should be available
that protects against off-path active attacks on a session, for
optional use in low threat environments.

Cryptographic authentication and confidentiality mechanisms should
be available in the network layer.  These should bind to the
Identifier and ignore the Locator.

	NOTA BENE:  ESP/AH would have bound to an Identifier had
	one existed a decade ago.  Only because there was no other
	option did ESP/AH bind to the whole IP address.  I went to
	A LOT of trouble with ISAKMP/IKE to make sure that a wide
	range of name types are supported in key management.  The
	better ESP/AH implementations can use FQDNs or such like in
	their Security Associations, in lieu of the IP address.

A multi-homed node or site will never increase the entropy of the
default-free zone of the inter-domain routing table.  Instead,
the Locator in use will vary as appropriate to achieve the
multi-homing objectives.

A mobile node or site will never increase the entropy of the
default-free zone of the inter-domain routing table.  Instead,
the Locator in use will vary as appropriate to achieve the
mobility objectives.

Full backwards compatibility with deployed network-layer and
transport-layer protocols is nice to have, but is not a requirement.

Yours,

Ran
[email-masked]

PS:	The lack of implementation detail is quite deliberate.
	As JNC might comment, this note is an attempt to talk about
	things architecturally.

_______________________________________________
Architecture-discuss mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/architecture-discuss

---

From: David Conrad <[email-masked]>
Date: Fri, 17 Nov 2006 11:41:18 -0800

Ran,

The model I have is as follows:

a) source and destination end points are labeled with identifiers
b) the destination identifier is used at the edge (be it first hop  
router, customer/ISP boundary, or something in between) of the source  
network to look up the destination locator(s)
c) the source edge device (router) picks an appropriate destination  
locator from the set returned by the lookup
d) packets are encapsulated with locators in the source and  
destination fields for transit routing
e) at the destination edge, the packet is de-encapsulated and  
forwarded to the destination end point identifier.

With that model in mind, I have the following questions/comments:

> interface of a node, a point of attachment, or a location.

Why wouldn't an identifier name an interface?  What do you gain by  
labeling a node?

> A given node will have one or more Identifiers at a given

Yes.

> but is not guaranteed to necessarily always be globally unique.

If an identifier is not globally unique, the lookup will be ambiguous  
and not securable.

> An Identifier will be unique within the context of a

This implies identifiers would potentially need to change should  
locators shift.  This seems like a mistake to me as it removes one of  
the primary advantages I see is having identifiers.

> but such special cases, if any, should be rare.

I'm not sure what this means.  Can you provide an example?

> naming a node or an interface.

I believe a locator should name a connection to the routing system.   
What is on the other side of that connection is opaque and irrelevant  
to the routing system.

> different upstream connection.

Right.

> in use by any endpoint of any transport-layer session.

Exactly.

> the Fully Qualified Domain Name of that node.

Yes.

> given only the Identifier of the node.

This is the case today in the sense that there is no global law  
saying you must set up the {in-addr,ip6}.arpa PTR to match the  
forward name.

> optional use in low threat environments.

Can you explain what a "non-cryptographic authentication mechanism"  
is in this context?

> Identifier and ignore the Locator.

In my model, since encapsulation is used, you can have crypto auth/ 
confidentiality as an option for both locators and identifiers.

> the Locator in use will vary as appropriate to achieve the

Right.

> the Locator in use will vary as appropriate to achieve the

Yep.

> transport-layer protocols is nice to have, but is not a requirement.

At this point, I suspect lack of backwards compatibility will likely  
result in non-deployability.

Rgds,
-drc

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 17 Nov 2006 15:06:03 -0500

> a) source and destination end points are labeled with identifiers

"end point" means a stack, a node, an interface, or something else ?

> router, customer/ISP boundary, or something in between) of the  
> source network to look up the destination locator(s)

This implies that one can *directly* go from Destination Identifier
to Destination Locator, which is not one of my assumptions.  In
my model that can be done, through a layer of indirection, but
not directly.

> locator from the set returned by the lookup

In my model, the originating node selects a Destination Locator
from the list in the DNS for the destination node's FQDN.  There
is no requirement that this Destination Locator remain immutable
end-to-end, but the Identifier does have to remain immutable
end-to-end.  Edge routers are not required to re-write a Locator,
but if one does then no operational problem ensues.

> destination fields for transit routing

In my model, no tunnelling or packet encapsulation is required.
Nothing prohibits, for example, GRE tunnelling done for the
same reasons it might be done today in the IPv4 Internet.

> forwarded to the destination end point identifier.

Again, in my model, no decapsulation is ever required.

As it happens, I know of silicon where encaps/decaps is nearly free,
but there are always MTU issues with encapsulation and for more
commonplace routers encaps/decaps is far from free.  So for both
architectural simplicity and operational considerations, I'd really
prefer to avoid requiring encaps/decaps of ordinary traffic.

> With that model in mind, I have the following questions/comments:

First, we have somewhat different models in our heads,
which probably accounts for the discrepancies.

> Why wouldn't an identifier name an interface?  What do you gain by  

Better native support for mobility.  What I care about is which
end system ("stack" if one thinks about an MLS OS or distributed OS)
I am communicating with, not which interface on that node the
packets happen to arrive-on/depart-from.

If we're going to have a clean new architecture, mobility needs
to be a native part of the new approach, not an add-on, IMHO.

> If an identifier is not globally unique, the lookup will be  
> ambiguous and not securable.

This is what many think, but it isn't true.

Again, in my model, one never starts with an Identifier to do any sort
of lookup.  One always does an ID lookup in the forward direction
(FQDN-->Identifier), never the reverse (Identifier-->FQDN).  If
one is already communicating with a node, but does not know its
FQDN, then one can send an control packet asking for its FQDN.

One need not trust that result blindly, but instead can authenticate
the FQDN answer by doing a forward lookup with DNS Security enabled.

DNS Security should work fine to authenticate bindings to the FQDN.
(I do assume there are new DNS resource records for L and I.)

> locators shift.  This seems like a mistake to me as it removes one  
> of the primary advantages I see is having identifiers.

No.
Identifiers never need to change even if the Locator set changes.
This is a very important point.

> I'm not sure what this means.  Can you provide an example?

I want to try to avoid situations where an Identifier is externally
assigned (e.g. IANA-->RIR-->Organisation-->node), but instead have
Identifiers based on something a typical node can find within itself.

> I believe a locator should name a connection to the routing  
> system.  What is on the other side of that connection is opaque and  
> irrelevant to the routing system.

Your distinction seems subtle to me, please say more.

(You seem to be saying that a Locator should name an SNPA,
and also that an SNPA is not the same as a sub-network.)

> saying you must set up the {in-addr,ip6}.arpa PTR to match the  

See above where your earlier comments seemed to imply that one
might want to make an Identifier-->something else lookup.

> Can you explain what a "non-cryptographic authentication mechanism"  

Something that does not involve expensive maths/computation
and yet will protect a session against off-path attacks.

> confidentiality as an option for both locators and identifiers.

In my model, AH/ESP can be used as originally desired.  The current
binding of AH/ESP to the IP Address was caused by the limitations
of the Internet Architecture circa 1995.  I never thought it was a
good idea, but it was necessary at the time.  This also relates to
why I (vigorously) campaigned for ISAKMP and the IPsec DoI to support
a *wide* range of Identity types.

The key change to AH/ESP is that they ignore Locators and bind
Security Associations only to Identifiers.  This means multi-homing,
NAT/NAPT, and mobility no longer have any adverse impact on native
IPsec.  No UDP-tunnel-hack-for-NAT extensions would ever be needed.

> At this point, I suspect lack of backwards compatibility will  
> likely result in non-deployability.

Well, the currently deployed transport-layer protocols all bind
to information used as a Locator, which tends to kill the idea
of an Identifier/Locator approach.  In turn, this forces one down
the SHIM6 ("NAT inside the host stack") approach.  However, ISPs
said clearly at NANOG that SHIM6 was not an accceptable approach.

The only change to on-the-wire transport protocols that I'd propose
is to remove location information from the pseudo-header calculations.

I think the network-layer can be implemented for either IPv4 or IPv6
as extensions -- and I think that this could be implemented so that
both "old" IPv4/IPv6 and the I/L split variant could be supported
concurrently (for different sessions, however).

Cheers,

Ran
[email-masked]

---

From: David Conrad <[email-masked]>
Date: Fri, 17 Nov 2006 16:44:05 -0800

Ran,

I realized we have different models: I'm trying to understand yours  
by comparing to mine.

> "end point" means a stack, a node, an interface, or something else ?

Interface (or perhaps more correctly, stack associated with an  
interface).

> my model that can be done, through a layer of indirection, but

Hmm.  I'm assuming a mapping function:

	mapping(identifier) = 1 or more locators

Conceptually, the mapping function could be the DNS (although it  
doesn't have to be).  If the DNS were used, it would be along the  
lines of:

# ID                                       RRType  RRdata
0.1.2.3.4.5.6.7.8.9.a.b.c.d.e.f.id.arpa IN LOCATOR A000::0001 100 ...
                                         IN LOCATOR B000::0001 200 ...
                                         ...

(which could obviously be DNSSEC signed to provide some level of data  
authenticatability).

Could you explain a bit more about the way you're viewing getting  
from an identifier to a set of locators?

>> c) the source edge device (router) picks an appropriate  
>> destination locator from the set returned by the lookup
> from the list in the DNS for the destination node's FQDN.

Just to be clear, your model requires modification to all nodes (that  
is, there is a layer inserted between the identifier and locator that  
does the DNS lookup)?

> same reasons it might be done today in the IPv4 Internet.

Do I understand correctly that the reason explicit tunnels are not  
necessary is that translation is being done in the end nodes, where a  
sort of implicit tunnel is created in between the transport and  
network layers (the place where the translation between identifier to  
locator at the source and between locator and identifier at the  
destination is being done)?

> commonplace routers encaps/decaps is far from free.

This was an issue I was concerned about and had come up with an  
approach that used destination field rewriting at both ends (edges).   
However, I've since become convinced that encapsulation is a more  
flexible and (with the exception of potential MTU problems) better  
approach.  Debugging is much easier since the original packet as seen  
by the application is available, you have the option of popping off  
the encapsulation in mid-flight (e.g., a transit router detects  
destination unreachability and pops off the transit layer in order to  
try and discover an alternative locator in the multi-homing case),  
ability to have flow labels that have meaning both to the end points  
as well as different flow labels for transit networks, etc.

> Better native support for mobility.

In my model, transitioning across service provider boundaries is  
implemented by changing the identifier to locator mapping.  In the  
simplest case (and using DNS as the mapping mechanism as an example  
only), a site changing ISPs would follow this basic process:

a) buy new connectivity
b) change the Rdata of the LOCATOR RR to reflect the new ISP's prefix
c) wait for TTLs of LOCATOR RRs that had old ISP's prefix to expire
d) disconnect old ISP

Mobility is simply a special case of this basic process.  Instead of  
'buy connectivity', you transition across access provider  
boundaries.  The old access network gets instructed to forward to the  
new access network until the TTL pointing to the old access network  
expires.

> to be a native part of the new approach, not an add-on, IMHO.

I'm too pessimistic (or cynical if you prefer) to believe we'll be  
able to have a clean new architecture.  My model assumes there is too  
much inertia in the Internet already to throw out the existing IPv6  
deployment.  As such, I'm trying to minimize changes to existing  
deployments.  The _only_ change necessary in my model is at the  
edges.  No change to existing stacks (either in end hosts or in most  
routers) necessary.

> (I do assume there are new DNS resource records for L and I.)

I'm not sure I follow.

An application does a DNS lookup to translate a fqdn to an identifier.
The network stack translates the identifier into a locator.
At the other end, how does the network stack unambiguously translate  
the locator back into the  correct identifier?

> Identifiers based on something a typical node can find within itself.

I see.  In my model, I assume identifiers are globally unique and are  
propagated somehow into a globally available map (e.g., the DNS).   
This implies some allocation authority, albeit since there is no need  
for hierarchical allocation of identifiers, can be pretty much anyone.

>> system.  What is on the other side of that connection is opaque  
>> and irrelevant to the routing system.

I don't want to preclude one routing domain's identifiers being used  
as another routing domain's locators.  For example, I can imagine the  
following encapsulations:

1. map(end point.ID.ARPA) -> ISP.NET global locator
2. forward toward ISP.NET
3. map(global locator.ISP.NET) -> traffic engineering locator
4. forward to ISP.NET's side of particular ISP.NET peering point  
defined by the traffic engineering locator
5. de-encap traffic engineering locator and give to peer/transit  
provider
...

> and also that an SNPA is not the same as a sub-network.)

SNPA?

>> Can you explain what a "non-cryptographic authentication  
>> mechanism" is in this context?

Can you provide an example?

Rgds,
-drc

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 17 Nov 2006 20:32:26 -0500

> Interface (or perhaps more correctly, stack associated with an  

I'm not entirely clear yet what you mean.  When I think of a "stack",
for example on my laptop, that same stack might concurrently be
associated with multiple link interfaces (e.g. 10/100/1000baseT,
802.11, & 1394).

For a conventional system, I'm comfortable with "node" meaning
roughly the same thing as "stack".  For unusual systems, such
as loosely coupled distributed systems, multi-level secure systems,
or virtualised systems, the term "node" becomes less crisp --
because the lines are necessarily drawn somewhat arbitrarily
in such cases.

>>> b) the destination identifier is used at the edge (be it first  
>>> hop router, customer/ISP boundary, or something in between) of  
>>> the source network to look up the destination locator(s)
>>
> (which could obviously be DNSSEC signed to provide some level of  
> data authenticatability).
>

Yes, but first please explain how would one end up with an Identifier
in hand without also happening to have a Locator for that node ?

If one knows the FQDN of a node, then one could find both Locator(s)
and Identifier(s) from DNS records using forward resolution.

> Just to be clear, your model requires modification to all nodes  
> (that is, there is a layer inserted between the identifier and  
> locator that does the DNS lookup)?

I am talking architecturally, not about implementation.
It isn't obvious to me that the layering would have to vary from now.

Oh, and I think this architectural change could be done without
modifying any existing routing protocols or forwarding engines.

> necessary is that translation is being done in the end nodes, where  
> a sort of implicit tunnel is created in between the transport and  
> network layers (the place where the translation between identifier  
> to locator at the source and between locator and identifier at the  

"Translation" covers a lot of possible meanings.  I'm not sure which
you mean.  I am trying to avoid having NAT/NAPT in the hosts,
so this is different architecturally from SHIM6 (as best I understand
SHIM6).  I am trying to avoid requiring tunnelling.

>>> Why wouldn't an identifier name an interface?  What do you gain  
>>> by labeling a node?
> Mobility is simply a special case of this basic process.  Instead  
> of 'buy connectivity', you transition across access provider  
> boundaries.  The old access network gets instructed to forward to  
> the new access network until the TTL pointing to the old access  
> network expires.

Hmm.  My concept is that if one were multi-homed to different providers,
then one would necessarily have more than one Locator (at least one
Locator per provider) and each Locator would be present concurrently
in the DNS.

If a service provider went away (e.g. backhoe), then one would update
one's DNS to remove the associated Locator(s).

Which provider gets used for outbound traffic would be the originating
node's choice in the first instance, though nothing would preclude a
Locator from being modified during transit for some reason (because
Locators are used *only* for packet routing/forwarding).

As you say, mobility and multi-homing are really the same case
if one gets the architecture right, though I don't know that the
old access network would necessarily have to forward packets.

> able to have a clean new architecture.  My model assumes there is  
> too much inertia in the Internet already to throw out the existing  
> IPv6 deployment.  As such, I'm trying to minimize changes to  
> existing deployments.  The _only_ change necessary in my model is  
> at the edges.  No change to existing stacks (either in end hosts or  
> in most routers) necessary.

I'm assuming that this list is about architecture and so I'm talking
about architecture.  I'm not necessarily talking about IAB RAW output,
though clearly that has revived this list.  I am definitely not
talking about any IETF work at this point -- just architecture.  It
sounds like you are talking specifically about IETF work relating
to IAB RAW, which maybe overlaps but is not exactly the same topic.

The architecture I'm proposing would not require any changes to
forwarding processes or routing protocols, nor to ARP/ND.  It
would change TCP/UDP by altering the pseudo-header checksum
to include only Identifiers, never Locators.

How would your system work in the case where the packet emitted
from the origin node used both AH and ESP -- that is, the payload
is opaque and (nearly) all of the header fields are authenticated
(hence immutable) ??   Is this where the tunnelling comes in ?

> An application does a DNS lookup to translate a fqdn to an identifier.

One can get the Locator from DNS in the same transaction, right ?

> The network stack translates the identifier into a locator.

FQDN->Locator mapping is not necessarily in the network stack.
(I'm not talking about implementation here. :-)

> At the other end, how does the network stack unambiguously  
> translate the locator back into the  correct identifier?

There are several options.

One possible alternative is to carry Source Identifier, Destination
Identifier, Source Locator, and Destination Locator in each packet.
That might or might not be the best option.  I remain open minded.

> I see.  In my model, I assume identifiers are globally unique and  
> are propagated somehow into a globally available map (e.g., the  
> DNS).  This implies some allocation authority, albeit since there  
> is no need for hierarchical allocation of identifiers, can be  
> pretty much anyone.

There will need to be some centralised allocation authority if
one wants absolutely globally unique identifiers.

If that authority involves humans, there is a good chance of an
accident at some point where a few identifiers would be duplicated.
So I'd rather not require an absolutely globally unique identifier.

> I don't want to preclude one routing domain's identifiers being  
> used as another routing domain's locators.  For example, I can  
> imagine the following encapsulations:

I want to always ensure that Locators are never Identifiers,
and vice versa.  Overloaded semantics is how we got into this
mess.  I really want to avoid overloaded semantics.

>> and also that an SNPA is not the same as a sub-network.)

sub-network point of attachment -- that old ISO CLNP term. :-)

> Can you provide an example?

I don't want to get into engineering.  For now, maybe just take
it as a design property for an alternative architecture.

Cheers,

Ran

---

From: John Day <[email-masked]>
Date: Fri, 17 Nov 2006 22:07:10 -0500

In reading the conversation between the three of you, I get the sense 
that you are still trying to solve the current engineering problem. 
This is one of the better abstract discussions I have seen on this 
list, but I don't think you have really boiled it down to its barest 
elements.  There is still too much flesh on the bones.  It is getting 
in the way of your thinking.  You need to work out in a sense what 
the general theory is before trying to apply it to this specific 
architecture.  I realize some think this is the only architecture, 
but for a moment consider the idea that there are rules that might 
underlie this one and as well as others.

Take care,
john

---

From: John Day <[email-masked]>
Date: Fri, 17 Nov 2006 23:14:50 -0500

The primary problem you are both struggling with is that there are 
two location-dependent identifiers: one for points of attachment and 
one for nodes.  You are trying to make one thing do for both.  It 
doesn't work in Operating Systems and it doesn't work here.  This is 
just like OSs.  You need a logical and physical address spaces under 
the application name space.  For the last 35 years, we have only had 
a physical address space.  The point of attachment id does not have 
to be global.  Neither does the node address, but if it isn't then 
you have to do relaying at the Application.

You keep talking about nodes having more than one identifier.  No. 
There may be more than one point of attachment (interface) bound to a 
node.  But the identifiers for the points of attachment and the node 
are all distinct.

The Loc/Id discussion is misleading. It is a red-herring.  It isn't 
the real issue.  The architecture you are working in only has point 
of attachment identifiers.  Your endpoints are what I would have to 
call names for instances of application-protocols, not applications. 
That makes your Loc/Id discussion about  the mapping of identifiers 
between application-protocol-instances and points of attachments. 
You are still tying everything to the physical. You have still failed 
to create the logical address space you need.

Look we were building an experimental network.  Passing data was a 
much bigger worry than the nuances of addressing.  We didn't really 
think about addressing.  We expected our experimental network to be 
replaced based on what we learned.  Using only switch port numbers 
was a mistake.  Well it was okay for early experimenting but not for 
production. We knew that by 72.  So quit trying to build solutions 
that make it work.  They will always be kludges.

Take care,
John

At 11:41 -0800 2006/11/17, David Conrad wrote:
>What is on the other side of that connection is opaque and 
>In my model, since encapsulation is used, you can have crypto 
>auth/confidentiality as an option for both locators and identifiers.
>

---

From: RJ Atkinson <[email-masked]>
Date: Sat, 18 Nov 2006 15:04:08 -0500

On  17 Nov 2006, at 23:14, John Day wrote:
> two location-dependent identifiers: one for points of attachment  
> and one for nodes.

It is not clear to me why a node identifier is "location-dependent".
A goal of mine is to have the node Identifier be location independent.

> You keep talking about nodes having more than one identifier.  No.

Please explain why having more than one Identifier (note capitalisation)
per "node" or "stack" is undesirable.

> There may be more than one point of attachment (interface) bound to  
> a node.

Agree.

> But the identifiers for the points of attachment and the node are  
> all distinct.

Well, I'd agree that names for "points of attachment" are different
from names for a "node" (or "stack").

> The architecture you are working in only has point of attachment  
> identifiers.  Your endpoints are what I would have to call names  
> for instances of application-protocols, not applications. That  
> makes your Loc/Id discussion about the mapping of identifiers  

The above is not obvious to me.

Cheers,

Ran
[email-masked]

---

From: Andrew McGregor <[email-masked]>
Date: Sun, 19 Nov 2006 19:43:42 +1300

> A goal of mine is to have the node Identifier be location independent.

That's kind of the point of having it, right?

> per "node" or "stack" is undesirable.

How about: there can be more than one Identifier per physical node/OS  
instance/application/whatever, but BY DEFINITION, each one defines a  
different node or stack.

>
>> There may be more than one point of attachment (interface) bound  
>> to a node.
>
> Agree.
>

I *think* he was saying that identifier for the node must not be one  
of the identifiers for points of attachment.

---

From: John Day <[email-masked]>
Date: Sun, 19 Nov 2006 07:09:06 -0500

>That's kind of the point of having it, right?

No,  Read Saltzer. RFC 1498.

>How about: there can be more than one Identifier per physical 
>node/OS instance/application/whatever, but BY DEFINITION, each one 
>defines a different node or stack.

You missed the point of Ran's comment.  Ran was distinguishing 
interface from stack.  For him, interfaces and stacks have distinct 
fate sharing properties.  My view is that one can not assume that is 
always the case, so you can't make it a property of the architecture. 
(Ran and I were having off-list discussions.)

>>
>>>There may be more than one point of attachment (interface) bound to a node.
>>
>>Agree.
>>

We all agree on that.  I believe that the node identifier must be 
location dependent as Saltzer found.  Ran wants a 
location-independent identifier associated with Transport as a short 
handle way of getting all applications on this system.  This is a 
radical change to Transport.  But more such a name has more to do 
with application management, not IPC.  And thus belongs in the 
application layer.

Transport is not as important as we have thought.  It is just the 
mechanism for creating per flow IPC.  The only identifier it needs is 
a connection-id and it has that.  Transport, LLC, HDLC are all 
instances of the same thing.

Take care,
john

---

From: Scott W Brim <[email-masked]>
Date: Sun, 19 Nov 2006 09:54:39 -0500

> node.  But the identifiers for the points of attachment and the node 

Small issue ... Point of attachment identifiers are distinct from node
identifiers as you say, but you should also allow for nodes to have
multiple identifiers.  I am known as Scott, swb, Honey, Daddy, punk,
etc.  In the Internet a node could be known by multiple
topology-independent names, each unique within its appropriate scope
-- all might be globally unique.

Honey

---

From: John Day <[email-masked]>
Date: Sun, 19 Nov 2006 10:04:45 -0500

Gee, Honey!  ;-)

>-- all might be globally unique.

Not to throw you too large a curve, and to agree with you.  I have 
through a separate analysis come to the conclusion that a layer (not 
consisting of quite what we thought) is a distributed application 
that provides IPC (Interprocess Communication).  The distributed 
application is composed of cooperating application processes on 
separate systems.  As applications they have application names. 
Addresses are identifiers *internal* to this distributed application 
and used only within it for its internal coordination in order to 
provide IPC.  Application names are external.  Addresses are internal.

Take care,
John

---

From: Peter Tomsu <[email-masked]>
Date: Sun, 19 Nov 2006 16:06:55 +0100

I do agree with that !

Peter

---

From: David Conrad <[email-masked]>
Date: Sun, 19 Nov 2006 11:17:51 -0800

[Sorry for the slow response, life got in the way]

Ran,

> associated with multiple link interfaces (e.g. 10/100/1000baseT,

I see a "stack" as a set of instantiations of protocol  
implementations on top of an interface where an interface has  
associated with it an identifier (or, in today's world, an address).   
Within a stack, there are a set of protocol handles that permit  
communication between the higher and lower level protocols.  Ideally,  
those handles are independent and opaque objects to all but the  
protocol in which they are defined (unfortunately, the ideal has  
frequently been violated, among the most egregious of which is  
applications knowing the format/length of addresses).

The reason for the parenthetical "more correctly" is pragmatically,  
an interface is pretty pointless without a stack on top of it.

> roughly the same thing as "stack".

I would've thought a node was something that had zero or more  
interfaces, that is, I see a node as a terminal point of 0 or more  
links.

> in hand without also happening to have a Locator for that node ?

I think it critical to decouple identifiers and locators, although  
I'm not that religious about "once a locator, always a locator".

An identifier can be configured in a variety of fashions, from  
statically assigned to DHCP to stateless auto-configuration.  You  
discover those identifiers in the traditional fashion, e.g., by  
translating a name (fqdn) via the DNS or via something like Apple's  
Bonjour.

In my model, the binding between an identifier and locator is done  
externally to the 'node'.

> and Identifier(s) from DNS records using forward resolution.

I'm still a bit unclear as to how this would work, but if I  
understand correctly, we're suggesting similar things, just a  
different approach to establishing the binding between the identifier  
and the locator.

(That is, delving into (a possible) implementation just to make sure  
I understand, your model has something like:

# name                  rrtype      rdata
node.fqdn.              IN ID       A000::0001 ...
                         IN LOCATOR  B000::0001 ...
                         ...

where I have:

node.fqdn               IN AAAA     A000::0001

1.0.0...0.0.A.ip6.arpa  IN LOCATOR  B000:0001 ...

(all of which can be DNSSEC signed)

If I'm close to what you are thinking, how would the identifier be  
associated with the locator as the packet traverses the stack?)

> I am talking architecturally, not about implementation.

My apologies: I tend to drop down to implementation to make sure I  
understand the theory.

> modifying any existing routing protocols or forwarding engines.

I must not understand.  I would be very interested in understanding  
how these would be the case.

> "Translation" covers a lot of possible meanings.  I'm not sure  
> which you mean.

Translation of identifier to locator and back to identifier.

Yes.

> one's DNS to remove the associated Locator(s).

Right.  One of the possibilities in my model is that if a transit  
router discovers there has been backhoe fade of the destination  
locator, that router has the option of popping off the topmost  
encapsulation, doing a lookup of the destination identifier at the  
next layer, getting back (potentially) alternate locators and  
forwarding the packet on.  Of course, this won't work if there is  
security protecting the top-most encapsulation layer, and it may be  
questionable that transit routers would have the cycles/interest to  
do this, but the capability is there.

Note that something like this capability would be necessary to  
emulate multi-homed PI space.

> node's choice in the first instance,

This gets a bit into implementation, but in my model, I assume the  
destination node has the ability to specify advisory preferences  
(e.g., a priority value in the rdata associated with each locator  
associated with an identifier).  The originating edge device SHOULD  
use that preference information for choosing the locator, but does  
not have to.

> old access network would necessarily have to forward packets.

In my model, it depends on how the mapping information between  
identifier and locator can be propagated fast enough.  I assume  
something like DNS TTLs, so when a transition between access networks  
occur, data in caches will need to expire.  During that expiration  
period, the old access network will need to forward to the new access  
network or the packets will get dropped on the floor.  Obviously, if  
you can pre-establish the new access network while traffic is still  
going to the old access network, you don't need the forwarding but I  
don't think that's something that can be guaranteed.

> to include only Identifiers, never Locators.

Which, of course, implies a change to all end point network stacks  
deployed to date.

> (hence immutable) ??   Is this where the tunnelling comes in ?

Yep.  The end-to-end connectivity is completely unmolested and the  
"identity-dependent layer" is completely ignorant of the "location- 
dependent layer".

> One can get the Locator from DNS in the same transaction, right ?

Not in my model, as the identifier and locator are completely  
decoupled.  The application doing the DNS lookup would not fetch  
anything related to the locator.  The edge device takes the  
identifier and does the lookup to establish the locator.

Right.

> Identifier, Source Locator, and Destination Locator in each packet.

This is, of course, what you get when you tunnel.

> So I'd rather not require an absolutely globally unique identifier.

In my model, since I assume something like ip6.arpa, lack of global  
uniqueness would be discovered quite quickly (given an attempt to  
update the appropriate identifer to locator mapping would not be  
possible unless you owned the signing key for that mapping).

> mess.  I really want to avoid overloaded semantics.

Ideally, yes.  Pragmatically speaking...

Rgds,
-drc

---

From: RJ Atkinson <[email-masked]>
Date: Sun, 19 Nov 2006 14:55:23 -0500

> associated with it an identifier (or, in today's world, an address).

In the IP Internet, I think of an interface as having at least
two different identifiers (little "i"), used for different purposes:
	- Link address (e.g. 802 MAC)
	- IP address (IPv4 or IPv6)

> communication between the higher and lower level protocols.   
> Ideally, those handles are independent and opaque objects to all  
> but the protocol in which they are defined (unfortunately, the  
> ideal has frequently been violated, among the most egregious of  
> which is applications knowing the format/length of addresses).

To the extent I'm understanding, I think I agree (definitely about
the inappropriateness of ordinary applications knowing about network
layer names).

> interfaces, that is, I see a node as a terminal point of 0 or more  

I view a node as having at least one interface.  A node with no
links and no interfaces is somewhat outside the concept boundary
of a network architecture, IMHO.

> I think it critical to decouple identifiers and locators,
> although I'm not that religious about "once a locator, always a  
> locator".

I am not keen on overloaded semantics.  This is my big issue with
MIPv6/SHIM6.  Each of those overloads the semantics of an IPv6
address, so that sometimes it is used a Locator and other times
it is used as an Identifier (big "I").

Based on the experience with overloaded semantics that we have to live
with, I'd prefer an architecture that eliminated or minimised such
overloaded semantics.

> statically assigned to DHCP to stateless auto-configuration.

I think that in order for an Identifier (big "I") to remain constant
across a location change, the Identifier ought not be assigned
dynamically (e.g. DHCP).  I have no issues with a Locator being
assigned dynamically (e.g. via Router Advertisement messages).

> You discover those identifiers in the traditional fashion,
> e.g., by translating a name (fqdn) via the DNS or via something
> like Apple's Bonjour.

That's fine with me.  (Aside: BonJour (TM) appears to mostly
be IETF ZeroConf.)

> externally to the 'node'.

I don't understand what you mean by the above.

> different approach to establishing the binding between the  
> identifier and the locator.
>
> (That is, delving into (a possible) implementation just to make  
> sure I understand, your model has something like:
>
> # name                  rrtype      rdata

That's reasonably close, though I'm open about the engineering.

> associated with the locator as the packet traverses the stack?)

The network-layer would be aware of both Identifier and Locator.
Only the Locator would be used for forwarding/routing packets.
The transport-layer would only be aware of the Identifier --
no location information (neither address nor Locator) would be
in any transport-layer state.

I probably would include both Identifier and Locator in each packet.

> how these would be the case.

If one takes IPv4, purely as an example, and ignores implementation
consequences, then one could redefine the IPv4 address to be a Locator
and carry an Identifier (some or all of the time) in something like
an IP option.  Note that I am *not* advocating this particular  
engineering
approach -- I'm focused on architecture, not engineering -- but you
asked for an example.

(Existing routers can forward such packets, perhaps slow-path but
none the less without change, and existing routing protocols don't
need any modifications.)

A nice feature of not modifying the routers/forwarding process is
that one probably could have incremental deployment.  In a trivial
example, and I don't suggest this is the right engineering approach,
packets with the new IP option would use a different pseudo-header
calculation than packets without that new IP option.

I emphasise that I'm giving trivial examples to explain the concepts.
If/when there were agreement on the right architecture, then one could
get down to doing engineering.  At that point, depending on whether
one wanted to be backwards compatible with something, or not, there
would be a range of engineering options that could be contemplated.

> Translation of identifier to locator and back to identifier.

I think it matters which object is doing the translation,
under which circumstances, and for what purpose.

Nodes sharing a session might do some translation back and forth
internally.  External nodes initiating a session would use DNS
to make forward lookups to find Identifier and Locator from
a FQDN (or via ZeroConf or some other TBD mechanism).

> do this, but the capability is there.

Because Locators are not covered by AH/ESP in my model, and are
not included in any state above the network layer, Locators would
be mutable, at least conceptually.  I'm neither requiring nor  
prohibiting
routers from modifying Locators, just ensuring that the session
won't necessarily break due to Locator modification during transit
(e.g. because of a NAT/NAPT/other middlebox).

Support for PI unicast addressing is not a goal in my concept,
nor is it particularly valuable to have, unlike today, because
of the native support for mobility and multi-homing.

> something like DNS TTLs, so when a transition between access  
> networks occur, data in caches will need to expire.  During that  
> expiration period, the old access network will need to forward to  
> the new access network or the packets will get dropped on the  
> floor.  Obviously, if you can pre-establish the new access network  
> while traffic is still going to the old access network, you don't  
> need the forwarding but I don't think that's something that can be  
> guaranteed.

Shorter TTLS for the Locator records, to a TTL value appropriate
for the frequency of layer-3 location changes, probably would
obviate the need for such special-case forwarding.

Also, small amounts of packet loss happen today, regardless of
mobility handoff.  This is a datagram network, there aren't
guarantees about packets being delivered, though we don't want
to gratuitously drop packets that reasonably can be avoided.

> Which, of course, implies a change to all end point network stacks  

Yes, but only to stacks that want to use the new architecture.
I think a dual-stack (triple-stack ??) approach is possible
so that migration can occur slowly and incrementally (i.e.
without necessarily requiring application changes).

> identifier and does the lookup to establish the locator.

That seems to be a difference.  Conceptually, how would the edge device
do that sort of lookup ?  Some sort of other directory service ?

> This is, of course, what you get when you tunnel.

Albeit with overloaded semantics -- outer IP address as Locator,
inner IP address as Identifier.  I'm not a fan of overloaded
semantics.  I'd also like to avoid mandatory tunnelling.  So there
are some other conceptual differences.

> possible unless you owned the signing key for that mapping).

OK, so this implies a pretty strong dependence on DNS and DNSsec
deployment and maybe also a strong dependence on being able to
somehow sign delegations from RIRs.

Cheers,

Ran
[email-masked]

---

From: David Conrad <[email-masked]>
Date: Sun, 19 Nov 2006 12:10:02 -0800

John,

On Nov 17, 2006, at 7:07 PM, John Day wrote:

> In reading the conversation between the three of you, I get the  
> sense that you are still trying to solve the current engineering  
> problem. This is one of the better abstract discussions I have seen  
> on this list, but I don't think you have really boiled it down to  
> its barest elements.  There is still too much flesh on the bones.

I suspect this is my fault since, as I said in a different note, I  
tend to drop down to implementation scenarios to insure I understand  
what is being discussed and that it makes sense.  A fatal character  
flaw, I know...

Rgds,
-drc

---

From: David Conrad <[email-masked]>
Date: Sun, 19 Nov 2006 12:39:12 -0800

John,

On Nov 17, 2006, at 8:14 PM, John Day wrote:
> You need a logical and physical address spaces under the  
> application name space.

Agreed.  By analogy, I am suggesting the identifier space is the  
virtual address that is mapped into the locator space which is the  
physical address space.

One might argue that the logical address space should be the fqdn,  
and in an ideal world, I might agree.  However, pragmatically  
speaking, that won't fly as long as there are applications and  
protocol stacks that _know_ an "address" is 32 or 128 bits and that  
certain bit patterns have special meanings.

> The point of attachment id does not have to be global.

No, but the mapping between the id and the locator must be globally  
unique.  It is possible to come up with a variety of mechanisms to  
ensure that global uniqueness, but since the amount of name space  
isn't an issue, it just seems simpler to require both id and locator  
be globally unique and avoid the question completely.

> So quit trying to build solutions that make it work.  They will  
> always be kludges.

Well, yes.  However, it is hard to boil the ocean.

Rgds,
-drc

---

From: Pekka Nikander <[email-masked]>
Date: Mon, 20 Nov 2006 11:16:16 +0200

A couple of details:

On Nov 19, 2006, at 22:39, David Conrad wrote:
> and in an ideal world, I might agree.

There are lots of problems with FQDNs.  Consequently, there is a lot  
of pressure to gradually get rid of the FQDNs in the application  
space, and to replace them with something better.  Unfortunately, my  
knowledge of the efforts in the application space are very limited,  
but my understanding is that some of the the CRISP/IRIS effort aims  
to experiment in an alternative space.

This is related to my other note, where I mentioned that due to  
conflicting needs we are unlikely to be able to use just one  
application-level name space.  In particular, security, privacy, and  
usability requirements seem to form here such conflicting goals that  
it seems likely that we'll need at least two types name of names  
spaces:  user friendly ones (which may be non-global), and a secure  
one.  The latter is unlikely to be user-unfriendly due to they  
probably being cryptographic.

> unique.

Strictly speaking, maybe no.  It may be feasible to live with a  
limited amount of unintended multicasting.  That is, there may be  
benefits from allowing a very limited amount of "unicast" packets to  
be sent to a few hosts instead of to a single one.

For example, it may turn out such limited amounts of limited  
multicasting may result if we decide to use statistically unique  
identifiers.  That is, if the identifiers in question are only  
statistically unique, then in some rare cases the same identifier may  
be used, simultaneously, at two or more different locations in the  
network.  Consequently, most probably the network should be  
engineered so that it will deliver data to all of the locations.  The  
stacks/nodes at the locations can then filter out those packets that  
are not really intended to them, based on upper-layer information.

The question is basically an economic one: the flexibility benefits  
from allowing rare conflicts may be larger than the performance  
penalty.  For example, the cost of ensuring 100% global uniqueness  
may turn out to be so high that we just don't want to pay it.

[A side issue here is that statistical uniqueness opens up a  
possibility for "interesting" traffic amplification, eavesdropping,  
etc attacks.  However, I don't see any real obstacles there; at least  
the most obvious vulnerabilities seem to be mitigable.]

--Pekka Nikander

---

From: <[email-masked]>
Date: Mon, 20 Nov 2006 16:07:58 +0200

RJ Atkinson [mailto:[email-masked]] wrote:
>I am not keen on overloaded semantics.  This is my big issue 
>with MIPv6/SHIM6.  Each of those overloads the semantics of an 
>IPv6 address, so that sometimes it is used a Locator and other 
>times it is used as an Identifier (big "I").
>

Thus it would be beneficial to allocate part of the reserved IPv6
address space (with some of the first couple of bits) for the ID usage.
This way they would be unambiguous. Have sufficient number of bits in an
"ID prefix" to enable scalable reverse lookup (might be useful), and
most (e.g. at least 100) bits for the "random" ID part (more bits for
higher security).

	Jarno

---

From: Pekka Nikander <[email-masked]>
Date: Mon, 20 Nov 2006 16:29:59 +0200

> most (e.g. at least 100) bits for the "random" ID part (more bits for

Do you mean

http://www.ietf.org/internet-drafts/draft-laganier-ipv6-khi-05.txt
https://datatracker.ietf.org/public/idindex.cgi? 
command=id_detail&id=13628

Currently in an extended IETF Last Call for 4 weeks, on its last week.

Some apps folks have voiced their concerns, but most people seem to  
be supportive for such an experiment.

Or do you have something else in your mind?

--Pekka Nikander

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 20 Nov 2006 10:09:41 -0500

In watching the discussion of things to be named and how they are 
named, I think there are a number of unstated assumptions people are 
making.  I think some are agreed.  Some are subtle enough that I am 
only going to allude to them.  But some I think can be usefully 
surfaced and discussed on their merits.

For this purpose, I will take certain things as given.
1) There ought to be identifiers for certain objects in the system 
which are independent of the location of those objects.  Application 
instances need to have such identifiers.
2) There are (and ought to be) identifiers which are location 
dependent.  subnets (and interfaces to subnets) ought to be 
identified based on their placement in the network graph.
3) It is expected that in most of the net, packet forwarding will be 
based on location dependent identifiers (locators.)

Note, point 3 does not deal with whether that is a single identifier, 
a cascade or nested set of identifiers, different locators for local 
and global use, or any of the many other variations in forwarding 
paradigms.  It is just saying that forwarding is working in terms of 
location sensitive identifiers.  I have seen some research work where 
that is not the case.]
I will use "locator" for an identifier which is location dependent. 
(Lots of folks use that, but I don't think we have yet settled on it.)

If we take that as given, and we assume that applications normally 
operate in terms of location, then there are a couple of interesting 
tasks for the collective system, and a couple of operations relating 
to those tasks.

The tasks are:
a) coping with multi-pathing
b) coping with multi-homing
c) coping with mobility

Folks have sometimes treated various of these as interchangeably 
solved by the id / locator split.  While that separation of notions 
helps us, it does not "solve" these issues.  It does not even 
necessitate that these issues be solved in the same place.

Functionally, one can talk about the functions of
i) determining the locator(s) that go with a location independent identifier
ii) selecting a locator to use for communication
iii) route determination forwarding packets based on that selected locator

(ii) is sometimes treated as a non-issue, if one assumes that there 
is only one such locator.  (ii) is also sometimes assumed to go in 
specific places.

Looking at the tasks above, multi-path is the problem (opportunity) 
of dealing with the fact that there are multiple paths to a location 
across the network.  We assume (correctly I believe) that coping with 
this is the job of the routing / packet forwarding functions.

On the other end, mobility seems to imply the changing of the 
locator(s) associated with a location independent identifier.  Hence, 
it seems to me that wherever it lives it is not part of the routing / 
packet forwarding system.  Yes, this re-mapping is helped by the 
separation of identifiers.  Yes, there can be functions required of 
packet handling systems that can help this.  But routing isn't going 
to tell you about it, and packet forwarding based on locators isn't 
going to cope with it.

The middle task raises, coping with multi-homing, some interesting 
questions.  And I think we have been mixing the answers.  If one 
assumes that one can have a singular, meaningful, location dependent 
identifier for a (multi-connected) node then one might well expect to 
use that identifier in packets, and expect the routing / packet 
forwarding system to cope with it.
If on the other hand, the location dependent identifiers are 
associated with subnets / interfaces, then it is hard to see how 
locator based forwarding can cope with this.  Rather, it would seem 
to be the locator selection function which has to cope with it.

The question I am wondering about is, assuming for the moment that it 
can be made to work either way, does coping with multi-homing 
conceptually belong with one or the other of multi-pathing and 
mobility?  (We may have to put it somewhere it does not belong for 
pragmatic reasons, but it seems useful to know if that is what we are doing.)

Yours,
Joel M. Halpern

PS: I am deliberately being vague about where the locator selection 
function is being done, and whether it is colocated with the locator 
determination.  Whether it looks like shim6, GSE, or something, and 
whether it is done in the host or in an edge does not, I think, 
affect the question here.

---

From: <[email-masked]>
Date: Mon, 20 Nov 2006 17:38:54 +0200

Pekka Nikander wrote:
>Rajahalme Jarno wrote:
>>> MIPv6/SHIM6.  Each of those overloads the semantics of an
>>> IPv6 address, so that sometimes it is used a Locator and 
>other times 
>> This way they would be unambiguous. Have sufficient number 
>of bits in 
>> an "ID prefix" to enable scalable reverse lookup (might be useful), 
>> and most (e.g. at least 100) bits for the "random" ID part 
>(more bits 
>> for higher security).
>
>Do you mean
>
>https://datatracker.ietf.org/public/idindex.cgi?command=id_deta
>il&id=13628
>
>Some apps folks have voiced their concerns, but most people 
>seem to be supportive for such an experiment.
>

Almost, but not exactly. I think ORCHID is asking for too little, and is
in no way facilitating effective lookups, or localizing identities
(which I expect to be a requirement in some jurisdictions). IMO, ORCHID
is also plainly wrong:

- 1st of all, the ORCHID proposal is contradicting itself. It calls for
conformity with RFC 3513 section 2.5.4, but breaks this:

"All global unicast addresses other than those that start with binary
   000 have a 64-bit interface ID field (i.e., n + m = 64), "

- Therefore it is wrong to ask for allocation under IANA Special Purpose
Address Block (which starts with binary 001).

- Ask for something like 0400::/6 (binary 0000 01), claiming 1/8 of the
address space starting with binary 000

 - Maybe should be asked for limited time experimentation (e.g. 5
years), and all systems could be mandated to cease using these addresses
after the dead line. Unless the status is changed before expiration?

- If bit 7 is clear, the whole ID MUST be registered (see below)

- Use bits 8-28 for regional/national (RIRs/NIRs) level aggregation for
efficient, localized lookups. David has expressed examples of IN RR in
.id.arpa on this list before).

 - maybe each DNS top-level domain should get piece in this ID address
space? Maybe 9 bits are needed for these (8-16), bits 17-28 could then
be further allocated beneath each top-level domain for lookup service
providers. Part of the 9-bit space could be carved out for
experimentation and collaborative, independent global lookup provision??

- bits 29-128 would be self assigned identity, as in ORCHID (exept the
hash will need to change, see below)

- If bit 7 is set, the ID MUST not be registered on the registry, but
the regianal structure SHOULD still be used (if possible)

 - or altenatively mandate 0600::/7 to use 121-bit identifier hashes

The hash function will need to be changed to include the prefix as
input. But note that this in NOT network topology dependent prefix. If
we are lucky this  difference will be enough to get past some of the
existing IPR on CGAs (can you verify this?).

If I recall right, one of the expressed concerns against ORCHID has been
semantical overloading. By using address space starting with binary 000
this overloading is avoided.

If what I propose above is too much, please feel free to utilized what
you find useful (if any).

Regards,

	Jarno Rajahalme

---

From: Ted Hardie <[email-masked]>
Date: Mon, 20 Nov 2006 16:06:59 -0800

At 11:16 AM +0200 11/20/06, Pekka Nikander wrote:
>There are lots of problems with FQDNs.  Consequently, there is a lot of pressure to gradually get rid of the FQDNs in the application space, and to replace them with something better.  Unfortunately, my knowledge of the efforts in the application space are very limited, but my understanding is that some of the the CRISP/IRIS effort aims to experiment in an alternative space.

I am fairly familiar with CRISP (the WG) and IRIS (the protocol), but I do not
understand what you mean by this.  Nothing in either attempts to get rid
of FQDNs in application space, as far as I know. 
			regards,
				Ted Hardie

---

From: Jefsey_Morfin <[email-masked]>
Date: Tue, 21 Nov 2006 02:56:52 +0100

Dear Joel,
This looks a good approach. Thx. It might be interesting that you 
detail multi-pathing and multi-homing operations the same. Also 
consider what you think can be end-driven (both ends). Then to 
consider the information needed for each operation, and where can it 
be located.
jfc

At 16:09 20/11/2006, Joel M. Halpern wrote:

>Note, point 3 does not deal with whether that is a single 
>identifier, a cascade or nested set of identifiers, different 
>locators for local and global use, or any of the many other 
>variations in forwarding paradigms.  It is just saying that 
>forwarding is working in terms of location sensitive identifiers.  I 
>have seen some research work where that is not the case.]
>across the network.  We assume (correctly I believe) that coping 
>with this is the job of the routing / packet forwarding functions.
>
>locator(s) associated with a location independent 
>identifier.  Hence, it seems to me that wherever it lives it is not 
>part of the routing / packet forwarding system.  Yes, this 
>re-mapping is helped by the separation of identifiers.  Yes, there 
>can be functions required of packet handling systems that can help 
>this.  But routing isn't going to tell you about it, and packet 
>forwarding based on locators isn't going to cope with it.
>
>identifier for a (multi-connected) node then one might well expect 
>to use that identifier in packets, and expect the routing / packet 
>The question I am wondering about is, assuming for the moment that 
>it can be made to work either way, does coping with multi-homing

---

From: David Conrad <[email-masked]>
Date: Mon, 20 Nov 2006 22:21:20 -0800

Ran,

> I don't understand what you mean by the above.

This is mostly an implementation detail.  Architecturally, what I  
meant was that the mapping between locator and identifier is not  
dependent on either.  That is, the binding is a simple mapping  
function that takes as input the identifier and spits back a set of  
zero or more locators.  How/where that mapping is done does not  
depend on the locator or identifier (other than the identifier is the  
input that results in zero or more locators as output).

> be mutable, at least conceptually.

When I raised this approach before, people complained about MITM and  
spoofing attacks.

> obviate the need for such special-case forwarding.

You get into a tradeoff here, between load on the DNS servers and the  
ability for mapping changes to be implemented.  I believe that for  
scalability reasons, you want to keep a reasonable level of caching.

> Yes, but only to stacks that want to use the new architecture.

Right.  As I've become a bit cynical about what is possible to change  
on the Internet, I've consciously been assuming that the only way to  
get stuff deployed is to minimize what has to be changed, thus the  
"change only the edge" approach.  Changing host stacks is a fairly  
significant change in my mind.

> do that sort of lookup ?  Some sort of other directory service ?

DNS or something like it would work for a "pull" model.  A push model  
(e.g., flooding a map via BGP or something similar) might also work.

> somehow sign delegations from RIRs.

Not necessarily.  The mechanism used for propagating the mapping can  
be either pull (e.g., something that looks and smells like the DNS 
+DNSSEC, but does not have to be) or push.  I just use the DNS in  
examples because it is easier to explain.  As for signing  
delegations, I feel that would be useful for other reasons, but isn't  
required by my model.

Rgds,
-drc

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 21 Nov 2006 10:40:03 +0100

Let me get absurd for a moment:

David Conrad wrote:
>> You need a logical and physical address spaces under the  application 
>> name space.
> 
> 

OK, we have layers, and the layers each have namespaces, which may or
may not be externally significant. But trying to say that one namespace
is virtual and another is physical strikes me as bogus; they are all
virtual. (MAC addresses aren't really physical - maybe you can consider
that the numbers on wall sockets are physical addresses, but even they
can be changed.)

So I think we should consider all namespaces to be virtual or logical,
and not try to find a specific "physical" namespace.

This makes it a lot easier to think about VPNs for example - they
merge and map parts of a namespace, but they are not 2nd class namespaces.

> One might argue that the logical address space should be the fqdn,  and 
> in an ideal world, I might agree.  However, pragmatically  speaking, 
> that won't fly as long as there are applications and  protocol stacks 
> that _know_ an "address" is 32 or 128 bits and that  certain bit 
> patterns have special meanings.
> 

Define "global." In other words, what is the scope of the namespace
within which you require uniqueness?

     Brian

It is possible to come up with a variety of mechanisms to
> ensure that global uniqueness, but since the amount of name space  isn't 
> an issue, it just seems simpler to require both id and locator  be 
> globally unique and avoid the question completely.
>

---

From: Jari Arkko <[email-masked]>
Date: Tue, 21 Nov 2006 11:44:17 +0200

Jarno,
> you find useful (if any).
The issue of which part of the address space to use has certainly
been discussed already. I have to look into your comment about
RFC 3513 rule. Thanks for pointing this out.

However, there are some important issues that you should be
aware of:

First of all, ORCHIDs are not intended as the final solution
for the routing and addressing problem. They indeed fall
short in the question of identifier lookups. But that's by design.
What this allows is that people can run HIP (or other) experiments
without changing the APIs that the applications see. Indeed,
new routing mechanisms such as those operating on "overlays"
should be part of the experimentation, but they are not part
of the allocation, and I don't think we are ready to specify
all the details yet. On the other hand I think it is very
valuable for an experiments like this to proceed. If there
is one new feature that needs to be tried first
before its adopted for the Internet, its the identity-locator
split. Your ideas above sound interesting, please document
them and consider running an experiment of your own
to convince the rest of us that it works great. ORCHIDs
might even be used for your experiment, just that you
have a different use of the remaining bits than
the HIP experiment has.

Similarly, since this is an experiment I don't think we should
burn any significant part of the address space for this. If
it turns out that people run a lot of experiments in this space
and the results are successful, we can revisit this.

The big question mark related to ORCHIDs is the overloading.
We could, of course, use a different prefix. But this does not
necessarily solve the issues associated with the overloading.
For instance, since applications do not understand one part
of the address space to have a different semantics than another
one, they would still be equally easy to leak through referrals
to legacy nodes, etc. One important result from experiments
in this space is determining how widespread that problem
is.

--Jari

(P.S. Sorry if you get this twice. I sent one mail
accidentally using an address that I am not subscribed
to arch-d with.)

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 21 Nov 2006 10:53:57 +0100

...
> When I raised this approach before, people complained about MITM and  

Hence the cryptographic protection of locator sets in shim6. This
problem is valid, but soluble as long as you have some state to
keep track of the locator set. If you attempt to do it stateless,
you are exposed.

     Brian

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 21 Nov 2006 08:24:48 -0500

On  21 Nov 2006, at 01:21, David Conrad wrote:
> When I raised this approach before, people complained about MITM  
> and spoofing attacks.

Maybe some people are confused then.  MITM and spoofing attacks
are possible today in the IP Internet -- unless one uses ESP/AH.
Period.  And there are ample CERT advisories (and equivalent advisories
from organisations outside the US) that show such active attacks
are practical.

There exist non-cryptographic mechanisms that could virtually preclude
off-path active attacks.

To my mind, the security goal would be that the new approach
does not significantly increase the risks versus the current
approach, while retaining the ability to operate in a secured
mode (as today with AH/ESP) if one wants to use cryptography.

> You get into a tradeoff here, between load on the DNS servers and  
> the ability for mapping changes to be implemented.  I believe that  
> for scalability reasons, you want to keep a reasonable level of  
> caching.

It is a fair question.  My intuition is that the critical things
to cache are the NS records, not the Locator records.  This is best
addressed by running some experiments in some friendly DNS Zones,
so that one can talk about measurements rather than intuition.

Yours,

Ran
[email-masked]

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 21 Nov 2006 08:28:35 -0500

> keep track of the locator set. If you attempt to do it stateless,

The proposed approach is no more exposed than ordinary IPv6
(without AH/ESP) is.  I did not ever say "stateless".  I simply
said that nothing precluded a Locator from being rewritten
-- and then in the next breath noted that nothing required a
Locator to be rewritten either.  The simple reality is that
NAT/NAPT boxes exist and will continue to exist and they will
continue to rewrite fields used for packet forwarding as
those packets traverse the middle box.

Perhaps people want to outline specific attacks that they
believe would apply only to this new concept (or to SHIM6),
but would not apply to ordinary IPv6 (without AH/ESP) ??

Yours,

Ran

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 21 Nov 2006 14:58:33 +0100

> but would not apply to ordinary IPv6 (without AH/ESP) ??

In a word, session hijacking by injecting a fraudulent
locator rewrite. It's distinct from simple source address
spoofing because you can persuade Alice that Bob's address
has changed.

In many words, RFC 4218.

    Brian

---

From: Jefsey_Morfin <[email-masked]>
Date: Tue, 21 Nov 2006 15:04:45 +0100

Dear Brian,
you start being in tune with me about externets, continuity and 
relational spaces ... and ISO 3166, 639, etc. (see below)

However do not go too far.  The addresses of hardware belonging to a 
namespace are definitely virtual, but they indirectly relate to 
hardware, logical power, and people/people's agents and their 
characteristics, properties, and purposes must be kept in mind. This 
is why you do not consider the network chart but its current 
topology. And that externally what counts is not the way the network 
works, but the way the users collectively believe (brainware) it works.

One of the layer violations in the WG-LTRU is that they confuse 
languages IDs and language names IDs. What you document here is that 
it is a basic mistake. The addresses do not relate to a machine, but 
to the number someone gave to that machine. This means that a machine 
may be "missing" but interfering, and a machine can have several 
numbers and addresses.

This is why you can consider externets (external look-alike networks 
within the network system) as virtual hardware spaces. This is why 
you can consider the convergence of all the hardware systems as a 
single multitechnology/multinetwork continuity. This is also why you 
can consider all the users' relational spaces (real life human 
organised spaces of exchanges) as a manageable large multilateral 
system, however it is so big that as a mono-system it would be a very 
very large system subject to all the RFC 3439 complexity problems.

This is why you MUST consider orthogonal address systems in each of 
these namespaces. This makes a three (even more if to support several 
addressing schemes) degree of liberty vector the scalars of each of 
its dimensions can be conveniently concatenated into an IPv6 address 
as I indicated.

This way each scheme/routing/identification/serialisation information 
can be sequentially used (and encrypted) independently for analysis 
(what scheme), routing (net to net - can be simplified in being 
topology oriented), lodging (which system on the network - or new 
address to use in case of a mobile), access (which virtual location 
on the target system). With a routing table or computation function 
at the internetwork transit, at the network routing, at the user 
system access levels.

If you use a routing computation function it can be located at the 
network DNS, locating the destination address (net and system) and 
providing the routing from the origin to the destination network 
(with all the necessary information/constraints for multi-....). At 
the destination network the local "DNSS" will route it to the system 
on the network or bounce it towards its real current address. Each 
time the user address segment can be encrypted. An externet will be 
an "physically empty" network made of its own net address, the group 
of destination systems, the class of accepted users, and their 
updated "DNSS" knowledge.

jfc

At 10:40 21/11/2006, Brian E Carpenter wrote:

>>On Nov 17, 2006, at:14 PM, John Day wrote:
>>
>>>You need a logical and physical address spaces under 
>>>the  application name space.
>>
>>One might argue that the logical address space should be the 
>>fqdn,  and in an ideal world, I might agree.  However, 
>>pragmatically  speaking, that won't fly as long as there are 
>>applications and  protocol stacks that _know_ an "address" is 32 or 
>>128 bits and that  certain bit patterns have special meanings.
>>
>>ensure that global uniqueness, but since the amount of name 
>>space  isn't an issue, it just seems simpler to require both id and 
>>locator  be globally unique and avoid the question completely.
>>

---

From: David Conrad <[email-masked]>
Date: Tue, 21 Nov 2006 13:05:37 -0800

Brian,

On Nov 21, 2006, at 1:40 AM, Brian E Carpenter wrote:
>> No, but the mapping between the id and the locator must be  
>> globally  unique.

Good question.

I have implicitly assumed there is a "global" scope that encompasses  
all potential entities prepared to communicate end-to-end.

Rgds,
-drc

---

From: John Day <[email-masked]>
Date: Tue, 21 Nov 2006 16:25:20 -0500

At 13:05 -0800 2006/11/21, David Conrad wrote:
>>>No, but the mapping between the id and the locator must be globally  unique.

We could say that "global" is defined by the fact that there is no 
scope greater.  ;-)  That is only half in jest.  That *is* what it 
is, but you always have to allow for a larger one appearing.

One of the things I have noticed with assignment of IP addresses is 
that we didn't start distinguishing between internet and Internet 
soon enough.  In other words, that IP addresses were only being 
assigned for use on the public Internet.  Those internets not 
connected to the public Internet did not need addresses from that 
space.  Later of course we sort of recognized that with private 
addresses, but by that time we had allocated large blocks to 
internets.  So in some sense, "global" might be the public Internet. 
However, if we had an "application name space" with a scope that 
encompassed the public Internet and internets as well.   We could do 
relaying in the application layer across NATs, i.e. forwarding on 
application names.

Now given that application names were suppose to be 
location-independent, that would seem to scale very well. Although it 
didn't bother us for along time that IP addresses were 
location-independent.

So, I would global is the biggest scope you feel like worrying about! ;-)

Take care,
John

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 21 Nov 2006 17:02:43 -0500

> spoofing because you can persuade Alice that Bob's address

Thanks very much for being specific. :-)

I'd prefer to avoid delving into mechanism, so I'm going to
remain somewhat abstract here for the moment.  I have been
thinking about the security issues that could lurk in any change.

OK.  Lets go through the case analysis for the Section on
"Potential New Attacks" (Section 4 of RFC-4218):

4.1:	RFC text says this is an existing threat to existing
	IP if the attacker is on-path.  It also says the main
	concern is with off-path attackers.

	I've mentioned that non-cryptographic means exist
	to mitigate would-be off path attacks.

	(Of course, and I won't repeat it each time below, one
	can always use AH to authenticate any control message
	if one wants strong cryptography.)

	So this isn't an issue for what I've been discussing.

4.1.1:	The RFC text says that solving this requires the existence
	of some practical to authenticate "I have moved" messages,
	rather than blindly trusting non-authenticated messages.
	That seems reasonable to me.   Such mechanisms exist.	
	
	So this isn't an issue either.

4.1.2:	This says that if an on-path attacker moves off path,
	there ought to be a time-limit to the attackers continued
	ability to engage in an on-path-like attack on a session.

	The non-cryptographic methods can handle this case, too.

4.1.3:	If B behaves properly, B will use DNS (with DNS Security)
	to authenticate any Identifier and Locator information
	associated with A.  So attacker X won't be able to just
	tell B "I'm A and this is my location" and have any success.

	So this isn't an issue either.

4.1.4:	This says control protocols ought not be vulnerable to
	replay attacks where the replay attempt is some non-trivial
	time after the initial packets.

	The non-cryptographic authentication can handle this.  AH
	can also handle this.

4.2:	A variant on one of the above, differing only in that instead
	of re-routing a packet to an attack node, the packet gets
	re-routed to a black-hole.

	Solution is the same as for the initial version above.

4.3:	This has to do with attacker X causing intended victim A
	to send packets really intended for B towards C instead.

	The same DNS mechanisms used for 4.1.3 above eliminate
	this risk.

	(ASIDE: While the ability to engage in this attack at the
	network layer is more limited than at the application layer,
	this kind of (D)DOS attack is actually pretty commonly seen
	using application layer protocols today.)

4.3.1:	The DNS solution works.  An even simpler solution is described
	in the RFC.

4.3.2:	This is a variant with on-path help.  On-path help doesn't
	matter if one uses the DNS mechanisms in 4.1.3.

	Also, note that without DNS Security, this attack works fine
	today where the on-path attacker Y modifies the DNS responses
	heading for A to replace correct information with incorrect
	information.  So it isn't a new risk if one chooses not to use
	DNS security.

	Other solutions are also outlined in the RFC.

4.4:	Ingress filtering, while highly desirable, is not commonly
	deployed within ISPs.  It is somewhat more commonplace at
	the edge, but it is not nearly as common as one would like
	it to be.  So, in practice, source address forgery is not
	uncommon today in (D)DOS attacks that have been seen in the
	wild and reported upon by people like CERT.  The RFC text
	acknowledges this in the 2nd paragraph of 4.4.

	In the same places where it is practical to deploy ingress
	address filtering today, it would be practical to deploy
	Locator filtering in the new concept.  So there is no real
	change here.

	Other mitigation techniques are also described within 4.4.

4.5:	The RFC suggests having multiple Identifiers concurrently
	would be a solution to the issues in this section.  I have
	already said that in my concept a node could have more than
	one Identifier concurrently.

5:	This does not discuss a specific vulnerability, instead its
	a general discussion of architectural issues.

6:	Same as 5.

I hope I didn't miss some case in the above analysis.  If I did
overlook one, I'm sure someone will point it out.

Yours,

Ran
[email-masked]

---

From: Ted Hardie <[email-masked]>
Date: Tue, 21 Nov 2006 18:22:16 -0800

At 4:25 PM -0500 11/21/06, John Day wrote:
>One of the things I have noticed with assignment of IP addresses is that we didn't start distinguishing between internet and Internet soon enough.  In other words, that IP addresses were only being assigned for use on the public Internet.  Those internets not connected to the public Internet did not need addresses from that space.

As point of history, this was, at least at one point, a policy choice that was
made quite openly.  It was not an accident.  During the period when I
was at the SRI-NIC, the policy was to actively encourage folks who were
using IP to get allocations.  This was designed to make things easier if
they were later to connect their networks to the Internet (in other words,
to save them renumbering).  It went along with an active effort to reclaim
IP space that was not being used at all, so it was not completely wasteful.

You would have to talk to someone much further up the food chain than
I was to get the real details of why that policy was in place, but my naive
view at the time (retained to now) was that it was part of an effort to
encourage experimentation with IP and to extoll IP's "network effect"
of connected sites. 
			regards,
				Ted

---

From: John Day <[email-masked]>
Date: Tue, 21 Nov 2006 21:39:13 -0500

Yes, that is all is well known.  The point is that at some point the 
emphasis shifted and the 'Net took quite awhile (if they really have) 
to shift from a loose collection of cooperating researchers to 
"administering a production network."  In some sense, it has been an 
experimental network since IP was deployed and probably long before 
that.

If I had to guess there was probably some resistance (internally, 
i.e. we didn't want to admit) to the idea that we were no longer 
doing research and were minding a large network. ;-)

At 18:22 -0800 2006/11/21, Ted Hardie wrote:
>>space.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 22 Nov 2006 10:35:34 +0100

Ran,

> "Potential New Attacks" (Section 4 of RFC-4218):

<snip>

And I believed you when you used to deny having security expertise :-)

Yes. At a quick glance, I think you're correct and all these
threats can be countered; indeed the shim6 security mechanism is
designed to do so (and there are no doubt other ways of doing so).
So these threats don't prevent us from using relocator rewriting.

    Brian

---

From: "Bound, Jim" <[email-masked]>
Date: Wed, 22 Nov 2006 09:15:22 -0500

I think global is required David and I like your initial proposal too,
and Ran's too the diff is important to analyze between the two.

Some points from the many mails and use cases are important for this
work.

If I am first responder and I move to different location IP topology (I
agree with Noel on this word but the only one I can think of right now)
my locator has to change because of this movement, but the identifier
should remain the same.  If I am NATO spec op force entity and I have to
move to different geography my locator changes there too.  I believe the
identifiers have to be globally unique but realize that is going to be
hard to do regarding what value can be used?

NB: all - I thought we were supposed to move to RAM list for this
discussion?  

/jim 

> -----Original Message-----
> From: David Conrad [mailto:[email-masked]] 
> Sent: Tuesday, November 21, 2006 4:06 PM
> To: Brian E Carpenter
> Cc: [email-masked]
> Subject: Re: [arch-d] thoughts
> 
> Brian,
> 
> globally  
> I have implicitly assumed there is a "global" scope that 
> encompasses all potential entities prepared to communicate end-to-end.
> 
> Rgds,
> -drc
> 
> 
> 
>

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 23 Nov 2006 08:46:51 +0200

Ted,

At 11:16 AM +0200 11/20/06, Pekka Nikander wrote:
>> There are lots of problems with FQDNs.  Consequently, there is a  
>> lot of pressure to gradually get rid of the FQDNs in the  
>> application space, and to replace them with something better.   
>> Unfortunately, my knowledge of the efforts in the application  
>> space are very limited, but my understanding is that some of the  
>> the CRISP/IRIS effort aims to experiment in an alternative space.

> of FQDNs in application space, as far as I know.

I must have misunderstood what Leslie said while I was at the IAB.

IIRC, when we discussed some of the problems with the DNS, Leslie  
told us that some folks are trying to address some of the issues  
through IRIS and SLS.  IIRC, she also told that it is painful and  
slow progress.

Another piece of technology which was mentioned was the Handle  
system.  SPKI/SDSI was also briefly mentioned, but some vocal IAB  
members readily offered their opinion that SPKI is dead and buried.

That's basically all that I know.  But my memory is probably failing  
here; it's over a year ago when that discussion took place.  And, of  
course, to clarify, all this was unofficial discussions and have  
nothing to do with what the IAB is or does, even though there  
happened to be IAB members that were discussing.

Sorry for the confusion.  On the other hand, if someone could point  
out to any serious work in that space, I'd be very glad to spend some  
cycles in trying to understand.

--Pekka Nikander

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 23 Nov 2006 13:04:33 +0200

There's been some discussion on how to define "global" and "virtual"  
when speaking about identifiers, names, and name spaces.  I must be  
missing something because I think we could have pretty simple  
definitions for both "global" and "virtual", both given below.

However, we first have to understand a crucial point:

   An identifier is meaningless without a defining context.

That is, an identifier is merely an non-interpretable string of bits  
unless we know the context in which we should understand it.

Given this, we perhaps could define as follows:

   An identifier is global iff there is only one possible context in  
which we can interpreting it.

That is, if an identifier drawn from a name space will always be  
interpreted in the same way, yielding the same behaviour, independent  
on where (and when?) it is used, then it is global.

Along the same lines:

   An identifier is virtual iff there is a separate context,  
different from the "usual" context, in which we will interpret the  
identifier.

That is, identifiers are "virtual" (as opposed to "real") if they are  
interpreted using some given, "virtual" context, different from the  
default context where they would be interpreted without virtualisation.

This seems to match with our typical usage:

- a virtual memory address is interpreted in terms of the MMU  
translation tables instead of being directly handled by the  
demultiplexing logic at the chip select and chip level

- a VPN address is interpreted in terms of the routing internal to  
the VPN instead of being interpreted in terms of the global routing  
table

--Pekka Nikander

---

From: John Day <[email-masked]>
Date: Thu, 23 Nov 2006 07:36:16 -0500

>   An identifier is meaningless without a defining context.

Yes, in the past we have used "name" for this as the most general 
form of label.  And always reserved "identifier" for things that we 
saw as short and probably numeric.  But that was really a fairly 
informal convention.

>unless we know the context in which we should understand it.

Agreed.   When a name is defined, sorry identifier, one must also 
define what it names, the name space from which the names are taken, 
and the scope of the name.

>which we can interpreting it.

Yes.  The universal set in a different guise.

>interpreted in the same way, yielding the same behaviour, 
>independent on where (and when?) it is used, then it is global.

If you add "when applied within the defined scope of the name space" 
then you have the general definition.

>different from the "usual" context, in which we will interpret the 

I would prefer not to use this. I had used it before as analogy with 
operating systems to give an idea of what we needed to do.  To help 
people think about it.  This is where defining scope becomes 
important.

In this sense, virtual is only virtual ;-) in the sense that higher 
layers of naming represent a higher level of abstraction than lower 
ones. But here I don't think the abstraction is as important as the 
property that scope tends to increase as one moves up in the layers.

>
>That is, identifiers are "virtual" (as opposed to "real") if they 
>are interpreted using some given, "virtual" context, different from 
>the default context where they would be interpreted without 
>virtualisation.
>

Good show, Pekka.

Take care,
john

---

From: Jefsey_Morfin <[email-masked]>
Date: Thu, 23 Nov 2006 13:15:39 +0100

>However, we first have to understand a crucial point:

I am afraid you confuse names and identifiers.
Names are intrinsic to something, to some people, in a given 
relational space. Home you will be Pekka, in Army you will Nikander.

In a given virtuality (which may encompass many relational spaces) an 
Identifier is related to a name. For example in a group you can be nr 
19 by alphabetical order and nr 37 by age order. This will be noted 
as a 19 or a 37 in front of your name, or printed on your T-Shirt. 
But you will stay Pekka Nikander.

Global does not opposes to virtual but to intrinsic or real. 
Telephone numbers or IPv6 addresses build a global virtuality. If no 
one answers, their  virtuality still exists.
jfc

---

From: "Bound, Jim" <[email-masked]>
Date: Thu, 23 Nov 2006 22:03:33 -0500

I agree and in this definition I think an anycast address is virtual too
the address in of itself does not identify what node the packet will be
delivered.

/jim 

> From: Pekka Nikander [mailto:[email-masked]] 
> Sent: Thursday, November 23, 2006 6:05 AM
> To: [email-masked]
> Cc: John Day
> Subject: [arch-d] On identifiers: what is virtual and what is 
> global (was Re:thoughts)
> 
> when speaking about identifiers, names, and name spaces.  I 
> must be missing something because I think we could have 
> pretty simple definitions for both "global" and "virtual", 
> both given below.
> 
> That is, an identifier is merely an non-interpretable string 
> of bits unless we know the context in which we should understand it.
> 
>    An identifier is global iff there is only one possible 
> context in which we can interpreting it.
> 
> That is, if an identifier drawn from a name space will always 
> be interpreted in the same way, yielding the same behaviour, 
> different from the "usual" context, in which we will 
> interpret the identifier.
> 
> That is, identifiers are "virtual" (as opposed to "real") if 
> they are interpreted using some given, "virtual" context, 
> different from the default context where they would be 
> interpreted without virtualisation.
> 
> - a VPN address is interpreted in terms of the routing 
> internal to the VPN instead of being interpreted in terms of 
> the global routing table
> 
> --Pekka Nikander
> 
>

---

From: John Day <[email-masked]>
Date: Thu, 23 Nov 2006 22:23:29 -0500

>the address in of itself does not identify what node the packet will be

Neither an anycast address nor a multicast address are addresses.  We 
have been sloppy in our terminology. They are names of sets of 
addresses such that when referenced the result is a list of one or 
more addresses according to some rule associated with the set.

Since addresses are location-dependent, there is no meaningful way 
for a the name of a set of addresses to be location-dependent.  (Now 
before any of you start suggesting some idea of maximum range or some 
such. Yes, you could attribute such a property to them.  But as some 
on this list keep pointing out, "It's the routing!"  Such 
interpretations of location-dependent are no help in routing or 
related issues.  Furthermore, it is fairly easy to come up with 
"monsters" that will make any such use absurd. It is easier to just 
admit they are names and get on with it. ;-))

Take care,
John

---

From: "Bound, Jim" <[email-masked]>
Date: Thu, 23 Nov 2006 23:00:38 -0500

Thanks for your opinion.  Correct the conceptual model of anycast
addressing is virtual.
/jim 

> From: John Day [mailto:[email-masked]] 
> Sent: Thursday, November 23, 2006 10:23 PM
> To: Bound, Jim; Pekka Nikander; [email-masked]
> Cc: John Day
> Subject: RE: [arch-d] On identifiers: what is virtual and 
> what is global (was Re:thoughts)
> 
> >I agree and in this definition I think an anycast address is virtual 
> >too the address in of itself does not identify what node the packet 
> >will be delivered.
> 
> Neither an anycast address nor a multicast address are 
> addresses.  We have been sloppy in our terminology. They are 
> names of sets of addresses such that when referenced the 
> result is a list of one or more addresses according to some 
> rule associated with the set.
> 
> Since addresses are location-dependent, there is no 
> meaningful way for a the name of a set of addresses to be 
> location-dependent.  (Now before any of you start suggesting 
> some idea of maximum range or some such. Yes, you could 
> attribute such a property to them.  But as some on this list 
> keep pointing out, "It's the routing!"  Such interpretations 
> of location-dependent are no help in routing or related 
> issues.  Furthermore, it is fairly easy to come up with 
> "monsters" that will make any such use absurd. It is easier 
> to just admit they are names and get on with it. ;-))
> 
> Take care,
> John
>