Hi Joel,
Thanks for your support for my msg05921.
I think I was right to state that the text Xiaohu quoted was not
relevant to the question of how ILNP could specify multiple hosts
from a single FQDN.
I presented a model by which I thought ILNP could or should do this -
without stating that it definitely would do this.
Xiaohu responded in msg05922 that my model was good, but that ILNP
does not in fact work this way.
So when you write:
> As far as I can tell, Robin is correct. The current ILNP specification
> does not deal with the case of a DNS name that points to multiple
> different machines.
I think you probably mean that Xiaohu is correct.
> It seems pretty clear that some form of indirection will be needed so
> that a DNS name can point to a list of names, each of which has I and L
> (and maybe LP) records. The good thing is that there are a number of
> mechanisms available in DNS to do this, and the logic doesn't break
> anything.
I think you are referring to some kind of system where one FQDN leads
to a list of other FQDNs, each of which is for a single host. Then,
with each one of the "single host" FQDNs, you do a DNS lookup and get
exactly one Identifier and one or more Locators. I guess this could
work, but it is messy - since how could anyone tell by looking at a
FQDN that it was a "single host" one or one which lead to a list of
"single host" FQDNs?
I think what you are suggesting would be a four level system:
Role Level
Text Name <---- FQDN which returns a list of 1 or more:
Text Identifier <---- FQDN for a single host
64 bit Identifier <---- IIII IIII } Combined into
64 bit Locator <---- LLLL LLLL } one IPv6 address
Then you could use DNS for the two types of lookup which are needed:
1 - Text Name to: >=1 x Text Identifiers.
2 - Text Identifier to: 1 x 64 bit Identifier
>=1 x 64 bit Locator
Here is my understanding of how ILNP is specified at present, and how
I think it could be redesigned to support multiple hosts with one
FQDN (as today's IPv4 and IPv6 2 level naming models do) - while
retaining ILNP's current 3 level naming model.
Looking closely at draft-rja-ilnp-dns-02.txt it can be seen that when
a FQDN refers to a single ILNP host there is:
1 I Identifier record
The value in the preference field for this I record
is irrelevant.
1 or more L Locator records.
The value in the preference field only affects host
behaviour if there are two or more L records with
different preference values. The L record with the
lower preference values will be tried first.
When an FQDN refers to two or more hosts, there are correspondingly
two or more Identifier records:
2 or more I Identifier records
The value in the preference field only affects host
behaviour if there are two or more I records with
different preference values. The I record with the
lower preference values will be "preferred" - but
I think what this means.
1 or more L Locator records.
The value in the preference field only affects host
behaviour if there are two or more L records with
different preference values. The L record with the
lower preference values will be tried first.
I think there is no purpose in having a preference value for
Identifier records. As far as I know, the ILNP documents don't state
what "preference" means for Identifier records.
As Xiaohu points out:
> ... there is no direct association between I record and L record,
> instead, both I record and L record are only associated with a
> FQDN.
This is true, as can be seen from the above, where 2 or more
Identifiers are returned for a single FQDN, with 1 or more Locators,
but without any indication of which Locators are to be used with
which Identifiers.
ILNP has a 3 level naming model:
Role Level Some CEE architectures
such as ILNP
Text name <---- FQDN
Identifier <---- IIII IIII } Combined into
Locator <---- LLLL LLLL } one IPv6 address
However, in its current form, ILNP is incapable of associating
particular Locators with individual Identifiers, when multiple
Identifiers are associated with a given FQDN.
Here is what I think would need to be done to ILNP to make it work,
at least in respect of a FQDN being able to refer to multiple hosts:
1 - Remove the Preference element of the I Identifier record -
unless there really is a purpose for it.
2 - Have a DNS lookup for a FQDN provide:
1 or more Identifier records.
+ For each such Identifier record:
1 or more Locator records, with preference field.
3 - Provide a mapping system, by which any host could look up
an Identifier to find what Locators it has.
As far as I know, all CEE architectures need the point 3 mapping
system, lookup system or whatever it might be called - but perhaps
ILNP doesn't.
To see why I believe this lookup facility is needed, please see:
Today's "IP addr. = ID = Loc" naming model should be retained
http://www.ietf.org/mail-archive/web/rrg/current/msg05864.html
I am not sure how point 2 would be structured in the DNS zone files,
or in the DNS reply. If it can't be, then the DNS lookup should only
return one or more Identifiers - requiring a separate lookup as with
point 3.
Point 3 might be possible via a DNS lookup, but it would be very
demanding. ILNP Identifiers are 64 bit binary numbers.
No single DNS server can handle the global set of Identifiers. Here
is one way of handling the range, but splitting it up over many
authoritative DNS servers (2^54 of them, to be precise!).
If the 64 bits are broken into 8 bytes, and each byte is given a
decimal representation between 0 and 255, then it would be possible
to have a structure of DNS servers such as to convert an Identifier,
whose value was:
Hex 2B B8 46 02 E9 4D 27 A9
Decimal 43 184 70 2 233 77 39 169
via a DNS lookup on the name:
169.39.77.233.2.70.184.43.ilnp-id.arpa
into a list of one or more Locators, each with a preference.
If the global set of Identifiers was scattered randomly, then every
node on this 7 level DNS hierarchy, with 256 branches at each level,
would need to have at least two authoritative nameservers: a total of
2^55. Obviously more than one DNS server can run on a physical
server, but the whole thing scales very badly indeed even if one
physical server could run 2^20 authoritative DNS servers. That would
still require 2^36 (32 billion) physical servers.
Also, there's no way resolvers could cache the IP addresses of more
than the right-most one or two levels of DNS server. So doing a
lookup would involve five or so levels of recursion.
Assuming ILNP needs an Identifier -> Locator lookup service, then
whether it is implemented with DNS, something like DNS or any other
way I can imagine, it is not going to scale well if the Identifier
space is used entirely randomly.
However, if Identifier space was allocated in blocks, so in certain
subsets of the vast 2^64 range, smaller ranges of sequential
Identifier values generally had quite a high proportion which were
actually used, then this would enable the DNS or similar structure to
work nicely, with only a small subset of the authoritative servers
which would be required to handle the complete range of random
Identifier values.
In this case, resolvers would have a better chance of caching the IP
addresses of the right-most levels of the 7 level scheme. Also,
those right-most levels would have a better chance of returning the
IP addresses of multiple lower levels (to the left) if at each level,
there were only a fraction of the possible 256 branches in use.
I will read ILNP again later - after I have read the other proposals.
My guess is that with changes such as I suggest, it would be a
reasonably elegant CEE architecture. Nonetheless, I think there are
many reasons to choose a CES architecture over any CEE architecture,
starting with the desirability of retaining the current 2 level IP
naming model, rather than adopting a Loc/ID Separation naming model
which is how CEE architectures work.
CES & CEE are completely different (graphs)
http://www.ietf.org/mail-archive/web/rrg/current/msg05865.html
- Robin
_______________________________________________
rrg mailing list
rrg@irtf.org
http://www.irtf.org/mailman/listinfo/rrg
