RE: [RRG] On "jack-down" models

[Randall Atkinson <rja@extremenetworks.com>]

Earlier, Scott Brim wrote:
% Specifically how does a network-layer ID make host-based mobility and
% multihoming easier?

It decouples the TCP/UDP transport session state from the location.
So when a node moves location (or its upstream connectivity changes
because one of its several upstream links develops a fault -- which is
really the same thing as moving location), the Transport protocol
session state is not affected by the network-layer location change.

It is entirely analogous to why link-layer mobility works so well
(Transport layer session state does not include link-specific information).

To be fair, there are several approaches to this that (arguably)
are pretty similar:

1) SHIM6
2) GSE/8+8
2b) ILNP
3) Mark H's proposal to modify TCP/UDP behaviour so that the
   network-layer information is not part of the Transport layer
   session state.

In some ways, this reminds me of ancient discussions ("Layer Wars")
about the difference between changes at the top of the
network layer and changes at the bottom of the transport layer.
(Summary: the architecture might be different between those two,
but often the engineering is pretty similar.)

% When a host works from multiple IP addresses (either serially or
% simultaneously), which functions need to know that this is in fact the
% same host?  It's for service continuity.  The IP layer doesn't care.

The IP layer might care.  For example, if a node were single-homed
and changed its location without a "soft handoff", then there needs
to be some method to verify that the location update message
came from the same node one was originally communicating with.

% Transport might care but won't know how to use the knowledge
% effectively.  (E2E principle within a general-purpose stack.)

See above.

> And even there ephemeral, crypto-strong node-to-node
> identifiers may be very useful.  However, I do think that a HIP-like
> intermediate step towards such architectures is probably very useful.

The above quoted material is unclear to me.  Given that all keys are
eventually compromised, I would not want my identity to be some
f(public key or some other key) -- so that a key compromise does not
always lead to a loss of identity.

Yours,

Ran
rja@extremenetworks.com


--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg