[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Some Comments on ID/Loc Separation Proposals
I have been analyzing a few of the proposal for ID/Loc separation
(HIP, NOID and MAST) and I have some comments (attached).
Unfortunately, I won't be in most of the multi6 meeting today
(I may pop in and out), but please consider this e-mail as input
to your discussion.
Sorry for the cryptic nature of some of these comments. If there
are any questions, let me know. I may try to write-up something
more detailed later.
The combination of ID/Loc in IP (v4 and v6) is an architectural
feature with good and bad trade-offs. It can be viewed as an
ID/Loc system with: (1) Very efficient ID -> Loc mapping (they
are the same), (2) An inflexible association between a single
ID and a specific Locator (they are the same). Property #1
allows convenient, high performance referrals. Property #2
causes difficulties for mobility, multihoming, etc.
The use of the term "Identifier" or "ID" sweeps an important
issue under the rug in some cases: Is this a host ID or an
interface ID? The current IP (v4 and v6) architecture uses
interface IDs. IPv4 implementations are generally constrained
to one ID per interface, while IPv6 supports multiple IDs per
interface. ID selection is linked to outbound interface
selection -- it is still unclear to me what implications this
has for ID or Locator selection in ID/Loc separation protocols.
Some things to consider for proposals:
What are the mechanisms to support (and the costs of):
- Initial end-to-end connection set-up.
- Referrals. The question I ask is: Could this mechanism
support FTP PASV mode -- I know no one uses it, but it is
a simple, well-understood referral. If a mechanism won't
support FTP PASV, then it won't support any referral-based
- What happens when two nodes try to establish connections
to each other "simultaneously" (where "simultaneously"
is defined to mean "during each others' connection set-up
- How does the mechanism avoid connection hijacking?
Of course, there are many other interesting questions.
Interesting proposal that offers at least some support for
referrals and offers a zero-cost mapping from an ID to a
locator, by using one of the available locators as the ID.
Supports multihoming and planned renumbering, but not
- NOID is not compatible with local addressing or
"two-faced" DNS. Relies on consistent information
being returned from the DNS at both ends.
- NOID happens below frag/reassm, but may add 8
bytes to the packet length. ??
- NOID may have issues when two hosts both attempt
to open a connection to the other within the NOID
establishment phase (which may last for a while,
as it involves two DNS lookups, etc.). If I
am modeling this correctly, if NodeA is currently
in the process of establishing a NOID connection
to Node B (we have the state set-up on NodeA, but
not on NodeB), NodeB's attempts to open a connection
to NodeA will be discarded by NodeA because they
don't contain the correct FlowID. Am I right?
If so, is this a problem?
- If the topological information in an AID is no
longer valid to reach the node, a referral will
require two DNS lookups (reverse lookup, followed
by forward lookup) before the new connection can
be established. This represents a significant
change to the speed/performance of referrals.
Uses a control protocol between the two end-nodes to
exchange address information. The current proposal is
two sparsely defined to allow a full analysis of its
properties. In particular the document does not describe
when MAST control messages would be sent, and how the
nodes would know when to send them.
- This proposal seems, to me, to sweep the entire
problem under the rug of this mostly-unspecified
- How do the end-points know when they need to
send SET operations to update the locators
being used on the ends of this connection?
- The draft suggests using IPsec to secure the
control connection, but IPsec doesn't support
changing end-point addresses.
- The PROBE message sounds (to me) similar to
the old proposal to use pings to detect dead
gateways. What can we learn from the problems
with that model that apply here? I have stored
my knowledge of the issues here in long-term
storage, and I'm still waiting to retrieve it.
But, there are some serious issues with active
keepalive mechanisms that we should probably
Very well-developed proposal for end-to-end ID/Loc separation.
No ID->Locator mapping mechanism, so no support for referrals.
- The lack of any ID->Locator mapping mechanism is a
blocking problem for using HIP (as currently defined)
with anything but simple end-to-end applications.