Subject: Re: [arch-d] Some notes about HIP and SHIM6 (was Re: On identifiers: what is virtual and what...)

From: [email-masked] (Noel Chiappa)
Date: Fri, 1 Dec 2006 12:37:50 -0500 (EST)

[Sorry this is a bit out of order, it's been sitting in my editor buffer,
waiting till I had time to complete it. I think the point about NAT's is
still very apt.]

    > From: Pekka Nikander <[email-masked]>

    > the purpose of HIP is to establish a new, cryptographic name space into
    > the stack ..
    > .. 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.

Absolutely. Anytime you're adding a general-purpose namespace (and bindings
thereto), that's definitely architectural. Another way to tell it's
architectural is that it's not intended to support just a single feature
(e.g. mobility or multi-homing); rather, it provides a very general,
fundamental capability that lots of different things can be built upon.

    > somewhere between the internetworking and transport layers.

And that's an interesting choice, given the previous discussion here. It
really does name a "stack" (whatever that means :-). Not perhaps the best
choice, given a blank slate, but when you're constrained to be modifying an
existing architecture, sometimes you have to take what you can get.

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

Well, sometimes you don't have any choice...

    > better-engineered NAT traversal

Oh Lord, there's something we really need, too. NAT's are going to be with us
a long time, and anything we can do to make crossing them less kludged is a
Really Good Thing. Too bad this goal has received so little attention...

And no, "just get rid of all the NAT boxes" is NOT a viable strategy for
dealing with them - as people keep pointing out, they are so incredibly
popular because they are the only things out there that meet a *variety* of
real needs, most of which we aren't really meeting yet, even with our latest
designs.

Expanding on this a bit, I see HIP as potentially part of an alternative
strategy for how to evolve a large, in-service architecture. I am frankly
dubious about fork-lift upgrades, where one replaces an entire layer with
something else. I think a much better strategy is a "piece-by-piece" one,
where one tries to deploy some (hopefully well-architected) new pieces that,
while each stands on its own, both in terms of functionality to give you some
new capability, as well as cost/benefit, *together* add up to a coherent new
whole.

(By "well-architected" I mean in the sense that "the measure of a good
architecture is not how well it does the things you knew up front you wanted
it to do, but how well it does the things you never had any idea it would be
called on to do", as one of my favourite aphorisms goes.)

Yes, such things will always be a bit of a "bag on the side", but if
well-done, they can be a piece of a better replacement. E.g. if we get HIP
widely deployed, it will slowly leach the "end-end naming" part of IPvN
addresses off to a new namespace, and that will make NAT box traversal (which
is where I started this thought) much easier. At that point, it's feasible to
e.g. start trying to morph IPv4 addresses into scope-local forwarding tags,
with yet another new namespace being used for end-end routing-names, and
routing stuff.

This leads to my most far-reaching (grandiose? :-) vision, in which the new
routing-names I mentioned above would be part of a replacement internework
layer (eventually totally obsoleting IPv4 addresses). I view MPLS, currently
yet-another Bag-on-the-Side (BotS), as something that could be integrated
into that new internetwork layer, one that (among many other new
capabilities) recognizes and can manipulate traffic aggregates, and make
better use of the current actual fabric (e.g. lamda-switching).

But it's going to be a long road, with many smaller paving-stones to be put
down, before that happens.

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

Only if one doesn't actively consider them as part of a larger picture, as I
did above.

I don't see them as that closely equivalent, mind, because HIP does introduce
a new namespace, and that can be a key piece of an "architecture evolution"
plan.

    > I consider it more likely that the results the NSF and FP7 funded
    > research will mature before the IETF community gets to the stage

I'm dubious about these academic projects really producing something that is,
in itself, viable as a replacement. The issues of interoperability, and the
cost/benefit issues that drive the success of things in the Real World, have
to be factored in at a higher level that research efforts (which really have
different goals) are really able to do.

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

Well, exactly how drastic the lower-layer redoing will be is still open; it
hasn't really gotten a lot of thought. Even attempts to, e.g., deploy a
second copy of IPv6 (to allow reuse of existing hardware/code) below an
end-end IPv6 turn out to be pretty difficult, though.

    > Again, I am not too hopeful about the IETF community ever getting there.

Well, we'll see. Things are heading for trouble, and if the IETF can't get
with it, the affected parties (e.g. ISP's) will simply find some other forum
in which to tackle the problem.

	Noel

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

---

From: "Bound, Jim" <[email-masked]>
Date: Sun, 3 Dec 2006 18:22:33 -0500

Agree with all of Noels points and thoughts in this thread response and
for NAT we might want to look at the NAP work in v6ops as suggestion in
process now.  But the below I want to stress again.

> I'm dubious about these academic projects really producing 
> something that is, in itself, viable as a replacement. The 
> issues of interoperability, and the cost/benefit issues that 
> drive the success of things in the Real World, have to be 
> factored in at a higher level that research efforts (which 
> really have different goals) are really able to do.

I feel the same way.  I have to track this work and have come to the
same conclusion.
Well stated.

> Well, exactly how drastic the lower-layer redoing will be is 
> still open; it hasn't really gotten a lot of thought. Even 
> attempts to, e.g., deploy a second copy of IPv6 (to allow 
> reuse of existing hardware/code) below an end-end IPv6 turn 
> out to be pretty difficult, though.
> 
> Well, we'll see. Things are heading for trouble, and if the 
> IETF can't get with it, the affected parties (e.g. ISP's) 
> will simply find some other forum in which to tackle the problem.

I fully agree and very healthy warning to us IMHO.  I am tracking the
work in IPsphere, DARPA projects, EU research projects, etc.  If we do
not solve the essential problem of routing for billions of devices and
sensors, and being seamless mobile (meaning their location changes in
relation to provider prefix space) over some "core" Internet (not
Intranet) network model it will be taken out of the IETF hands. I will
not venture to postulate how but the market will find a way to not melt
down.

/jim

/jim

830); 
	Sun, 3 Dec 2006 18:23:16 -0500
Content-class: urn:content-classes:message
Subject: RE: [arch-d] Some notes about HIP and SHIM6 (was Re: On
	identifiers:what is virtual and what...)
Date: Sun, 3 Dec 2006 18:22:33 -0500
From: "Bound, Jim" <[email-masked]>
To: "Noel Chiappa" <[email-masked]>, <[email-masked]>
Cc: 

Agree with all of Noels points and thoughts in this thread response and
for NAT we might want to look at the NAP work in v6ops as suggestion in
process now.  But the below I want to stress again.

> I'm dubious about these academic projects really producing 
> something that is, in itself, viable as a replacement. The 
> issues of interoperability, and the cost/benefit issues that 
> drive the success of things in the Real World, have to be 
> factored in at a higher level that research efforts (which 
> really have different goals) are really able to do.

I feel the same way.  I have to track this work and have come to the
same conclusion.
Well stated.

> Well, exactly how drastic the lower-layer redoing will be is 
> still open; it hasn't really gotten a lot of thought. Even 
> attempts to, e.g., deploy a second copy of IPv6 (to allow 
> reuse of existing hardware/code) below an end-end IPv6 turn 
> out to be pretty difficult, though.
> 
> Well, we'll see. Things are heading for trouble, and if the 
> IETF can't get with it, the affected parties (e.g. ISP's) 
> will simply find some other forum in which to tackle the problem.

I fully agree and very healthy warning to us IMHO.  I am tracking the
work in IPsphere, DARPA projects, EU research projects, etc.  If we do
not solve the essential problem of routing for billions of devices and
sensors, and being seamless mobile (meaning their location changes in
relation to provider prefix space) over some "core" Internet (not
Intranet) network model it will be taken out of the IETF hands. I will
not venture to postulate how but the market will find a way to not melt
down.

/jim

/jim

830); 
	Sun, 3 Dec 2006 18:23:16 -0500
Content-class: urn:content-classes:message
Subject: RE: [arch-d] Some notes about HIP and SHIM6 (was Re: On
	identifiers:what is virtual and what...)
Date: Sun, 3 Dec 2006 18:22:33 -0500
From: "Bound, Jim" <[email-masked]>
To: "Noel Chiappa" <[email-masked]>, <[email-masked]>
Cc: 

Agree with all of Noels points and thoughts in this thread response and
for NAT we might want to look at the NAP work in v6ops as suggestion in
process now.  But the below I want to stress again.

> I'm dubious about these academic projects really producing 
> something that is, in itself, viable as a replacement. The 
> issues of interoperability, and the cost/benefit issues that 
> drive the success of things in the Real World, have to be 
> factored in at a higher level that research efforts (which 
> really have different goals) are really able to do.

I feel the same way.  I have to track this work and have come to the
same conclusion.
Well stated.

> Well, exactly how drastic the lower-layer redoing will be is 
> still open; it hasn't really gotten a lot of thought. Even 
> attempts to, e.g., deploy a second copy of IPv6 (to allow 
> reuse of existing hardware/code) below an end-end IPv6 turn 
> out to be pretty difficult, though.
> 
> Well, we'll see. Things are heading for trouble, and if the 
> IETF can't get with it, the affected parties (e.g. ISP's) 
> will simply find some other forum in which to tackle the problem.

I fully agree and very healthy warning to us IMHO.  I am tracking the
work in IPsphere, DARPA projects, EU research projects, etc.  If we do
not solve the essential problem of routing for billions of devices and
sensors, and being seamless mobile (meaning their location changes in
relation to provider prefix space) over some "core" Internet (not
Intranet) network model it will be taken out of the IETF hands. I will
not venture to postulate how but the market will find a way to not melt
down.

/jim

/jim