Subject: Re: [arch-d] On identifiers: what is virtual and what is global (was Re: thou...

From: [email-masked]
Date: Thu, 23 Nov 2006 11:39:37 EST

virtual versus global?  Isn't it more appropriate to speak of names  and 
alias'es.
And of global addresses versus local addresses ?
My main question however is:
Why is it not feasable to integrate a 4 byte sized AS number (of  the primary 
service provider) into a 16 byte sized IPv6-address ? If a user  changes his 
ISP then he would get a different address anyway! All  these problems with 
prefix building blocks would be gone, all this discussions  on identifiers and 
locators and respective mapping became less virtual.
 
Heiner
 
In einer eMail vom 23.11.2006 13:59:46 Westeuropäische Normalzeit schreibt  
[email-masked]:

On 12:04  23/11/2006, Pekka Nikander said:
>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:

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

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

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

---

From: David Conrad <[email-masked]>
Date: Thu, 23 Nov 2006 12:36:18 -0800

Heiner,

On Nov 23, 2006, at 8:39 AM, [email-masked] wrote:
> Why is it not feasable to integrate a 4 byte sized AS number (of  
> the primary service provider) into a 16 byte sized IPv6-address ?

It is feasible, but since that ties location with identity, you  
aren't solving any real problem.

> If a user changes his ISP then he would get a different address  
> anyway!

This is what we're trying to avoid.

Rgds,
-drc

---

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

> This is what we're trying to avoid.

I don't think this can be avoided nor can it be assumed.  If the address
prefix used by the ISP is different a node should use it and this also
has mobility implications per the use cases I sent.  What should not
change is the identifier.  Thus here we may disagree.  The complexity
for routing for performance reasons will not scale ever in my view.

Best
/jim

---

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

Best
/jim

---

From: David Conrad <[email-masked]>
Date: Thu, 23 Nov 2006 20:23:14 -0800

Jim,

On Nov 23, 2006, at 7:04 PM, Bound, Jim wrote:
> I don't think this can be avoided nor can it be assumed.

Separating identity from location via indirection would allow us to  
avoid folks having to renumber when they change providers and thus  
allowing locators to be highly aggregated.

> If the address
> has mobility implications per the use cases I sent.

The whole point of this discussion is that the term "address" as it  
is used today implies the concepts of identity and location are  
merged.  "Addresses" as they are used today simply will not scale.   
Period.  Since I do not believe we have the luxury of coming up with  
and deploying IPv7, we have to backfit the separation of identity  
from location into IPv6.

> What should not change is the identifier.

Exactly.  To bad identity and location is the same thing in IPv4 and  
IPv6.

> Thus here we may disagree.  The complexity

As I'm sure you are aware, aggregation allows hiding of information  
thereby allowing for greater scalability.  As long as identity and  
location are tied, the only way you can aggregate is by forcing  
identity to change when location changes. Since changing identity is  
hard, people don't do it and thus, scalability goes out the window.  
This does not have to be the case.

Rgds,
-drc

---

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

At 20:23 -0800 2006/11/23, David Conrad wrote:
>>>>If a user changes his ISP then he would get a different address anyway!

We had that opportunity 14 years ago and decided to stick with what 
doesn't work.

Fundamentally one can not "locate" without "identifying."  This is 
why this whole loc/id discussion has been such a red herring. 
Addresses as they are used today are being used in half an addressing 
architecture which is why they don't scale, not because they are 
addresses.

>Exactly.  To bad identity and location is the same thing in IPv4 and IPv6.

Only because you don't have a complete addressing architecture.  If 
it was complete, you would all of the names whether addresses, names 
or identifiers, would do what they need to do quite well.

>This does not have to be the case.

All of these arguments are an artifact of the current approach not 
universally the case.

Perhaps we should figure out what does work and then worry about how 
we get there.  Rather worry about how to fix what we have with no 
clear idea of where we need to go.

Take care,
John

---

From: "Bound, Jim" <[email-masked]>
Date: Fri, 24 Nov 2006 00:39:27 -0500

Dave, 

> Separating identity from location via indirection would allow 
> us to avoid folks having to renumber when they change 
> providers and thus allowing locators to be highly aggregated.

Agree and that aggregation is important but will not always be possible.
We must separate entirely locator and identifier.  Routing and the
locator I use are to me entirely separate from the identification.

> The whole point of this discussion is that the term "address" 
> as it is used today implies the concepts of identity and 
> location are  
> merged.  

That is where I believe I disagree.  Open list and open discussion so we
shall see where it goes.  What Pekka N. proposed leaves this question
open for now. If ISP1 has prefix for location as FFEE but ISP2 has
prefix FEEF the aggregation is only for the first order bits (leaving
undefined) and without more bits location cannot be known for routing.
The identifier comes into play only for me between the two end-to-end
applications, security enhancements, and transport end-points possibly.
Whether that is part of an IP address with the locator for me is
premature discussion and identifying the requirements.

>"Addresses" as they are used today simply will not scale.   
> Period.  Since I do not believe we have the luxury of coming 
> up with and deploying IPv7, we have to backfit the separation 
> of identity from location into IPv6.
> 

Yes and that is the hard part of the work here to alleviate and I am
hoping we hear a lot of different persons bright ideas to resolve this
and analysis.

> 
> > Thus here we may disagree.  The complexity for routing for 
> performance 
> > reasons will not scale ever in my view.
> 
> As I'm sure you are aware, aggregation allows hiding of 
> information thereby allowing for greater scalability.  As 
> long as identity and location are tied, the only way you can 
> aggregate is by forcing identity to change when location 
> changes. Since changing identity is hard, people don't do it 
> and thus, scalability goes out the window.  

Agree with the problem statement and why I allude above that the
identifier may not part of the IP address.

Best,
/jim

---

From: David Conrad <[email-masked]>
Date: Tue, 28 Nov 2006 01:02:49 -0800

Jim,

> Agree and that aggregation is important but will not always be  

I agree that it won't always be possible.  However, we have changed  
the Internet scaling characteristics from tending towards O(ISPs 
+enterprises+end users) to O(ISPs).  As we have an existence proof  
that we can have over 200K entries with today's technology, I think  
we have some room to grow.

>> location are  merged.
> That is where I believe I disagree.

I think you misunderstood me as I believe we mostly agree.

> What Pekka N. proposed leaves this question

Right.  Since I do not believe it realistic to assume we can  
aggregate ISPs without changing ISP business models (which they are  
not particularly inclined to do), I'm implicitly assuming that each  
ISP would have their own prefix.  That is, at the highest level of  
hierarchy, the locator space would be flat.

However, a nice aspect of separating identity from location (and  
providing a mapping function to translate between the two) is that in  
the future, we can rip out the location mechanism and replace it with  
something better without impacting the end users (in fact, they won't  
even have to know there has been a change), so if we discover the two- 
tiered approach doesn't scale enough for whatever reason, we can  
deploy a new/better solution much, much more easily.

> applications, security enhancements, and transport end-points  

Yes.

> premature discussion and identifying the requirements.

As I've said previously, I don't like to use the term "address" as it  
blurs the line between the two different functions of "identification  
of end point" and "location of network attachment".  These two  
functions can obviously be merged into a single bit string (albeit, I  
believe this will require changes to all deployed TCP/IP stacks which  
I'm skeptical we can do in any reasonable timeframe), but I believe  
it would be really helpful to keep the functions as conceptually  
distinct as possible.

Rgds,
-drc

---

From: Peter Sherbin <[email-masked]>
Date: Tue, 28 Nov 2006 11:47:04 -0800 (PST)

> of end point" and "location of network attachment"

Just a thought:

- person's name = ID
- person's address = location (geo, topo, any physical)
- ID does not change
- location changes often

to reach a person an envelope needs a combination: ID + location

Could the same principle apply to a network:
- ID's and locators are independent
- Uniqueness realizes at the attachment point = ID + location

Result
- No dependency on a provider
- No scaling problem because the routing table is fixed in a robust hierarchy

Thank you,

Peter

> it would be really helpful to keep the functions as conceptually  

____________________________________________________________________________________
Do you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail beta.
http://new.mail.yahoo.com

---

From: John Day <[email-masked]>
Date: Tue, 28 Nov 2006 15:15:40 -0500

Peter,

Very good.  This is a good start.

>to reach a person an envelope needs a combination: ID + location

This is the conclusion in John Shoch's paper. "Internetwork Naming, 
Addressing, and Routing," IEEE Proc. COMPCON Fall 1978, pp. 72-79.

>- No scaling problem because the routing table is fixed in a robust hierarchy

While necessary, this is not sufficient.  As worked out few years 
later in, Saltzer, Jerry. "On the Naming and Binding of Network 
Destinations" in Local Computer Networks, edited by P. Ravasio et al. 
P North-Holland Publishing Company, pp 311-317, 1982, republished as 
RFC 1498.

I can't recommend strongly enough that you very carefully read and 
understand this paper.  Then you will understand why loc;/id split is 
not the whole story and if by concentrating on that and that alone is 
a red-herring.  As we have seen it gets one as far as Shoch's 
conclusions, but it doesn't go far enough.

Saltzer concludes rightly, that a network architecture requires at a 
minimum application names, node addresses, and point of attachment 
addresses.  The current Internet has only the latter.

As I have pointed out earlier on this list, Salzter does miss one 
important point (understandably), but that can wait until you have 
worked through the paper.

Take care,
John Day

---

From: David Conrad <[email-masked]>
Date: Tue, 28 Nov 2006 19:16:00 -0800

John,

A quibble:

On Nov 28, 2006, at 12:15 PM, John Day wrote:
> Saltzer concludes rightly, that a network architecture requires at  
> a minimum application names, node addresses, and point of  
> attachment addresses.  The current Internet has only the latter.

No. The Internet has all three.  The problem is that these three  
namespaces are overloaded onto the same bit string, resulting in  
significant loss of functionality and greatly limiting scalability.   
I suspect what you meant to say was something along the lines of "a  
scalable network architecture requires at a minimum separate  
application names, node addresses, and point of attachment addresses."

Rgds,
-drc

---

From: John Day <[email-masked]>
Date: Tue, 28 Nov 2006 22:36:44 -0500

I will quibble with your quibble. ;-)

The Internet was built with only one of them.  Over the past 30 
years, the Internet has tried one band-aid, kludge and hack after 
another to try to avoid actually fixing the problem, yielding your 
perception that it has all 3 one bit string.  It remains that that 
bit string only names one thing: the interface.

Isn't it interesting that the *Internet* address names a subnet point 
of attachment?  A little cognitive dissonance.

Harkens to what one might expect from a bellhead rather than netizen, 
doesn't it?

Maybe we never finished the paradigm shift.

---

From: "Bound, Jim" <[email-masked]>
Date: Wed, 29 Nov 2006 10:57:40 -0500

Dave,

Good responses.  How I want to respond now I think supports the abstract
view and assumptions from Pekka N. and Brian C. concerns for
optimizations to continue to work on the Internet (as I paraphrase
multiple conversations).  Also we are in complete synch on the benefits
of aggregation below.  I leave your mail in tact below I hope that works
for readers of the thread I am never sure when to reduce the text in a
thread?

1.  If we are not going to call the "thing" that sits in the IP header
as src and dst address can we please pick a reference point for these I
think that will help us not enter forever do-loop for analysis and
discussion.  A suggestion route-identifiers (RI). What I like about this
and why I suggest it is I think end-to-end identifiers may be different
and become EIs.  But we need a term other than address for routing it
seems to me.

2.  Regarding the RI or the identifier in conjunction with location:

a.  I do not believe we can assume the Internet will work or any network
with billions of transactions if router-infrastructure (that can mean
many things and not just routers) have to do a DNS, LDAP, or other
name-space to be invented look-up on the identifiers within the
location-ID (RI).  So as implementer I am highly concerned we address
this issue sooner rather than later in the model discussion.

b.  Given seamless mobility which to me is the node changes its location
coordinates to a new routing area with different high-order aggregation
first order bits, I don't see how it can be avoided to report that new
RI back to the Home Agent, Nemo Router, etc. Thus I do believe in and
buy into the current IETF RFCs for Network Mobility and that should be
transparent to the work here.  This I think is important to the model
discussion and any assumptions about mobility or nomadicity.

Thus I would be happy camper at this point if we could adopt a new name
for address such as RI, determine how the identifier will be used for
routing (different than the EI), and what are our initial thoughts on
impact to mobility.  

At least as a start for this point from our threads.

Best,
/jim

> -----Original Message-----
> From: David Conrad [mailto:[email-masked]] 
> Sent: Tuesday, November 28, 2006 4:03 AM
> To: Bound, Jim
> Cc: [email-masked]
> Subject: Re: [arch-d] On identifiers: what is virtual and 
> what is global (wasRe: thou...
> 
> Jim,
> 
> I agree that it won't always be possible.  However, we have 
> changed the Internet scaling characteristics from tending 
> towards O(ISPs 
> that we can have over 200K entries with today's technology, I 
> think we have some room to grow.
> 
> > What Pekka N. proposed leaves this question open for now. 
> If ISP1 has 
> > prefix for location as FFEE but ISP2 has prefix FEEF the 
> aggregation 
> > is only for the first order bits (leaving
> aggregate ISPs without changing ISP business models (which 
> they are not particularly inclined to do), I'm implicitly 
> assuming that each ISP would have their own prefix.  That is, 
> at the highest level of hierarchy, the locator space would be flat.
> 
> However, a nice aspect of separating identity from location 
> (and providing a mapping function to translate between the 
> two) is that in the future, we can rip out the location 
> mechanism and replace it with something better without 
> impacting the end users (in fact, they won't even have to 
> know there has been a change), so if we discover the two- 
> tiered approach doesn't scale enough for whatever reason, we 
> can deploy a new/better solution much, much more easily.
> 
> As I've said previously, I don't like to use the term 
> "address" as it blurs the line between the two different 
> functions of "identification of end point" and "location of 
> network attachment".  These two functions can obviously be 
> merged into a single bit string (albeit, I believe this will 
> require changes to all deployed TCP/IP stacks which I'm 
> skeptical we can do in any reasonable timeframe), but I 
> believe it would be really helpful to keep the functions as 
> conceptually distinct as possible.
> 
> Rgds,
> -drc
> 
>

---

From: John Leslie <[email-masked]>
Date: Wed, 29 Nov 2006 13:55:45 -0500

Bound, Jim <[email-masked]> wrote:
>    as src and dst address can we please pick a reference point for these

   I strongly recommend that we call the "thing" that sits in the IPv4
header as destination address an "IPv4 destination address", and the
"thing" that sits in the IPv6 header as a destination address an
"IPv6 destination address". That, after all is exactly and _only_
what they are.

   (The "things" which sit in those headers as source addresses are
something else entirely, I agree; and I'm open to any suggestions...)

   IPv4 and IPv6 are, after all, protocols for sending packets to
addresses which may be on a different network. IPv4 and IPv6
destination addresses, except for the trivial case where the address
can be shown to be on the same network, are opaque strings to be
passed to a gateway "closer" to the destination.

   Thus, they are not "locators" in the general case to the forwarders
that must process them -- they are only "locators" to routers which
have a "complete" view of internetworking routes.

   (The actual parameters passed to operating systems to open TCP
sockets and connections are _also_ something else entirely: we must
not confuse TCP endpoints with IPvN destination addresses.)

   I quite agree with John Day that these "things" are "point of
attachment" addresses; not "node addresses" or "application names".
TCP, alas, tends to use them as if they were node addresses. :^(

   (One could argue, indeed, that the IPvN "source address" is in
fact a "node address", but I'd rather steer clear of that flamewar...)

--
John Leslie <[email-masked]>

---

From: "Bound, Jim" <[email-masked]>
Date: Wed, 29 Nov 2006 15:48:04 -0500

I right now agree with your input. Two points I do want to note for
discussion are what is passed to transport connections are end-to-end
identifiers in my view and should not be exposed in the IPvN headers or
used for loc+id.  Also on source addresses my pain has been if they get
altered then I am unclear how I respond back at the OS transport end.
But if I am no longer using the notion of a current source address at
the transport end I don't care about that anymore and if that is
possible that is a good thing.  I believe shim6 and hip get us very
close to this model for the transport with current architecturs and
specifications.

NB: In particular not for this thread it opens up brand new use of
ingress/egress filtering, use of anycast address concepts for
deployment, and moves us to using an identifier for IPsec, but will need
that provided to the dst entity in some form or derived from what is in
the IPvN header and that still gets complex.  I am assuming all but the
IPvN header and possibly options with IPv6 are encrypted.  Though we can
continue to use the IPvN dst address for IPsec and tackle that problem
later but make note to ietf-arch-self it is a problem now.

Best,
/jim 

> From: John Leslie [mailto:[email-masked]] 
> Sent: Wednesday, November 29, 2006 1:56 PM
> To: Bound, Jim
>    I strongly recommend that we call the "thing" that sits in 
> the IPv4 header as destination address an "IPv4 destination 
> address", and the "thing" that sits in the IPv6 header as a 
> destination address an
> "IPv6 destination address". That, after all is exactly and 
> _only_ what they are.
> 
>    (The "things" which sit in those headers as source 
> addresses are something else entirely, I agree; and I'm open 
> to any suggestions...)
> 
>    IPv4 and IPv6 are, after all, protocols for sending 
> packets to addresses which may be on a different network. 
> IPv4 and IPv6 destination addresses, except for the trivial 
> case where the address can be shown to be on the same 
> network, are opaque strings to be passed to a gateway 
> "closer" to the destination.
> 
>    Thus, they are not "locators" in the general case to the 
> forwarders that must process them -- they are only "locators" 
> to routers which have a "complete" view of internetworking routes.
> 
>    (The actual parameters passed to operating systems to open 
> TCP sockets and connections are _also_ something else 
> entirely: we must not confuse TCP endpoints with IPvN 
> destination addresses.)
> 
>    I quite agree with John Day that these "things" are "point 
> of attachment" addresses; not "node addresses" or "application names".
>    (One could argue, indeed, that the IPvN "source address" 
> is in fact a "node address", but I'd rather steer clear of 
> that flamewar...)
> 
> --

---

From: Peter Sherbin <[email-masked]>
Date: Wed, 29 Nov 2006 13:12:06 -0800 (PST)

> RFC 1498

Saltzer identifies 4 network objects:
1.Service/aka Application; 2.Node; 3.Network Attachment Point/aka Interface; 4.Path

Routing only needs a unique Interface, which reduces objects to 2: 1.Interface and
2.Path. But too many nets to remember still choke routers.

Could the split work as follows:
- AS hierarchy constructs a backbone
- Providers get AS numbers bound to a given physical space
- EU get IPv6 addresses bound to a given physical space
- no change for routing on private networks
- for public routing a source and a destination addresses must add ASN
- when a mobile interface attaches to a foreign AS it already knows its home ASN to
reach its home node(s)
- receiving node learns about sending node's ASN and establishes communication

There are some limitations:
- unless a mobile node on a foreign AS sends a packet, home node does not know where
the mobile node is
- private networks who want to communicate have to acquire each other ASN in advance
and put them into destination address
- scalability of AS hierarchy 
- scalability of routing within AS

Thanks,
Peter

---

From: John Day <[email-masked]>
Date: Wed, 29 Nov 2006 16:36:35 -0500

>2.Path. But too many nets to remember still choke routers.

Actually he says routes, not paths.  And he says that application 
names map to node addresses and node addresses are mapped to point of 
attachment addresses which are mapped to routes.

But this is where he goes a bit astray (and understandably) because 
at the time he wrote there were no cases (or very very few) of 
multiple paths to the next hop.  SO, if you adjust his model for that:

Application names are mapped to node addresses by a directory.
Routes are calculated from node addresses.  From the routing 
calculation, you determine the next hop.
Then you need the mapping of node address to point of attachment 
address for all of your nearest neighbors.  From this, a subset gives 
you know all of the possible paths from this point to the next hop, 
so by some criteria you choose one.  It is fundamentally a two step 
process.

Now notice something interesting.  The mapping of application names 
to node addresses and the mapping of node addresses to points of 
attachments for all nearest neighbors are essentially the same 
mapping.  They are both all mappings one hop away.  Hmmmm.

>- receiving node learns about sending node's ASN and establishes communication

You are looking for a kludge.  This is the arch-d list.  We are 
looking for the right solution.  Then we will worry about how to get 
there.  Once you know where you are going, it will be easier to 
figure out how to get there.

Don't skip steps.  You will drop a sign or worse! (metaphorically).

>- scalability of routing within AS

These are all show stoppers.

I would suggest that a more interesting exercise is to answer the 
following questions:

what protocol carries the point of attachment address?
what protocol carries the node address?
what protocol carries the application name?

For the whole thing to work, they must be managed independently.

---

From: John Leslie <[email-masked]>
Date: Wed, 29 Nov 2006 16:52:19 -0500

Bound, Jim <[email-masked]> wrote:
>> destination address an "IPv6 destination address".
>>...
> Two points I do want to note for discussion are
> 
> what is passed to transport connections are end-to-end identifiers
> in my view and should not be exposed in the IPvN headers or used
> for loc+id.

   I agree they are end-to-end identifiers, even if they look exactly
like IPvN addresses.

   That they currently are exposed in IPvN headers is an accident of
history: TCP never defined a standard for exchanging anything else
as endpoint identifiers. (Clearly, both ends of a TCP connection
need to agree how to distinguish that a packet belongs to that
connection: IPvN addresses have worked OK for that purpose. Endpoint
identifiers _could_ be something else entirely; and need not be
visible at all to the IPvN layer.)

   We must allow _something_ to be used for loc+id within IPvN; but
it'd be fine if, for example, the application passed FQDNs as the
endpoint IDs and the operating system did a DNS-like query to find
loc+id.

> Also on source addresses my pain has been if they get altered then
> I am unclear how I respond back at the OS transport end.

   This is indeed a mess right now. NAT boxes routinely alter these
and "try" to maintain enough state to alter them back. :*(

> But if I am no longer using the notion of a current source address
> at the transport end I don't care about that anymore and if that is
> possible that is a good thing.

   IPvN source addresses are used to report routing problems: other
than that, they can mostly be ignored. (Indeed, they can't even be
trusted for that much: the less we depend on them, the better.)

   (There was a time when we believed routing based on source
address would help. Most of us would like to bury that idea...)

> I believe shim6 and hip get us very close to this model for the
> transport with current architecturs and specifications.

   I must admit that I view both shim6 and hip as moving targets
trying to be too many things to too many people. I suspect I'm not
alone. In any case, both of those are engineering, not architecture;
for purposes of this list I suggest explaining which features of them
you'd like to compare, rather than just naming a protocol.

---

From: "Bound, Jim" <[email-masked]>
Date: Wed, 29 Nov 2006 20:49:50 -0500

agree again.  also no attachment to src addresses at my end.  agree on
identifying transport points of the protocols to the architecture but
want to go offline with Pekka N. on that one and can do as I can around
the day job of course.  the reason to do this arch exercise is the
potential of freeing the transport layer from IPvN layer and components,
which affords routing more freedom in thinking models.  but to note both
shim6 and hip have done this and some implementation exists.

Best,
/jim

> Sent: Wednesday, November 29, 2006 4:52 PM
> To: Bound, Jim
>  the IPv4 
> >>"IPv6 destination address".
> >>...
> >>sockets and connections are _also_ something else
> >> entirely: we must not confuse TCP endpoints with IPvN  destination 
> >>addresses.)
> > 
> > what is passed to transport connections are end-to-end 
> identifiers in 
> > my view and should not be exposed in the IPvN headers or used for 
> > loc+id.
> 
>    I agree they are end-to-end identifiers, even if they look 
> exactly like IPvN addresses.
> 
> history: TCP never defined a standard for exchanging anything 
> else as endpoint identifiers. (Clearly, both ends of a TCP 
> connection need to agree how to distinguish that a packet 
> belongs to that
> connection: IPvN addresses have worked OK for that purpose. 
> Endpoint identifiers _could_ be something else entirely; and 
> need not be visible at all to the IPvN layer.)
> 
>    We must allow _something_ to be used for loc+id within 
> IPvN; but it'd be fine if, for example, the application 
> passed FQDNs as the endpoint IDs and the operating system did 
> a DNS-like query to find
> loc+id.
> 
> > Also on source addresses my pain has been if they get 
> altered then I 
> > am unclear how I respond back at the OS transport end.
> 
>    This is indeed a mess right now. NAT boxes routinely alter 
> these and "try" to maintain enough state to alter them back. :*(
> 
>    IPvN source addresses are used to report routing problems: 
> other than that, they can mostly be ignored. (Indeed, they 
> can't even be trusted for that much: the less we depend on 
> them, the better.)
> 
>    I must admit that I view both shim6 and hip as moving 
> targets trying to be too many things to too many people. I 
> suspect I'm not alone. In any case, both of those are 
> engineering, not architecture; for purposes of this list I 
> suggest explaining which features of them you'd like to 
> compare, rather than just naming a protocol.
> 
> --

---

From: John Day <[email-masked]>
Date: Wed, 29 Nov 2006 21:14:19 -0500

Not quite.  Sooner or later you are going to realize that that there 
are no such thing as Transport Addresses.  In fact, transport is sort 
of a minor layer at best.  As far as this problem is concerned, 
Transport is irrelevant to the solution.

Transport has no effect on the routing and its components and doesn't 
constrain its possibilities in the least.

QED

---

From: Peter Sherbin <[email-masked]>
Date: Wed, 29 Nov 2006 18:56:15 -0800 (PST)

> Actually he says routes, not paths.

for the sake of accuracy: "4. Paths. These run between network attachment
points,..." [RFC 1498, p.3]

>...he says that application names map to node addresses and node addresses are
mapped to point of attachment addresses which are mapped to routes.

1. The above requirement is not mandatory for routing. Node hierarchy can be
transparent to the network hierarchy.
2. It holds true for a limited sample of relatively big machines supporting several
applications and/or multiple interfaces. For the prevailing majority of
microcomputers and sensors Application = Node = Interface.
 
> You are looking for a kludge.
More thoughts
>>- unless a mobile node on a foreign AS sends a packet, home node does not know
>> where the mobile node is
Which is OK, because home needs an info from the remote node and the remote node
first will have to contact home

>>- private networks who want to communicate have to acquire each other ASN in
OK, because now I control whom I am going to communicate with

>>- scalability of AS hierarchy
non issue, there is no need even to extend 16bit ASN to 32bit, instead introduce
upper tier ASN

>>- scalability of routing within AS
mitigate by e.g. limiting number of /32's per AS

> what protocol carries the point of attachment address?
IP

> what protocol carries the node address?
IP, where node = interface

> what protocol carries the application name?
TCP, but does it really need an application name?

Thanks,
Peter

---

From: John Leslie <[email-masked]>
Date: Wed, 29 Nov 2006 22:07:39 -0500

John Day <[email-masked]> wrote:
> are no such thing as Transport Addresses.

   I try to avoid saying "transport" layer / address / etc. because I
believe it means too many different things to too many people.

   Actually, I agree that TCP-as-we-know-it isn't a "transport layer"
and most assuredly lacks anything we should call a "transport address".

> In fact, transport is sort of a minor layer at best.

   It depends...

   When I do talk of a "transport layer", I mean a layer that worries
about reliability, and thus detects and deals with

- packet loss,
- packet corruption, and
- choosing among multiple paths (if available).

  I cannot agree with John Day that a layer which does that much is
just a "minor layer". That much done right would solve

- multi-homing,
- mobility,
- congestion, and
- most forgery.

> As far as this problem is concerned, Transport is irrelevant to the
 solution.

   I'm not sure what "this problem" John Day is talking of, but
"transport" isn't "irrelevant" to the problems I'm trying to talk
about.

> constrain its possibilities in the least.

   Transport _shouldn't_ affect routing; but doing transport wrong
(like, e.g. TCP) can constrain routing pretty severely. :^(

---

From: John Day <[email-masked]>
Date: Wed, 29 Nov 2006 23:12:45 -0500

>points,..." [RFC 1498, p.3]

ooops, bad memory!  I knew I should have checked it.  Although right 
after that he refers to it as a route service.

>transparent to the network hierarchy.

What node hierarchy?  Address assignment hierarchies are used to 
better manage address space their correspondence to hierarchies of 
subnets is purely coincidental.  It is important not to confuse the 
two.

>microcomputers and sensors Application = Node = Interface.

This is science.  Our goal is to find the minimal set of concepts 
that encompass the whole problem..  The attitude that most systems 
are not multihomed and therefore we don't need to look for a real 
solution is what got us into this mess to begin with.

>first will have to contact home

We have already established that a mobility solution with a concept 
of "home" is a kludge.

>  >>- private networks who want to communicate have to acquire each 
>other ASN in
>>>advance

Gee, I thought it was MAC protocol.

>IP, where node = interface

Node does not equal interface.  That is why we are having this discussion.

But you are right.  IP does carry point of attachment and the IETF in 
its infinite (and misguided) wisdom has decreed that it shall be the 
case:  Full emulation of Faber Marching Band.

>TCP, but does it really need an application name?

TCP!?  Or any such protocol?  Nah.  Have you looked at these 
protocols?  They are purely single instances of communication.  They 
have no functionality across instances.  Very clean.  We don't want 
to destroy that.  Don't make them any more complex than they are.

What about application connections?

Take care,
John

---

From: John Day <[email-masked]>
Date: Wed, 29 Nov 2006 23:18:27 -0500

>and most assuredly lacks anything we should call a "transport address".

Nor should any transport protocol,

>- choosing among multiple paths (if available).

None that I know of do the latter.  O, yes, SCTP tries to but how? 
This is just because we have failed to do the relaying and 
multiplexing functions well.  It really is in no position to do it.

>just a "minor layer". That much done right would solve

Really only congestion in this list has anything to do with 
Transport, well, that class of protocols.

>"transport" isn't "irrelevant" to the problems I'm trying to talk

Multihoming, mobility, routing, security, etc.  Everything but error 
and flow control on a single flow.

>(like, e.g. TCP) can constrain routing pretty severely. :^(

Well, as one of the best system designers I ever knew often said, "if 
you don't do it right, it won't work."  ;-)

Take care,
John

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 30 Nov 2006 09:57:22 +0200

> you'd like to compare, rather than just naming a protocol.

I'm certainly digressing below, but I can't help feeling sympathetic  
to both HIP and SHIM6/CGA, for obvious reasons. :-)

 From my point of view, HIP and SHIM6 implement the so-called  
identifier-locator split in the sense that they separate the  
identifiers that are passed through the socket API from the  
"addresses" that are placed in the IPvN header.  There I completely  
agree with Jim.

What comes to the current state of HIP and SHIM6, I wouldn't call  
them that moving targets any more.  The base HIP specs have been  
fairly stable for a couple of years now, and are in the final stages  
of getting through the IESG.  In the last calls there's been nothing  
earth shattering, mostly clarifications on intended usage and  
behaviour in certain corner cases.  There are three open source,  
interoperable implementations, running on Linux, FreeBSD, Windows,  
and Mac OS X.  The only moving target today seems to be the way the  
host identities are referred to through the backwards compatibility  
API; see http://www.ietf.org/internet-drafts/draft-laganier-ipv6- 
khi-05.txt

 From my point of view, HIP has never really intended to be very many  
things.  Metaphorically, it has always just tried to be the  
proverbial Indian elephant, nothing more and nothing less.  What  
cannot be helped is that different blinds feel it in different way;  
http://en.wikipedia.org/wiki/Blind_Men_and_an_Elephant

As explained in RFC 4423, the purpose of HIP is to establish a new,  
cryptographic name space into the stack, somewhere between the  
internetworking and transport layers.  However, by adding this new  
identity space and thereby a new layer of indirection, it *naturally*  
creates a way of implementing mobility, a way of implementing multi- 
address multi-homing, and a provides a name space for security  
purposes.  As an added plus, there comes lots of other properties,  
including (IMHO) better-engineered NAT traversal, ability to use IPv4  
and IPv6 interchangeably, ability to use delegation to implement  
subnetwork mobility, ability to use delegation to represent "higher- 
level" names such as application and application instance names,  
etc.  But those are all just consequences of the architectural  
change.  Architecturally speaking, they are all made easy by  
providing a new secure layer of indirection.

Hence, given its purpose, I would consider HIP architectural and not  
just engineering.  A new name space is a new name space, and that is  
something architectural.  On the other hand, the way the new name  
space is embedded into the stack for backwards compatibility is  
certainly engineering; depending on your point of view, it can be  
considered either as very clever engineering or as an utterly ugly  
kludge.  See http://www.ietf.org/internet-drafts/draft-ietf-hip- 
applications-00.txt and the last call comments to draft-laganier-ipv6- 
khi-05.txt.

Now, considering SHIM6 first from the technical point of view, I see  
it mainly motivated by the desire of allowing combined id+locators to  
be still used in the socket API, thereby reducing the pressure to  
update resolvers, adding new infrastructure to support a new name  
space, and making it slightly less probable that referrals will  
break.  But then, again, far more than being motivated by technical  
grounds, SHIM6 represents a political compromise, trying not to  
aggravate Mobile IP people (by officially stating that that it is not  
a mobility protocol while in reality being very close to one), trying  
to satisfy those people who are afraid of burning CPU cycles for any  
kind of crypto by allowing one to use very little crypto, and trying  
to comfort those people that still are afraid of breaking application- 
level IP-address-based referral, in these NATed ages, by allowing the  
combined id+locs to be used in the socket API.

What comes to SHIM6 as an architecture, I would consider it, at least  
in its current stage, less architecture and more engineering.  Half- 
architectural, if you will, since it kind-of allows you to embed a  
new name space into the stack (through using CGAs) but does not  
mandate it (allowing HBAs).  My personal view of SHIM6 is that it is  
a kind-of watered-down version of HIP, officially trying to achieve  
clearly less than HIP but at the same time unofficially crawling  
towards the directions where HIP has already boldly gone.  :-)  Not  
bad given the committee design.

----

That all said, my personal opinion is that alone both HIP and SHIM6  
are still just band aid, buying more time for the current  
architecture.  Perhaps better-than-usual band aid, due to having at  
least some threads of architecture instead of being completely  
kludgy, but still band aid.

For example, neither of them are able to address the bad traffic  
problem in any way.  Neither of them really help with the  
balkanisation, spreading of SBGs, closing of ports due to "security"  
reasons, and everything moving on the the top of HTTP.  While it  
might be possible to use them in engineering solutions to address  
some of those problems (see e.g. http://www.tml.tkk.fi/~pnr/HIP/draft- 
nikander-hiprg-hi3-00.xml), I'm not too hopeful about the community  
ever getting that far.  I consider it more likely that the results  
the NSF and FP7 funded research will mature before the IETF community  
gets to the stage where HIP, SHIM6, or perhaps some combination of  
them (CHIMP?) can be used as a genuine tool to address the harder  
problems that we have, such as bad traffic.

On the more positive side, while both HIP and SHIM6 would help with  
the current "routing crisis" (as identified by the IAB), they still  
build upon the current routing and addressing paradigm.  While in  
theory they could allow more radical changes of the underlying parts  
of the stack, that would require more drastic changes than either of  
the approaches currently support.  Again, I am not too hopeful about  
the IETF community ever getting there.

--Pekka Nikander

---

From: <[email-masked]>
Date: Thu, 30 Nov 2006 10:28:06 +0200

Hi all,

I've been following the discussions, but one thing that I not been able
to wrap my head
around is that if we split the identity & locator, what is it that we
are identifying.
We could be identifying the interface, the stack, the host, the process,
the application. 

For example, with SHIM6, congestion control will be quite difficult (if
not impossible) if 
you try to use SHIM addresses with SCTP. As SCTP calculates congestion
control per network
path, if the addresses used no long indicate a network path, all bets
are off.

The discussions on this list have pointed out many possibilities of what
& how we can
identify things, but when I start to look at how some of the potential
identifiers map
to transport protocols, to processes, to applications, things get a bit
messy.

Does anyone have any pointers on background reading on this issue?

thanks,
John

---

From: "Bound, Jim" <[email-masked]>
Date: Thu, 30 Nov 2006 03:38:20 -0500

I am working here on engineering (not a computer science research
project) for an architecture that will assist routing, but alleviating
the business problem for operators that are not just network providers
from the multihoming problem to some degree permits us more time to
resolve the architecture issue at hand for routing.  If the transport
layer, which does rely on IPvN addresses in any implementation code I
have ever seen for lookups etc., can be made to not be dependent on IPvN
addresses, that will permit aggregation of IPvN addresses for some time
to avoid the collision presented by the IAB at San Diego potentially.
Thus it is important and I don't agree with John Day.

Best,
/jim 

> From: John Day [mailto:[email-masked]] 
> Sent: Wednesday, November 29, 2006 9:14 PM
> To: Bound, Jim; John Leslie
> Subject: RE: [arch-d] On identifiers: what is virtual and 
> Not quite.  Sooner or later you are going to realize that 
> that there are no such thing as Transport Addresses.  In 
> fact, transport is sort of a minor layer at best.  As far as 
> this problem is concerned, Transport is irrelevant to the solution.
> 
> Transport has no effect on the routing and its components and 
> doesn't constrain its possibilities in the least.
> 
> QED
> 
> >potential of freeing the transport layer from IPvN layer and 
> >components, which affords routing more freedom in thinking 
> models.  but 
> >to note both
> >>  >> From: John Leslie [mailto:[email-masked]]  >>  >> I strongly 
> >> recommend that we call the "thing" that sits in
> >>   the IPv4
> >>  >>header as destination address an "IPv4 destination  
> address", and 
> >> the  >>"thing" that sits in the IPv6 header as a  
> destination address 
> >> an
> >> >>sockets and connections are _also_ something else  >> 
> entirely: we 
> >> must not confuse TCP endpoints with IPvN  destination
> >>  >>addresses.)
> >>  >
> >>  > Two points I do want to note for discussion are  >  > what is 
> >> passed to transport connections are end-to-end  
> identifiers in  > my 
> >> view and should not be exposed in the IPvN headers or used for  > 
> >> loc+id.
> >>
> >>  Endpoint identifiers _could_ be something else entirely; 
> and  need 
> >> not be visible at all to the IPvN layer.)
> >>
>  IPvN; but 
> >>  > Also on source addresses my pain has been if they get  altered 
> >> then I  > am unclear how I respond back at the OS transport end.
> >>
> >>  > But if I am no longer using the notion of a current source  
> >> address at  > the transport end I don't care about that 
> anymore and 
> >> if that is  > possible that is a good thing.
> >>
> >>  other than that, they can mostly be ignored. (Indeed, they  can't 
> >> even be trusted for that much: the less we depend on  them, the 
> >> better.)
> >>
> >>  > I believe shim6 and hip get us very close to this model 
> for the  > 
> >> for purposes of this list I

---

From: "Bound, Jim" <[email-masked]>
Date: Thu, 30 Nov 2006 04:03:13 -0500

This is an important reality discussion point that has been an
under-tone for some on the discussion.  Some thoughts below. 

> I've been following the discussions, but one thing that I not 
> been able to wrap my head around is that if we split the 
> identity & locator, what is it that we are identifying.
> We could be identifying the interface, the stack, the host, 
> the process, the application. 

5 years ago I would have said the interface. but now I believe the
stack. given VM guest OS proliferation.  but only in the context of
"routing".

> 
> For example, with SHIM6, congestion control will be quite 
> difficult (if not impossible) if you try to use SHIM 
> addresses with SCTP. As SCTP calculates congestion control 
> per network path, if the addresses used no long indicate a 
> network path, all bets are off.

Bingo. At the transport layer given we move to identifiers for end point
processes and applications the identifier would have to have associative
pointer to IPvN address for network path. If that IPvN dst path has
loc+id that requires another lookup on id part and already sent mail
concerned simply about the performance.

> 
> The discussions on this list have pointed out many 
> possibilities of what & how we can identify things, but when 
> I start to look at how some of the potential identifiers map 
> to transport protocols, to processes, to applications, things 
> get a bit messy.

I agree thus we need to define and crisply state what is the id part,
how is it used for a network path, how do I know from the id what the
network path is and then after all that is this truly the right approach
for routing, we do not know that for sure yet either IMHO.

But I do not think application, process, or an end-to-end identifier
represents at all the same identifier for a routing paradigm they are
orthogonal and separate.  At least right now that is what I think.

> Does anyone have any pointers on background reading on this issue?

Per the above context I have never seen anything on such an id for
routing or network path other than some very intense views using
fractals indirectly, and that was a long time ago.  I think its a new
space other than indirect subtle references from within the IETF
community provided early on in the discussion aka NIMROD.  If folks have
such pointers that would be highly helpful.

Best,
/jim

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 30 Nov 2006 11:27:28 +0200

John,

> I've been following the discussions, but one thing that I not been  
> able to wrap my head around is that if we split the identity &  
> locator, what is it that we are identifying.  We could be  
> identifying the interface, the stack, the host, the process, the  
> application.

I think part of the problem is that the current discussion is taking  
place at least at two different levels, maybe at more.  To me (and I  
know I'm at least partially wrong), the two levels seem to be roughly  
as follows:

1. Most of the time, John Day, Noel, and I are trying to discuss what  
would be the "right" long term architecture, simultaneously knowing  
that there aren't no such thing.  That is, disregard IP, start from  
the clean slate, what would be the better ways of doing things.  But  
learning from the existing, including its problems.

2. The discussion RJ started, and many other threads, are less  
ambitious and attempt to "fix" the current architecture by applying  
some kind of an identifier/locator split.  That is, add a new name  
space, add a new layer of indirection, or do something else of the  
same magnitude, which is by no means "small", but pretty much within  
the current paradigm.

To me, both of these two discussions are needed.  If we can "fix" the  
current architecture with something link HIP or SHIM6, that is good  
since we will get maybe 10-20 years more lifetime for it.  On the  
other hand, developing a new networking paradigm will take at least  
10 years of focused work, and probably much more.  Deploying it will  
take much longer, if we ever get that far.

--

Given that, in the ideal world, the primary things that we want to  
identify, IMHO, are whatever the applications need to.  Most  
applications want to identify "users" or "services", but then there  
those odd diagnostic and other applications that will need to  
identify network interfaces, stacks/hosts, nodes, and even perhaps  
individual processes.

Secondly, there are at least two very different "purposes" or  
"intentions" for such identification.  The applications want to  
identify their peer entities for their purposes, which differ  
slightly from application to application.  The networking system, on  
the other hand, want to identify them for the purposes of  
communication or reachability.  The difference may appear subtle but  
is very real can causes great tensions.

Basically, all the app wants is a way of exchanging information with  
the peer; the desired characteristics of the "way", such as security,  
reliability, bandwidth, frequency, etc, differ.  The networking  
system, on the other hand, will need to fulfil this need by knowing  
where the peer entity is, finding a way there, and being able to  
transport the information.  None of which are trivial deeds,  
especially given the current pretty hostile networking environment.

This leads to a desire to have a flexible application-level entity  
space that can encompass all kinds of entities from "users" and  
"services" down to network interfaces, for the purpose of  
_applications_.  Due to the different intentions, we apparently need  
at least two different kinds of name spaces imposed on the top of  
this entity space.  Firstly, we apparently need to have names that  
fulfil application needs, often dealing with human cognitive needs.   
Secondly, we apparently also need names that fulfil the networking  
requirements, including location-independency, security, and  
reachability.

Finally, at this level, it is very important to understand that the  
names that applications use to name low level entities such as stacks/ 
hosts, nodes, and interfaces need not be the same what are used  
inside the networking system.  For example, I could imagine using a  
user level name "Pekka Nikander's MacBook Pro WLAN" for my WLAN  
interface, having a cryptographic public key to denote it in an  
location-independent, secure way for diagnosis applications, while  
the network still internally eventually mapping both of those to the  
MAC address.  Note the consequences of this:  In things likes WLAN  
access control lists I would no longer use MAC addresses but probably  
dual human-friendly--cryptographic names.  I would select "Pekka  
Nikander's MacBook Pro WLAN" in the GUI and the system would  
internally store an identifying cryptographic key.

--

Getting down a level in the discussion, the situation changes.  Now  
we have to consider the realities of the socket API.  There the most  
pressing desire seems to be naming stacks/hosts (abstract entities,  
host != node).  Most people apparently still would like to refer to  
applications by using stack/host names and ports.  I'm fine with  
that, for the time being, while simultaneously considering that as an  
archaic notation.

> For example, with SHIM6, congestion control will be quite difficult  
> (if not impossible) if you try to use SHIM addresses with SCTP. As  
> SCTP calculates congestion control per network path, if the  
> addresses used no long indicate a network path, all bets are off.

That's long been a known problem.  I tried to open discussion about  
that with Randall Stewart and Michael Tüxen back in Vancouver, but at  
time we were unable to find a common standing point.  The base  
solution was later discussed at some point of time in some SHIM6  
meeting (I don't remember where and when): the interface between  
SHIM6 and SCTP must be richer than today.  Basically, you either  
store the ULIDs in the IP header and decorate the packet with the  
locators (external meta data flowing in the stack up and down), or  
vice versa.

> The discussions on this list have pointed out many possibilities of  
> what & how we can identify things, but when I start to look at how  
> some of the potential identifiers map to transport protocols, to  
> processes, to applications, things get a bit messy.

As always :-)

> Does anyone have any pointers on background reading on this issue?

For one, I have never before been able to speak about the  
architecture at the "higher" level of this discussion.  Until  
recently, I couldn't see beyond IP and the per-packet-send-receive &  
hop-by-hop-forwarding paradigms that we rely on.

For the "lower" level, or merely implementing id/loc split while  
retaining most of the current architecture and especially the current  
socket API, there are lots of written-down thoughts in the HIP  
community, including the following:

http://www.ietf.org/rfc/rfc4423.txt
http://www.ietf.org/internet-drafts/draft-ietf-hip-applications-00.txt
http://www.ietf.org/internet-drafts/draft-ietf-hip-native-api-00.txt  
(needs much more work)
http://www.ietf.org/internet-drafts/draft-laganier-ipv6-khi-05.txt

I think there are similar thoughts and documents written for SHIM6,  
but I am not aware of the details.

Unfortunately, I don't know if any of them addresses especially what  
you ask for, but maybe RFC 4423 does in some sense.

--Pekka Nikander

---

From: Jefsey_Morfin <[email-masked]>
Date: Thu, 30 Nov 2006 13:17:24 +0100

>"IPv6 destination address". That, after all is exactly and _only_

I know you did not read my mails, but amen.

>something else entirely, I agree; and I'm open to any suggestions...)

Why do you care?
What have them to do with architecture?

The Internet is a smart end to smart end dumb network. What is beyond 
the edges is not the Internet's cup of tea. What is currently the 
problem is that RFC 3439 accepts as an exception a growingly smart 
routing wich hardly qualify the network core as "dumb". And the 
routing needs to go too smart the way it goes. The only solution is 
to go back to the Internet's basic nature, and to fix the smart core 
routing into a smart edge dumb core routing. Or to come back to a 
situation we know how to manage in decreasing the load on routing in 
decreasing the demand for IP addresses.

This is an architectural decision. The rest is pure engineering.
jfc

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 30 Nov 2006 14:32:52 +0100

> path, if the addresses used no long indicate a network path, all bets

Which is why the shim6 model has to include the option of allowing the
transport layer to switch off the shim.

    Brian

---

From: John Day <[email-masked]>
Date: Thu, 30 Nov 2006 10:51:21 -0500

I believe that a week or so ago a list was created to address the 
problem you describe.  As I understand it, this list was created to 
address the fact that for the past 30 years the Internet has shirked 
its responsibility to do the work necessary to provide a complete and 
well thought out architecture.

As was expressed at the beginning of this discussion a few weeks ago, 
we have to give up this constant band-aid approach.  We have to find 
the *solutions.*  Then we can trade our band-aids in for steps toward 
an answer.

As for transport, yes, we do have a number of bad examples in the data.

---

From: "Bound, Jim" <[email-masked]>
Date: Thu, 30 Nov 2006 11:18:44 -0500

Not to John D. - Note the list is [email-masked] but it is silent should
we all be using that list, can someone here make an exec decision that
we move this discussion to ram?

In response to John D. below:

None of us here believe the band-aid approach is acceptable so I see no
issue at all.

What one may consider a bandaid vs. not-a-bandaid probably will require
some discussion and analysis.  I think we need to get a requirements
analysis done for guidance is my thought for this effort.

Best,
/jim

> Sent: Thursday, November 30, 2006 10:51 AM
> To: Bound, Jim; John Day; John Leslie
> I believe that a week or so ago a list was created to address 
> the problem you describe.  As I understand it, this list was 
> created to address the fact that for the past 30 years the 
> Internet has shirked its responsibility to do the work 
> necessary to provide a complete and well thought out architecture.
> 
> As was expressed at the beginning of this discussion a few 
> weeks ago, we have to give up this constant band-aid 
> approach.  We have to find the *solutions.*  Then we can 
> trade our band-aids in for steps toward an answer.
> 
> >have ever seen for lookups etc., can be made to not be dependent on 
> >IPvN addresses, that will permit aggregation of IPvN 
> addresses for some 
> >time to avoid the collision presented by the IAB at San 
> Diego potentially.
> >>  Not quite.  Sooner or later you are going to realize that  that 
> >> there are no such thing as Transport Addresses.  In  fact, 
> transport 
> >> is sort of a minor layer at best.  As far as  this problem is 
> >> concerned, Transport is irrelevant to the solution.
> >>
> >>  >identifying transport points of the protocols to the  
> architecture 
> >> but  >want to go offline with Pekka N. on that one and can 
> do as I  
> >> can around  >the day job of course.  the reason to do this arch 
> >> exercise is the  >potential of freeing the transport layer 
> from IPvN 
> >> layer and  >components, which affords routing more freedom in 
> >> thinking  models.  but  >to note both
> >>  >>  From: John Leslie [mailto:[email-masked]]  >>  Sent: Wednesday, 
> >> November 29, 2006 4:52 PM  >>  To: Bound, Jim  >>  Cc: 
> >> [email-masked]  >>  Subject: Re: [arch-d] On 
> >> identifiers: what is virtual and
> >>   what is
> >>  >> global (wasRe: thou...
> >>  >>
> address", 
> >> and  >> the  >>"thing" that sits in the IPv6 header as a  
> destination 
> >> address  >> an  >>  >>"IPv6 destination address".
> >>  >>  >>...
> >> TCP  >> >>sockets and connections are _also_ something else  >>
> >>  entirely: we
> >>  >> must not confuse TCP endpoints with IPvN  destination  >>  
> >> >>addresses.)  >>  >  >>  > Two points I do want to note for 
> >> discussion are  >  > what is  >> passed to transport 
> connections are 
> >> end-to-end  identifiers in  > my  >> view and should not 
> be exposed 
> >> in the IPvN headers or used for  >  >> loc+id.
> >>  >>
> >> else  >> as endpoint identifiers. (Clearly, both ends of a TCP  
> >> connection  >> need to agree how to distinguish that a packet  
> >> belongs to that  >>  connection: IPvN addresses have worked OK for 
> >> that purpose.
> >> need  >> not be visible at all to the IPvN layer.)  >>
> >>  >> it'd be fine if, for example, the application  passed FQDNs as 
> >> the  >> endpoint IDs and the operating system did  a 
> DNS-like  query 
> >> to find  >> loc+id.
> >>  >>
> >>  >> and "try" to maintain enough state to alter them back. 
> :*(  >>  
> >> >>  > But if I am no longer using the notion of a current 
> source  >> 
> >> can't  >> even be trusted for that much: the less we 
> depend on  them, 
> >> the  >> better.)  >>
> >> for the  >  >> transport with current architecturs and 
> >> specifications.
> >>  >>
> >>  >> trying to be too many things to too many people. I  
> suspect I'm 
> >> not  >> alone. In any case, both of those are  engineering, not  
> >> architecture;  >> for purposes of this list I  >  > suggest 
> >> explaining which features of them you'd like to  >>  
> compare, rather

---

From: "Bound, Jim" <[email-masked]>
Date: Thu, 30 Nov 2006 11:22:06 -0500

Pekka,

I am not 100% in agreement with your characterizations but I cannot state now what it is I am not comfortable with technically.  But, I am thinking regarding this effort we probably need to identify:

1.  What is valid IETF work.

2.  What is so far out and requires so many models it should be an Internet Research Task Force (IRTF) effort.

3.  Or we need some metric or test case that we do not bottleneck IETF work debating and agonizing over IRTF work.

Best,
/jim 

> From: Pekka Nikander [mailto:[email-masked]] 
> Sent: Thursday, November 30, 2006 4:27 AM
> To: John Loughney
> Subject: Re: [arch-d] Question on what we are identifying
> 
> John,
> 
> identifying 
> > the interface, the stack, the host, the process, the application.
> 
> I think part of the problem is that the current discussion is 
> taking place at least at two different levels, maybe at more. 
>  To me (and I know I'm at least partially wrong), the two 
> levels seem to be roughly as follows:
> 
> 1. Most of the time, John Day, Noel, and I are trying to 
> discuss what would be the "right" long term architecture, 
> simultaneously knowing that there aren't no such thing.  That 
> is, disregard IP, start from the clean slate, what would be 
> the better ways of doing things.  But learning from the 
> existing, including its problems.
> 
> 2. The discussion RJ started, and many other threads, are 
> less ambitious and attempt to "fix" the current architecture 
> by applying some kind of an identifier/locator split.  That 
> is, add a new name space, add a new layer of indirection, or 
> do something else of the same magnitude, which is by no means 
> "small", but pretty much within the current paradigm.
> 
> To me, both of these two discussions are needed.  If we can 
> "fix" the current architecture with something link HIP or 
> SHIM6, that is good since we will get maybe 10-20 years more 
> lifetime for it.  On the other hand, developing a new 
> networking paradigm will take at least 10 years of focused 
> work, and probably much more.  Deploying it will take much 
> longer, if we ever get that far.
> 
> --
> 
> Given that, in the ideal world, the primary things that we 
> want to identify, IMHO, are whatever the applications need 
> to.  Most applications want to identify "users" or 
> "services", but then there those odd diagnostic and other 
> applications that will need to identify network interfaces, 
> stacks/hosts, nodes, and even perhaps individual processes.
> 
> "intentions" for such identification.  The applications want 
> to identify their peer entities for their purposes, which 
> differ slightly from application to application.  The 
> networking system, on the other hand, want to identify them 
> for the purposes of communication or reachability.  The 
> difference may appear subtle but is very real can causes 
> great tensions.
> 
> Basically, all the app wants is a way of exchanging 
> information with the peer; the desired characteristics of the 
> "way", such as security, reliability, bandwidth, frequency, 
> etc, differ.  The networking system, on the other hand, will 
> need to fulfil this need by knowing where the peer entity is, 
> finding a way there, and being able to transport the 
> information.  None of which are trivial deeds, especially 
> given the current pretty hostile networking environment.
> 
> This leads to a desire to have a flexible application-level 
> entity space that can encompass all kinds of entities from 
> "users" and "services" down to network interfaces, for the 
> purpose of _applications_.  Due to the different intentions, 
> we apparently need at least two different kinds of name 
> spaces imposed on the top of this entity space.  Firstly, we 
> apparently need to have names that  
> Secondly, we apparently also need names that fulfil the 
> networking requirements, including location-independency, 
> security, and reachability.
> 
> Finally, at this level, it is very important to understand 
> that the names that applications use to name low level 
> entities such as stacks/ hosts, nodes, and interfaces need 
> not be the same what are used inside the networking system.  
> For example, I could imagine using a user level name "Pekka 
> Nikander's MacBook Pro WLAN" for my WLAN interface, having a 
> cryptographic public key to denote it in an 
> location-independent, secure way for diagnosis applications, 
> while the network still internally eventually mapping both of 
> those to the MAC address.  Note the consequences of this:  In 
> things likes WLAN access control lists I would no longer use 
> MAC addresses but probably dual human-friendly--cryptographic 
> names.  I would select "Pekka Nikander's MacBook Pro WLAN" in 
> the GUI and the system would internally store an identifying 
> cryptographic key.
> 
> --
> 
> Getting down a level in the discussion, the situation 
> changes.  Now we have to consider the realities of the socket 
> API.  There the most pressing desire seems to be naming 
> stacks/hosts (abstract entities, host != node).  Most people 
> apparently still would like to refer to applications by using 
> stack/host names and ports.  I'm fine with that, for the time 
> being, while simultaneously considering that as an archaic notation.
> 
> addresses 
> > used no long indicate a network path, all bets are off.
> 
> That's long been a known problem.  I tried to open discussion 
> about that with Randall Stewart and Michael Tüxen back in 
> Vancouver, but at time we were unable to find a common 
> standing point.  The base solution was later discussed at 
> some point of time in some SHIM6 meeting (I don't remember 
> where and when): the interface between
> SHIM6 and SCTP must be richer than today.  Basically, you 
> either store the ULIDs in the IP header and decorate the 
> packet with the locators (external meta data flowing in the 
> stack up and down), or vice versa.
> 
> recently, I couldn't see beyond IP and the 
> per-packet-send-receive & hop-by-hop-forwarding paradigms 
> that we rely on.
> 
> For the "lower" level, or merely implementing id/loc split 
> while retaining most of the current architecture and 
> especially the current socket API, there are lots of 
> written-down thoughts in the HIP community, including the following:
> 
> I think there are similar thoughts and documents written for 
> SHIM6, but I am not aware of the details.
> 
> Unfortunately, I don't know if any of them addresses 
> especially what you ask for, but maybe RFC 4423 does in some sense.
> 
> --Pekka Nikander
> 
>

---

From: Peter Sherbin <[email-masked]>
Date: Thu, 30 Nov 2006 09:00:58 -0800 (PST)

> Does anyone have any pointers on background reading on this issue?

IMO originally people were concerned on how to get computation done on a circuit.
Then they have combined a few circuits + I/O into a system. The next step was to get
processes in connected systems find each other and talk. This bottom up development
for obvious reasons under thought of the global architecture from microcomputers to
the Milky Way and beyond. IMHO we are blessed with IPv6 breakthrough and a white
board to put such architecture in place.

Thanks,

Peter

 
____________________________________________________________________________________
Cheap talk?
Check out Yahoo! Messenger's low PC-to-Phone call rates.
http://voice.yahoo.com

---

From: "Bound, Jim" <[email-masked]>
Date: Thu, 30 Nov 2006 12:36:06 -0500

John,

To answer your arch transport layer question previously to me, within
the context of this list discussion (leap of faith on my part :--)). 

- Transport protocol end-to-end communications connectivity should
evolve to identifiers and ports not using IPvN addresses.

- Transport identifiers could also be used as IPsec identifiers for the
SPI in conjunction with the IPvN dst address, but the IPvN dst address I
believe must stay in tact as archtype for any new routing architecture
at least at this point in the discussions, thus also for IPsec SPI.

- Transport identifiers need to be cryptographically secure.

- Transport identifiers are not the same as routing identifiers.

- Transport identifiers can be deferenced to find locators as required
for "implementation" of the required stack lookups, interfaces, etc. as
best current practice today for connections between two
applications/processes/services-instance, and used to identify network
path as required by a transport protocol.

NB: shim6 and hip IETF contributors (engineers, operators, architects,
technologists) are well underway to evolve to the above not exactly in
all cases but the bases of such technology evolution is in process.
shim6 appears to have the greatest IETF consensus to move forward at
this time in the IETF having adopted some of the hip architecture and
precepts.  And the devil is in the details as always.

Best,
/jim

---

From: Peter Sherbin <[email-masked]>
Date: Thu, 30 Nov 2006 10:12:33 -0800 (PST)

> Although right after that he refers to it as a route service.
IMO for him both terms bear the same meaning.

> What node hierarchy?

Arrangements inside the node that are independent of and transparent to routing.

> are not multihomed...

OK, science describes via definitions and assumptions. That most systems are not
multihomed is an assumption, where system = node performing an individual task.
Nodes are aggregated in private networks. Most private networks are (or will be)
multihomed.

A question to all: are we ready to start documenting architectural requirements and
assumptions? If yes, by what mechanism?

Thanks,

Peter 

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

---

From: John Day <[email-masked]>
Date: Thu, 30 Nov 2006 13:37:34 -0500

>Arrangements inside the node that are independent of and transparent 

Huh?  Hierarchy within the system?

>Nodes are aggregated in private networks. Most private networks are 

Not quite. That only goes as far as natural history.  Science finds 
the smallest number of concepts that describe the widest range of 
phenomena and from which predictions can be made.

As to your definitions, why set your sights so low?  You are trying 
to make simplifying assumptions before you even know if  it is 
necessary.  As I pointed out last night, this assumption that most 
systems are not multihomed is what got us n this mess to start with. 
Shall we continue it?

>assumptions? If yes, by what mechanism?

I think we need a model.

John

---

From: Geoff Huston <[email-masked]>
Date: Fri, 01 Dec 2006 05:42:49 +1100

At 12:32 AM 1/12/2006, Brian E Carpenter wrote:

>>not impossible) if you try to use SHIM addresses with SCTP. As SCTP 
>>calculates congestion
>>control per network

Well "not to turn it on the first place" for a particular session is perhaps a
better way of phrasing it. And, yes, the SHIM6 effort has thought about SCTP
and thought that it would be prudent for such a transport protocol to signal
via such a mechanism that it does not require, and would not benefit from,
a SHIM6 function further down the stack.

But I suspect with my nitpicking here I've strayed off into the 
undergrowth - sorry!

   Geoff

---

From: "Ian Peter" <[email-masked]>
Date: Fri, 1 Dec 2006 05:44:09 +1100

Assuming that action is required and this is not just an interesting
discussion -

Can someone give a best guesstimate as regards what timeframe the problem is
likely to severly affect Internet performance - are we talking 3 years or 10
or further?

That should help to indicate whether a bandaid approach is absolutely
necessary or whether a more wholistic approach should be concentrated on.

I certainly suggest you avoid trying to do both on the same list (if both
are necessary)

The next step after this preliminary analysis would be to evaluate
realistically what could be done (that’s means implemented, not just a
standard) in the timeframe in which action is needed.

Ian Peter
Ian Peter and Associates Pty Ltd
PO Box 10670 Adelaide St  Brisbane 4000
Australia
Tel (+614) 1966 7772
www.ianpeter.com
www.internetmark2.org
www.nethistory.info

-----Original Message-----
From: John Day [mailto:[email-masked]] 
Sent: 01 December 2006 02:51
To: Bound, Jim; John Day; John Leslie
Cc: [email-masked]
Subject: RE: [arch-d] On identifiers: what is virtual and what is global
(wasRe: thou...

At 3:38 -0500 2006/11/30, Bound, Jim wrote:
>>  architecture but
>>  >>     This is indeed a mess right now. NAT boxes routinely
>>  alter  thFrom [email-masked] Thu Nov 30 13:49:37 2006
Date: Fri, 01 Dec 2006 05:42:49 +1100
To: Brian E Carpenter <[email-masked]>, [email-masked]
From: Geoff Huston <[email-masked]>
Subject: Re: [arch-d] Question on what we are identifying
Cc: [email-masked]

   Geoff

---

From: John Day <[email-masked]>
Date: Thu, 30 Nov 2006 13:56:51 -0500

>evolve to identifiers and ports not using IPvN addresses.

We need to be careful here.  I have been thinking about this *a lot* 
and you are on the right track. And I realize that you are using the 
nomenclature you know.  But there are considerable benefits that 
accrue if the identifiers you speak of are not associated with the 
protocols we normally associate with the "Transport protocols."  The 
only identifiers they need and should have are the 
connection-identifier, i.e. source and destination port-ids they have 
now.

---

From: John Leslie <[email-masked]>
Date: Thu, 30 Nov 2006 14:32:29 -0500

> Nor should any transport protocol,

   That doesn't follow. Quoting an authority you should respect:
" 
" [A layer] 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.

   Surely one should allow "identifiers internal to" such a distributed
application.

> None that I know of do the latter.  O, yes, SCTP tries to but how? 

   "How" is engineering -- for this discussion it's sufficient to
say it _does_ choose among multiple paths.

   It's hardly surprising that we have spent most of the history of
the Internet choosing one "best" path: anything else leads to stability
problems in cases we have _already_ encountered. (We have, of course,
used "bonding" to make "best" paths which use more than one physical
medium.)

> multiplexing functions well.  It really is in no position to do it.

   Umm...

   SCTP would do just fine at choosing amrng multiple paths (AKA
multiplexing) if it had a stable enough base to build on.

   BTW, SCTP is in the ideal position to do multiplexing, IMHO.

> Transport, well, that class of protocols.

   You prove my point about "transport" meaning different things to
differerent people.

> and flow control on a single flow.

   I find it strange you want to divorce error control from your list.

   "Flow control" is complex enough that I suspect we'll need cooperation
among several layers.

   The rest of your list, IMHO, would benefit greatly from stability
of an internetworking layer to build on.

> you don't do it right, it won't work."  ;-)

   (I wonder if it would help if _you_ tried to avoid the name
"transport" for the layer you're talking about. I'd be happy to adopt
a different name for mine...)

---

From: Geoff Huston <[email-masked]>
Date: Fri, 01 Dec 2006 07:07:36 +1100

>   My personal view of SHIM6 is that it is

My personal view is that there is a significant difference between  a 
host-level approach and a transport session level approach that you 
seem to have missed in your note.  I find myself in  strong 
disagreement with your perspective of SHIM6 as some kind of diluted 
or  compromised version of HIP.

Frankly, as the volume, if not the usefulness, of all postings to 
this list demonstrates, there is much involved here. To expect any 
particular approach to get it all right first time is asking too 
much. HIP and SHIM6 are examples of trying to understand what these 
concepts look like in code and in protocol stacks. They bed down 
these otherwise abstract discussions with some experience with 
implementation and the harsh realities of deployment in the network. 
For you that may well be band aid. For me its part of the scientific 
investigatory process of devising an hypothesis, and then testing 
this hypothesis, and then looking very hard to make sure that the 
hypothesis remains intact. As far as I can see, we (or at least 'I' 
at any rate - the rest of you may know all there is to know about 
this subject already! :-) :-) :-) ) still have much to learn here.

Geoff

---

From: Andrew McGregor <[email-masked]>
Date: Fri, 1 Dec 2006 10:51:29 +1300

It may not be clear now, given that HIP is *called* the 'Host  
Identity Protocol', but there's actually nothing in the protocol  
itself to say what the identities in question belong to.  In that  
sense there's little difference between HIP and SHIM6 in terms of  
architecture; lots of differences in detail, and some striking and  
deliberate similarities.

In other words, what HIP and SHIM6 both give you is the ability to  
assert that something accessible at location A is also accessible at  
locations B through F, prove the assertion, and request changes in  
the delivery of packets.  There are differences in what assertions  
you can make at what stage of the process, what you have to know a  
priori, what events can be dealt with as they occur, what you want to  
put in the DNS, how much security you get, and in how much math you  
have to do to make assertions, but the core of what the protocols  
provide is very similar.

Andrew

On 01/12/2006, at 9:07 AM, Geoff Huston wrote:

> My personal view is that there is a significant difference between   
> a host-level approach and a transport session level approach that  
> you seem to have missed in your note.  I find myself in  strong  
> implementation and the harsh realities of deployment in the  
> network. For you that may well be band aid. For me its part of the  
> scientific investigatory process of devising an hypothesis, and  
> then testing this hypothesis, and then looking very hard to make  
> sure that the hypothesis remains intact. As far as I can see, we  
> (or at least 'I' at any rate - the rest of you may know all there  
> is to know about this subject already! :-) :-) :-) ) still have  
> much to learn here.
>
> Geoff
>
>
>

---

From: David Meyer <[email-masked]>
Date: Thu, 30 Nov 2006 16:13:40 -0800

> we move this discussion to ram?

	Sure, go ahead :-) But really, is anything more needed,
	other than to provide some context over there for folks
	not reading this list? And BTW, Fred (Baker) pointed the
	v6ops over to that list today as well.

	--dmm

---

From: "Bound, Jim" <[email-masked]>
Date: Thu, 30 Nov 2006 22:55:53 -0500

> And I realize that 
> you are using the nomenclature you know. 

Elitist and insulting please don't do that again.  Thank You.  We can
talk offline not the first time by you to me.

I prefer end-point identifiters instead of connection-identifiers.  But
key is they are not routing identifiers for now.

/jim

> Sent: Thursday, November 30, 2006 1:57 PM
> Subject: Re: [arch-d] transport layer identifier evolutiion 
> to support multihoming
> 
> We need to be careful here.  I have been thinking about this 
> *a lot* and you are on the right track. And I realize that 
> you are using the nomenclature you know.  But there are 
> considerable benefits that accrue if the identifiers you 
> speak of are not associated with the protocols we normally 
> associate with the "Transport protocols."  The only 
> identifiers they need and should have are the 
> connection-identifier, i.e. source and destination port-ids 
> they have now.
> 
> >
> >SPI in conjunction with the IPvN dst address, but the IPvN 
> dst address 
> >I believe must stay in tact as archtype for any new routing 
> >architecture at least at this point in the discussions, thus 
> also for IPsec SPI.
> >

---

From: "Bound, Jim" <[email-masked]>
Date: Thu, 30 Nov 2006 23:09:04 -0500

I could go on about this knowing both well.  But if we are to keep this
as architecture dsicussion we probably only need to know the arch diffs
of shim6 and hip. would that be useful?  I am not sure?  shim6 is not a
watered down HIP that is not a valid premise at least to me for the
deductions we are or may not be trying to achieve, or it might be using
inductive processes is better.  Figure out what end state we want and
work backwards from what certain proposals suggest to be clear.

/jim

> From: Andrew McGregor [mailto:[email-masked]] 
> Sent: Thursday, November 30, 2006 4:51 PM
> To: Geoff Huston
> Cc: Pekka Nikander; [email-masked]
> Subject: Re: [arch-d] Some notes about HIP and SHIM6 (was Re: 
> On identifiers:what is virtual and what...)
> 
> Identity Protocol', but there's actually nothing in the 
> protocol itself to say what the identities in question belong 
> to.  In that sense there's little difference between HIP and 
> SHIM6 in terms of architecture; lots of differences in 
> detail, and some striking and deliberate similarities.
> 
> In other words, what HIP and SHIM6 both give you is the 
> ability to assert that something accessible at location A is 
> also accessible at locations B through F, prove the 
> assertion, and request changes in the delivery of packets.  
> There are differences in what assertions you can make at what 
> stage of the process, what you have to know a priori, what 
> events can be dealt with as they occur, what you want to put 
> in the DNS, how much security you get, and in how much math 
> you have to do to make assertions, but the core of what the 
> protocols provide is very similar.
> 
> Andrew
> 
> >>   My personal view of SHIM6 is that it is a kind-of watered-down 
> >> version of HIP, officially trying to achieve clearly less than HIP 
> >> but at the same time unofficially crawling towards the directions 
> >> where HIP has already boldly gone.  :-)  Not bad given the 
> committee 
> >> design.
> >
> > a host-level approach and a transport session level 
> approach that you 
> > disagreement with your perspective of SHIM6 as some kind of 
> diluted or  
> > compromised version of HIP.
> >
> > Frankly, as the volume, if not the usefulness, of all 
> postings to this 
> > list demonstrates, there is much involved here. To expect any 
> > particular approach to get it all right first time is 
> asking too much. 
> > HIP and SHIM6 are examples of trying to understand what 
> these concepts 
> > look like in code and in protocol stacks. They bed down these 
> > otherwise abstract discussions with some experience with 
> network. 
> > investigatory process of devising an hypothesis, and then 
> testing this 
> > hypothesis, and then looking very hard to make sure that the 
> > hypothesis remains intact. As far as I can see, we (or at 
> least 'I' at 
> > any rate - the rest of you may know all there is to know about this 
> > subject already! :-) :-) :-) ) still have much to learn here.
> >
> > Geoff
> >
> >
> >

---

From: "Bound, Jim" <[email-masked]>
Date: Thu, 30 Nov 2006 23:09:31 -0500

ACK.
/jim 

> From: David Meyer [mailto:[email-masked]] 
> Sent: Thursday, November 30, 2006 7:14 PM
> To: Bound, Jim
> Cc: [email-masked]; John Day
> what is global(wasRe: thou...
>

---

From: John Day <[email-masked]>
Date: Thu, 30 Nov 2006 23:27:42 -0500

>key is they are not routing identifiers for now.

Jim, I am terrible sorry if you were offended by my choice of 
language.  It was not intended as elitist or insulting in the least. 
I think you are reading far too much into it.

I have worked (and am working) in more than one of terminology with 
respect to this work.  And I was merely recognizing that.  There was 
no value judgement in it whatsoever.  As for preferring to call them 
endpoint identifiers.  If you look at how the use of source and 
destination port-ids arise in this class of protocols, i.e. not only 
transport but also data link.  (They are basically the same thing.)

Working from first principles (consider just two machines trying to 
communicate), you find that the reason they first appear is to 
distinguish multiple flows on the line.  Since either end may 
initiate a connection, it is not feasible for just one end to assign 
the connection-id.  If they did, there would always be the chance of 
collisions.  Since both sides already had a port-id that their local 
IPC was using to distinguish the flow locally.  The convention has 
been to concatenate them as the connection-id.

So the reason, I refer to the field as a connection-id is that is its 
function in the protocol.  Each port-id can be seen as a 
local-identifier of an endpoint.

Does that explain it?

Take care,
John

Again, sorry.  I have no elitist intentions and not an elitist bone in my body!