Subject: RE: [arch-d] Mobility and multi-homing: Summary and going forward

From: [email-masked]
Date: Fri, 11 Nov 2005 07:40:04 +0200

Hi William,

>> I actually would like to see Applicability Statements for HIP, 
>> MIP(v4/v6), MONAMI, SHIM6, mSCTP, NETLMM, etc.
>>
>> I actually think that we need to do a bit of thinking of how each 
>> piece might live within the Internet, how you perform address 
>> selection when an application wants to get a new IP address (does it 
>> use the HIP or MIP stack on it), etc. etc.
>
>Particularly interesting would be diagram of how all the above 
>can (or can not) work together; and if some of them can not be 
>used together explanation as to why not and which of the 
>technologies are exclusive of the other ones.

That's kind of what I was getting at.  Depending upon what is needed,
one could see making a socket (or socket-like) call that would start
'simple' IP, MIP, HIP, whatever ... and understanding which type of
IP 'service' you wanted.  That's why I somewhat think this could be
considered an address selection issue - do you want a MIP address,
HIP address, SHIM address ... Life with IPv6 already brings this up,
as a 1-to-1 relationship IP address to an interface doesn't hold.

>P.S. Personally I think we need to evaluate ASAP if we really 
>need another layer in between IP and TCP/UDP and if it is 
>needed then design it in appropriate way with "base" layer 
>protocol and additional specification that use this layer 
>(instead of designing several protocols that each introduce 
>new layers "close" to each other).

At the shim6 meeting in Paris, Christian Huitema pointed out that
while we like to think that TCP & IP are separate layers, that's
not how people implement them.  I think that any 'layer' between
transport & IP might be a separate layer on paper, but won't be
in implementation.

John

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

---

From: Geoff Huston <[email-masked]>
Date: Fri, 11 Nov 2005 16:52:35 +1100

>transport & IP might be a separate layer on paper, but won't be

well ... yes and no. When you talk about the design of algorithms and 
associated protocols, then our tools to transform the space to conceptually 
manageable proportions typically rely on partitioning - and in this case 
the layered protocol model serves as a useful partitioning tool in terms of 
where and how data structures are organized and where and how the 
procedures that work off these data structures are organised. From this 
perspective there are certain obvious differences between the data 
structures associated with a transport session and those associated with 
the IP layer, for example.

  From my perspective I would see the interactions with a stack as more 
akin to a vertical API conceptualization, again as an abstraction to help 
partition the overall space in a productive manner. Of course, yes these 
are conceptual models rather than implementation imperatives. But at times 
seeing the entire space without this form of conceptual structure just gets 
overwhemlingly confusing  - at least it does for me!

   Geoff

---

From: David Barak <[email-masked]>
Date: Fri, 11 Nov 2005 03:48:30 -0800 (PST)

--- [email-masked] wrote:

> not how people implement them.  

I don't think I agree with this statement: there are a
lot of protocols which ride on IP and not TCP, and the
implementations don't have any "secret" TCP in the
mix.  Perhaps what he meant to say is that nobody
implements TCP without IP - that's correct, but the
converse isn't.

> I think that any
> 'layer' between

If there was a benefit to the existence of the layer,
you can reasonably expect that people will find a way
to use it.  However, it would need to really BE a
discrete layer: one of the big problems (IMO) with
IPv6 is the lack of respect for layer boundaries. 

David Barak
Need Geek Rock?  Try The Franchise: 
http://www.listentothefranchise.com

__________________________________ 
Yahoo! FareChase: Search multiple travel sites in one click.
http://farechase.yahoo.com

---

From: "william(at)elan.net" <[email-masked]>
Date: Fri, 11 Nov 2005 04:17:16 -0800 (PST)

On Fri, 11 Nov 2005, David Barak wrote:

>> I think that any 'layer' between transport & IP might be a separate 
>> layer on paper,  but won't be in implementation.

That really does not matter. If they have device that only does HTTP
they may well implement both TCP/IP & HTTP in one unified code (in
fact some people did if I'm not mistaken).

> to use it. However, it would need to really BE a discrete layer:

So what you're saying is that for adding new layer (as opposed to
modifications or additional to either IP or TCP), there needs to
be application that relies exclusively on this layer and builds up
on top of it (i.e. OSPF vs BGP). This is a fair view and perhaps
we need to look at how MIP, HIP, SHIM, etc feet into it.

However even if separate application using layer is not immediatly
found, layer-like separation may be still be good to have so new layer 
could be used very differently (or entirely bypassed) by upper layers
in certain cases, for example I have still have hard time imagining how 
shim6 or hip could/would be used with multicasting.

> one of the big problems (IMO) with

How so? What in IPv6 makes it so different layer-wise compared to IPv4?

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: David Barak <[email-masked]>
Date: Fri, 11 Nov 2005 06:32:36 -0800 (PST)

> layer-wise compared to IPv4?

The whole reason for a /64 being a "host" address is
to incorporate MAC information into the IPv6 address:
that bridges L2 and L3.  IPv6 has absorbed several
other protocols (DHCP, IPSec, GRE) in an attempt to be
all things to all people.  

The whole Shim6 discussion boils down to using
host-based rather than network-based failover
mechanisa, and so a useful scaling property of the
current Internet is lost (that hosts don't need
routing information).

I've long believed that strict separation of functions
leads to greater long-term stability and flexibility -
I'd like to be able to slip IPv6 into the protocol
stack instead of v4, and still run the same
upper-level stuff over it (that IS the layered model,
after all...)

David Barak

__________________________________ 
Start your day with Yahoo! - Make it your home page! 
http://www.yahoo.com/r/hs

---

From: Geoff Huston <[email-masked]>
Date: Sat, 12 Nov 2005 03:02:09 +1100

>current Internet is lost (that hosts don't need

I have to make the comment that this is not  the case - shim6 exploits 
multiple router advertisements with multiple prefixes in order to gain host 
knowledge of available address prefixes, but does not rely on the 
propagation of routing information to individual hosts. I 'd gently suggest 
that you may want to read through the shim6 working drafts before advancing 
such perspectives on this particular approach to multi-homing and the more 
general area of  advancing identity / locator semantic distinctions.

regards,

     Geoff

---

From: David Barak <[email-masked]>
Date: Sat, 12 Nov 2005 17:53:28 -0800 (PST)

> general area of  advancing identity / locator

I re-read the drafts, and while "routing information"
was not the proper choice of words, I stand by my
assertion that Shim6 is a host-based, rather than
network-based, failover mechanism.  State information
is maintained in a host to address network failures,
rather than these events being transparent to the
hosts, as they are currently.  

>From draft-ietf-shim6-applicability-00:
"State information relating to the multi-homing of two
endpoints exchanging unicast traffic is retained on
the endpoints themselves, rather than in the network."

In fact, looking at RFC 4177, pretty much all of the
multi-homing options other than "routing" imply that
hosts must maintain a significant amount of
information about network state.  That these
approaches are more complex (for the host) than the
current approaches is indisputable.  Whether or not
this complexity is worth it is a matter of opinion.  

I would assert that locational information belongs at
layer 3 (and to a lesser/more limited extent, below
that), while identity information should belong to
higher layers.  

My original complaint was that too many functions were
being crammed into IPv6, and that the benefits of the
layered approach were being lost.  

-David Barak-
-Fully RFC 1925 Compliant-

---

From: Geoff Huston <[email-masked]>
Date: Sun, 13 Nov 2005 14:41:34 +1100

At 12:53 PM 13/11/2005, David Barak wrote:

>network-based, failover mechanism.

Absolutely!  That's they way it was designed, coincidentally. :-)

Regards,

   Geoff

---

From: "william(at)elan.net" <[email-masked]>
Date: Sat, 12 Nov 2005 20:10:42 -0800 (PST)

> Absolutely!  That's they way it was designed, coincidentally. :-)

Trouble is that IPv6 most interesting feature is that it can provide
for large number of internet-connected hosts, that means number of
hosts would increase quite a bit and so per-host multi-homing ends
up being quite expensive to maintain. If any such type of multi-homing
is to exist and be widely used (especially in enterprise and businesses)
it would have to allow for easy network-wide setup & configuration
and without a need to renumber when you change providers.

So, I see the result of current effort is that those businesses would
not actually do per-host multi-homing [even though that is what protocol
would specify] but would use intermediate gateway device. All local
hosts on their network instead of having global ipv6 address would use
some type of shim6 host id and this network device would translate
between those host ids and real IPv6 addresses as well as maintain
proper dns configuration for such lan. Unless I'm mistaken such
setup is called NAT! So the result is that you'd now have special
protocol that would allow to use NAT not only for outgoing traffic
load-balancing (current NAT gateways can already translate into more
then one address pool) but also for incoming traffic multi-homing.

So if you want to introduce and greatly increase use of NAT in IPv6
(as compared to IPv4), please by all means continue with shim6!

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: "william(at)elan.net" <[email-masked]>
Date: Sat, 12 Nov 2005 20:24:52 -0800 (PST)

> (as compared to IPv4), please by all means continue with shim6!

BTW - I'm not at all saying such shim6 multi-homed NATed lan is bad idea
(it may well be that wonderful application that makes ipv6 tick and useful 
to the point that everyone would quickly abandon v4 :), but this really
would mean new layer for the Internet TCP/IP network and we better bet 
prepared and do proper architecture and modeling for such design.

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: Thomas Narten <[email-masked]>
Date: Tue, 15 Nov 2005 12:00:36 -0500

David Barak <[email-masked]> writes:

> The whole reason for a /64 being a "host" address is to incorporate
> MAC information into the IPv6 address: that bridges L2 and L3.

While true at one level, there is no architectural motivation here or
any real bridging of L2 and L3. It just so happens that MAC addrs had
desirable properties that stateless address autoconf needed.  That is,
the motivation was to allow direct inclusion of an IEEE EUI-64
Identifier into an address created via Stateless Addrconf. The
assumption was that IEEE EUI-64 Identifiers would be a
widely-available and globally unique.  And indeed, there are L2
technologies today that include an IEEE identifier, but don't use them
as link-layer addrs. Stateless addr conf assumes that the Interface
Identifier part of the address will be unique with high probability so
that it doesn't have to worry (much) about creating duplicate
addresses. Hence, it only detects (via DAD) duplicate addreses and
makes no attempt to generate alternative addresses in the case of a
duplicate.

I might agree with your assertion if IPv6 did away with ND and simply
extracted the L2 address from an IPv6 address when doing address
resolution. But that is not done.

> IPv6 has absorbed several other protocols (DHCP, IPSec, GRE) in an
> attempt to be all things to all people.

Um, this is a hard one to swallow. DHCP is not "absorbed" by
IPv6. It's pretty much standalone, just like in IPv4. And last I
checked, IPSec is pretty much the same in IPv4 and IPv6 (modulo
differences in address size). Finally, remind me, what part of IPv6
uses (much less mandates) the use of GRE?

Thomas

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 25 Nov 2005 09:58:05 +0100

Catching up late...

> At 12:53 PM 13/11/2005, David Barak wrote:

...
> Absolutely!  That's they way it was designed, coincidentally. :-)

Indeed, and it was designed to *not* need routing information.
But as has been discussed in recent weeks on shim6, an entirely
possible complement to basic shim6 is to have the routing system
appropriately update address selection preferences in hosts -
that is how shim6 can be made to respond to routing changes,
without needing any knowledge of routing.

Dino Farinacci wrote:
...
 >
 >     (3) As a separte process where on egress from TCP/UDP and ingress from IP,
 >         would use an IPC mechanism. As well as the separate shim process being
 >         an egress to both TCP/UDP and IP (for each packet direction).
 >
 >     (4) A library which is shared by both the TCP/UDP and IP processes.
 >
 >     It would be real nice if (3) could be avoided. And would be nice if
 >     the shim6 working group would decide if this is a transport function or
 >     an network layer function so (4) could be avoided.

The shim by construction preserves the upper layer identifier (a.k.a. address)
used by the transport protocol, so there is no doubt that it's below transport.

OTOH I do expect there will be an enhanced API whereby a transport that needs
to can interact with the shim; SCTP needs that for sure. But that is not
case (4) and doesn't require case (3). I see no reason why the shim can't be
in line with IP packet processing.

     Brian