Short version: If ILNP's Identifiers were always globally unique,
I would tend to agree that ILNP's semantics are
"crisp and clear".
However, this is not the case with Identifiers which
can be only unique within a local /64 network.
Hi Tony,
In "Re: [rrg] ILNP - communication between hosts with
same(duplicate) identifier", responding to Christian Müller, you wrote:
>> But how would an ILNP connection work if two hosts A and B on
>> different subnets but with the same identifier value tried to
>> connect to each other? Like host A tried to send packets to
>> identifier i, but could not determine if that was his own id or
>> the one host B uses.
>
>
> This should not be an issue. Since identifiers can be local, the
> implementation must be prepared for this.
>
> In particular, globally unique identifiers can be used to demux
> transport connections, but when the identifier is locally unique,
> then the implementation would need to demux using the full
> address.
According to:
http://tools.ietf.org/html/draft-rja-ilnp-intro-05
ILNP involves:
crisp and clear semantics for the Identifier and for the Locator
and avoids the currently "semantically-muddled concept of the IP
address", in which the IP address is both the Locator and Identifier
of an interface of the host.
If ILNP's Identifiers were guaranteed to be globally unique (which I
can only imagine resulting from a hierarchical assignment system,
much like today's global unicast IP address system, rather then
generating them from hardware IDs - see another thread on this) then
I would be inclined to agree that the semantics of ILNP Identifiers
were indeed "crisp and clear".
BTW, I think Ran's references to "RFC 4219" should be to RFC 4291.
However, ILNP has two types of identifier, which can be distinguished
by a flag in one of the 64 bits:
http://tools.ietf.org/html/rfc4291#page-20
I understand this as:
Bit 6 = 1 ==> Globally unique.
Bit 6 = 0 ==> Unique only within the /64(s) of the Locator(s)
currently used by this host.
If we consider two hosts, A and B, with A attempting to communicate
with B, there are four combinations of Identifier uniqueness:
0 - A's Identifier is globally unique. B's is globally unique.
1 - A's Identifier is locally unique. B's is globally unique.
2 - A's Identifier is globally unique. B's is locally unique.
3 - A's Identifier is locally unique. B's is locally unique.
Leaving aside various ways in which A could be prompted to commence
communication with B (FQDN -> DNS lookup; referral of Identifier and
Locator; Receiving a packet with an Identifier and Locator . . .)
lets look at the cases:
0 and 1 are fine. B's Identifier is globally unique, so there is
no fuss.
2 and 3 have at least two options:
i: B's Locator matches one or more of A's Locators.
ii: B's Locator does no match one or more of A's Locators.
(Maybe A could find out all B's Locators, but for simplicity I am
assuming it only knows one Locator at present.)
In cases 2i and 3i, we can be assured (not counting the possibility
of an attack) that B's Identifier is different from A's Identifier.
This is because in 2i, the Identifiers are different due to bit 6 at
least and in 3i, properly functioning ILNP hosts A and B could not
have the same locally unique identifier, since each host as at last
one Locator in common.
>From Ran's intro I-D:
* The Locator is used only to name the subnetwork a node is
* connected to, while the Identifier is used only for node
* identity. So the routing system uses Locators, while
upper-layer protocols (e.g. TCP/UDP pseudo-header checksum,
IPsec Security Association) use only the Identifier.
With ILNP, the Identifier is an unsigned 64-bit number.
This provides a fixed-length non-topological name for a node.
With this proposal, the IP Security protocols, AH and ESP,
are enhanced to bind Security Associations only to
Identifier values and never to Locator values (and also
not to an entire 128-bit IPv6 address).
Similarly, key management protocols used with IPsec would be
enhanced to deprecate use of IP addresses as identifiers and
to substitute the use of the new Identifier for that
purpose.
Note that a given ILNP session normally will use a single
Identifier value for the life of that session.
The IP Security standards are enhanced here by binding IPsec
Security Associations to the Identifiers of the session
endpoints, rather than binding IPsec Security Associations
to the IP Addresses as at present.
All this is crisp and clear - and would be fine if Identifiers were
always globally unique.
By including the possibility of Identifiers which are only unique
within a /64 network, I think the proposal becomes very messy indeed.
You wrote:
> . . . when the identifier is locally unique, then the
> implementation would need to demux using the full address.
If this is true of ILNP - and I think it must be to support
Identifiers which are only locally unique within a /64 - then much of
what Ran writes about purely "Identifiers" in the I-D is incorrect,
or at least incomplete.
If this is true of ILNP, then the true semantics of Identifier and
Locator are muddled and not at all crisp. Likewise, the ILNP
functionality in the stack will be much more complex.
- Robin
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
