[My apologies for the delay caused by the US Thanksgiving Holiday.]
Earlier, Damian Lezama wrote:
> If you have duplicated IDs, then what happens
> if you have a conflict ?
Before we start, some observations about the probability
of this:
- If one forms the ID from any IEEE MAC address on the system,
then probability of collision is roughly zero.
There are no known modern instances of duplicate MAC
addresses. There is a credible report of some
duplicates being seen in the wild about ~20 years ago.
IEEE manages the MAC address space to prevent duplicates.
- If one forms the ID using the IPv6 Privacy Address
extensions, then probability of collision is still
extremely low.
- If one forms the ID from the hash of a public key,
in a HIP-like manner, collisions remain unlikely.
If duplicate MAC addresses did appear on the same bridged
LAN segment (i.e. IP subnetwork), then layer-2 bridging
would not work properly (regardless of whether one were
using IPX, IPv4, IPv6, CLNP, or some other layer-3 protocol).
This is why IEEE carefully manages the MAC address space
to preclude duplicate MAC addresses.
So this "ID Collision" scenario is incredibly unlikely.
Next, some other observations:
- A node's Identifier does not usually change
when the node moves its point of network attachment;
the node's (set of) Locator(s) normally will change
when the node joins/leaves some IP subnetwork.
- DHCP or IPv6 Router Advertisements can be used
to provide updated Locator values to nodes;
- one would not expect that DHCP would be used to
provision an Identifier to a node, since identifiers
can be locally self-generated within each node
in various ways.
In this example:
A, B, and C are ILNP-enabled IPv6 nodes.
A is a server; B and C are clients.
A can make DNS lookups to determine the FQDN of B
(and/or C) and include the FQDN in the ILNP Session
Cache within A. This is sufficient to disambiguate
B from C. (As an example, this might make sense
for a typical client host with a normal number
of concurrent sessions.)
Alternately, A can choose to correspond with only one
node at a time for a given remote ID value. (As an
example, this might make sense for a web server that
has a very high (e.g. thousands) number of concurrent
connections, each short in duration.) Note that in
this model, by the time the user hits retry on his/her
web browser, that web server likely won't have the
other session trying to use the same Identifier in
its ILNP session cache, so the retry is likely to
succeed.
Also, if IPsec is in use, then the systems can use
the combination of Identifiers and IPsec SPI values
to differentiate one correspondent from another.
So there are a range of approaches possible, and
communication remains possible between a pair of nodes
even in the (highly unlikely) event of an Identifier
collision.
Finally, note that these same issues exist today with
about the same probability in the deployed IPv4/IPv6
Internet. Source address forgery has been used for
at least 13 years to attack various Internet connected
devices. [US CERT: CA-1995-01] Separately, there are
a number of known cases where a node was misconfigured
and was using an invalid IP address (one that conflicted
with another node on the same IP subnetwork as the
misconfigured node). These examples are precisely
the same as an Identifier collision with ILNP. They
aren't a widespread problem in the deployed Internet.
> Is this proposal suggesting that DNS should be
> responsible for finding the hosts locators ?
Hmm. The DNS doesn't "find" anything. With ILNP, the
DNS stores various networking values (I, L, PTRL, PTRI)
just as it does today (A, PTR, CNAME) and makes them
available to nodes querying via the DNS protocol.
Individual nodes are responsible for updating their
authoritative DNS servers as that node's networking
parameters change. These updates can use, for example,
"Secure Dynamic DNS Update" [RFC-3007].
"Secure Dynamic DNS Update" is widely available now in
the free BIND software for UNIX/Mac systems, and also
in Microsoft Windows (both client & server).
[source: Liu & Albitz, "DNS & BIND", 5th Edition,
pp 500-508.]
The recent press about DNS server vulnerabilities has
caused many sites to upgrade their DNS servers to modern
versions. It is also causing various parties that were
impeding deployment of DNSsec to switch course and
actively require deployment of DNSsec. (These are
possibly the only good to come from that event.)
> Is a DNS update fast enough for that to work
> (i.e. with mobility) or [will] cached entries
> make it too slow ?
An excellent question.
ILNP uses DNS for rendezvous of new sessions,
just as the existing deployed Internet uses DNS
for rendezvous of new sessions.
DNS resource record TTLs are configurable on a
per-record basis. So a node can set its I record(s)
to have some relatively long TTL value (e.g. days),
and set its L record(s) to some quite short TTL value
(e.g. seconds).
We experimented with varying the DNS TTL values
for all records within a site. We tested TTL
values as low as 60 seconds. Preliminary results,
which require more detailed analysis, indicate that
DNS servers scale fine for all of the tested values.
We plan to extend the experiment to much shorter time
periods in future.
We note that this result (i.e. that DNS caching of A
and PTR records is ineffective in the deployed Internet)
is entirely consistent with the simulation analysis done
at MIT LCS earlier this decade. ["Reconsidering Internet
Mobility", Proc. of 8th Workshop on Hot Topics in OSs. 2002]
Incremental zone transfers for DNS mean that primary->secondary
DNS updates also can be performed efficiently.
If there were an issue with scalability of some particular zone,
then there are at least two obvious approaches:
- Split the zone
- Buy more powerful systems for the DNS server
Note that a DNS Zone split can be made largely transparent,
through use of CNAME (and PTRL, LP) DNS resource records.
For existing sessions, movement or other change in
Locator values normally are handled using "Locator Update"
control messages. (NB: While the current drafts
use ICMP for these messages, there is no magic;
one could use UDP rather than ICMP if desired.)
Yours,
Ran Atkinson
[EMAIL PROTECTED]
_______________________________________________
rrg mailing list
[email protected]
https://www.irtf.org/mailman/listinfo/rrg
