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

From: [email-masked]
Date: Fri, 24 Nov 2006 04:03:17 EST

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

H.H: Well, that is a matter of how you deal/handle/operate/manipulate  with 
the 16-Byte-sized entity. By choosing a sub-structure which is capable to  
support routing then I think something is accomplished.
IMHO prefix block building is the most minimal support as it tries to make  
the routing task doable. But beyond that it does not support routing at  all.
 
And the same is true with respect to addressing=identifying : Look E164 is  
done via DNS which is fine for the moment. But if you go for the profound  
redesign then that should not be necessary anymore, should it?
 
Heiner

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

This is what we're trying to  avoid.

Rgds,
-drc

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

---

From: David Conrad <[email-masked]>
Date: Sun, 26 Nov 2006 01:08:28 -0800

Heiner,

On Nov 24, 2006, at 1:03 AM, [email-masked] wrote:
> H.H: Well, that is a matter of how you deal/handle/operate/ 
> manipulate with the 16-Byte-sized entity. By choosing a sub- 
> structure which is capable to support routing then I think  
> something is accomplished.

In theory, I would agree.  16 bytes is an insane amount of address  
space and you should be able to shoehorn sufficient location  
information into the high order bits (particularly given the RIRs are  
allocating /32s to their customers).

However, in reality, since IPv6 made the same mistake IPv4 did by  
including the entire IP address in the pseudo-header checksum, if you  
include location with identity information in the "address", you get  
the following choices:

1) don't ever change providers
2) renumber when you change providers
3) modify every deployed end point TCP/IP stack that will be part of  
the communication such that it won't look at the high order bits of  
the "address" that contain the location information.

1 & 2 won't fly according to every large scale enterprise network  
operator I've ever spoken to.

If you're going to go around mucking about with deployed end point  
TCP/IP stacks, then it would probably make more sense to go back to  
the drawing board and come up with IPv7 (IMHO).

> And the same is true with respect to addressing=identifying : Look  
> E164 is done via DNS which is fine for the moment.

Not exactly sure what you mean here.  ENUM hasn't really been a  
rousing success and it merely provides a way of using the DNS to  
translate one name (E.164 strings) into another name (the target DNS  
names).

> But if you go for the profound redesign then that should not be  
> necessary anymore, should it?

I'm arguing that we don't really have the luxury to do a profound  
redesign.  I believe the best we can pragmatically do at this stage  
is to make a clear distinction between identifier and locator by  
providing an indirection mapping.  At the very least, this would  
allow us to redeploy a routing layer without impacting end users/ 
applications that only know about identifiers.

Rgds,
-drc

---

From: "Bound, Jim" <[email-masked]>
Date: Mon, 27 Nov 2006 10:18:23 -0500

Just on this point:

> If you're going to go around mucking about with deployed end 
> point TCP/IP stacks, then it would probably make more sense 
> to go back to the drawing board and come up with IPv7 (IMHO).

I don't agree.  There can be a transition and it can be done
transparently as will any significant change from this effort.  shim6 is
very friendly to such a transition as one data point.  

But more importantly the identifier architecture in shim6 is approaching
the use of identifiers far different than for routing.

We need to define crisply what we want from an identifier for routing
and how it works with routing and if it is to be global.  

Also this only addresses the multihoming problem and the question is if
that is addressed in this manner per the IAB Report does this buy us
more time to work on the routing?

/jim

---

From: "Bound, Jim" <[email-masked]>
Date: Mon, 27 Nov 2006 10:59:26 -0500

I have no idea what your input is at all I think we agree on the mission
though. But shim6 is not a kludge if that is what you meant?

Best,
/jim 

> -----Original Message-----
> From: John Day [mailto:[email-masked]] 
> Sent: Monday, November 27, 2006 10:53 AM
> To: Bound, Jim; David Conrad; [email-masked]
> Cc: [email-masked]
> Subject: RE: [arch-d] On identifiers: what is virtual and 
> what is global (wasRe: thou...
> 
> We have had 20 years to get it right and frankly we have 
> avoided working on the problem.  To a large extent we have 
> allowed superficial success, i.e. success in the market and 
> the popular press, to be confused as good science.  They 
> aren't the same thing at all.  It is interesting that most of 
> us would not consider DOS a good OS even though it was wildly 
> successful in the market place, but we accept that measure 
> for what we have created.
> 
> This thing can't go on indefinitely as a collection of 
> band-aids on an unfinished demo.  It is far too important for 
> that.  We have to get a good idea what the end state should 
> look like and then and only then begin to consider 
> incremental steps that will take us there. 
> This is arch-d.  Let us do what we know needs to be done and 
> leave the band-aids and kludges to their proper place: on ark b.
> 
> Take care,
> John
> 
> 
> At 10:18 -0500 2006/11/27, Bound, Jim wrote:
> >Just on this point:
> >
> >transparently as will any significant change from this 
> effort.  shim6 
> >is very friendly to such a transition as one data point.
> >
> >But more importantly the identifier architecture in shim6 is 
> >approaching the use of identifiers far different than for routing.
> >

---

From: John Day <[email-masked]>
Date: Mon, 27 Nov 2006 10:52:44 -0500

We have had 20 years to get it right and frankly we have avoided 
working on the problem.  To a large extent we have allowed 
superficial success, i.e. success in the market and the popular 
press, to be confused as good science.  They aren't the same thing at 
all.  It is interesting that most of us would not consider DOS a good 
OS even though it was wildly successful in the market place, but we 
accept that measure for what we have created.

This thing can't go on indefinitely as a collection of band-aids on 
an unfinished demo.  It is far too important for that.  We have to 
get a good idea what the end state should look like and then and only 
then begin to consider incremental steps that will take us there. 
This is arch-d.  Let us do what we know needs to be done and leave 
the band-aids and kludges to their proper place: on ark b.

Take care,
John

---

From: Pekka Nikander <[email-masked]>
Date: Tue, 28 Nov 2006 11:33:22 +0200

Then Jim Bound wrote:
>> approaching

As an answer, John Day wrote:
> working on the problem.

---

As I stated in towards the very beginning of this discussion,  
apparently we need both long term and shorter term approaches.  It  
looks like that we'll need to work on them in parallel, for number of  
years.

Then, again, we have three "things" (assets) that can be and should  
be each changed individually; their natural life cycles differ:

1. Applications.  It takes a long time to update all apps (or even  
most) to use a new API.  Many popular, developing apps change fast,  
though.

2. OS stacks.  Most of them are replaced every 3-5 years.

3. Routers.  I have no real idea about life cycles.

Our experience (from IPv6) seems to show that trying to change them  
all at once is, well, problematic.  Now that we have IPv6 there in  
the routers and in the APIs for many apps, IMHO we should try to  
leverage that, even though such changes might be classified as  
kludges from the architectural point of view.

In other words, changes that change only one of the three instead of  
them all seem to be easier to deploy, taking less time.

What I understand less well is that there seems to be also other  
factors.  Both SHIM6 and HIP attempt to change only the OS stack.   
However, SHIM6 seems to be much easier for most people to swallow,  
perhaps because it is felt as a "smaller" change.  OTOH, if you  
compare SHIM6 and HIP using the number of lines needed to implement,  
the difference is pretty small.

--Pekka Nikander