Subject: [rrg] Another concern about using FQDNs as host idenfieirs//re: A concern with ILNP//re: critique of RANGI

From: Xu Xiaohu <[email-masked]>
Date: Tue, 02 Feb 2010 11:48:51 +0800

Hi all,

In the current Internet, an ICP (e.g., google) could scatter a set of
servers sharing the same FQDN (e.g., www.google.com ) worldwide or
nationwide to provide load-balancing services in an anycast-like way. For
example, if a client performs a DNS query for the A or AAAA records of ”
www.google.com”, the DNS server could return the address of a server which
is one of the nearest servers to the client, in the DNS response. Of course,
the DNS server could also return all available A or AAAA records, then the
client will choose one according to some policy. In this case, the FQDN
plays a role of service ID, rather than host ID.

If I understood ILNP correctly, each ILNP host needs a globally unique FQDN.
That’s to say, the FQDN can not be used as a service ID to represent a set
of ILNP servers which are scattered in the Internet. As a result, the above
load-balancing service through DNS is not available anymore in the ILNP
architecture. Maybe another indirection from one FQDN (representing a
Service ID) to another one (representing a Host ID) should be developed in
order to support the above service.

Xiaohu

> -----邮件原件-----
> 发件人: Xu Xiaohu [mailto:[email-masked]]
> 发送时间: 2010年1月28日 16:51
> 收件人: 'Tony Li'
> 抄送: 'RRG'
> 主题: re: [rrg] A concern with ILNP//re: critique of RANGI
> 
> 
> 
> > -----邮件原件-----
> > 发件人: Tony Li [mailto:[email-masked]]
> > 发送时间: 2010年1月28日 16:15
> > 收件人: Xu Xiaohu
> > 抄送: 'RRG'
> > 主题: Re: [rrg] A concern with ILNP//re: critique of RANGI
> >
> > Xu Xiaohu wrote:
> >
> > > OK, I got it. My point is the above scenario should be considered in a
non-
> > > clean-slate architecture.
> >
> >
> > Not necessarily.  Some folks don't feel that it's necessary (or
> > beneficial) to warp the architecture around the legacy host.  Things do
> > change.  We no longer need to be concerned with our IMP number, for
> > example.  ;-)
> 
> How many people used IMP, and how many people use current Internet? The
> difference in scale may cause us to make totally different choices. ;)
> 
> Xiaohu
> 
> > Yes, we could have a band-aid architecture.  But then we have to live
> > with those band-aids.  Forever.  No thank you.
> >
> >
> > > Then each ILNP+ host should be assigned a globally unique home address
just
> > > for communication with legacy hosts ;)
> >
> >
> > There's no such thing as ILNP+.  If someone wants to use an ILNP host
> > with Mobile IP to interact with legacy hosts, then yes, it will need to
> > act like a legacy host and have a home address.
> >
> >
> > > Not better, but worse in some cases (e.g., the above scenario), IMHO.
> >
> >
> > You haven't shown that.  All you've done is to restate that legacy hosts
> > can't take advantage of ILNP.  This was stipulated up front.  Asked and
> > answered.  Let's move on.
> >
> > Tony

---

From: Tony Li <[email-masked]>
Date: Mon, 01 Feb 2010 22:24:21 -0800

> order to support the above service.

Hi,

That's an interesting interpretation.

ILNP uses an explicit numeric token as the identifier.  The FQDN is not
the identifier.  The identifier can be found in the I record.

On a forward reference, a FQDN is resolved into an I record and one or
more L records.  In the case of a service name, it is not unreasonable
for DNS to return multiple I records, each with an associated set of L
records.  This is not explicitly called out in the current ILNP
documentation, but is a reasonable extrapolation from current usage,
plus the existing documents.

Regards,
Tony

---

From: Xu Xiaohu <[email-masked]>
Date: Tue, 02 Feb 2010 17:02:09 +0800

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 代表 Tony Li
> 发送时间: 2010年2月2日 14:24
> 收件人: [email-masked]
> 主题: Re: [rrg] Another concern about using FQDNs as host idenfieirs//re:
A
> concern with ILNP//re: critique of RANGI
> 
> 
> 

Interesting, is there any association between the I record and the L record?

Best wishes,
Xiaohu

> Regards,
> Tony
> 
> 
> _______________________________________________
> rrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/rrg

---

From: Robin Whittle <[email-masked]>
Date: Tue, 02 Feb 2010 23:18:04 +1100

Hi Xiaohu,

>From what I understand about ILNP, Tony is right to say the FQDN is
not the Identifier.  A FQDN lookup can return multiple Identifiers,
each for a different host.

However, I think such problem such as you suggested exists with Name
Based Sockets.  I haven't yet recieved clarification from Christian,
but see my concerns about his model:

          Role             Level            Name Based Sockets?

          Text name  <---] FQDN
          Identifier <---]
          Locator    <---- IPv6 address

in:   CES & CEE are completely different (graphs)
      http://www.ietf.org/mail-archive/web/rrg/current/msg05865.html

 - Robin

---

From: Javier Ubillos <[email-masked]>
Date: Tue, 02 Feb 2010 14:02:58 +0100

>           Locator    <---- IPv6 address

As per my understanding

          Role             Level

          Text name  <---] FQDN
          Identifier <---] FQDN (used as a nonsensical text string)
          Locator    <---- whatever address

There are no DNS queries done after the initial connection.

What happens on the client side is:
1. Query DNS with the FQDN
2. Get an IP
3. Send packets to that IP and add your Text name (=FQDN)

and on the server side:
1. Get a packet with the NBS name extension
2. Add text name (=FQDN) to reply packets

So, the DNS is only used in the initiating packet, to pull out a
reachable locator, the rest is then done without interaction with DNS.

The current track for NBS is going for a shim6 like approach for
management of the locators (for multi-homing and mobility). 

Primary IP : A text-string (FQDN)
Active  IP : Whichever locator is chosen and verified as reachable
(REAP?)
Locator pool: Set of locators.

// Javier

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 03 Feb 2010 12:09:35 +1300

On 2010-02-02 16:48, Xu Xiaohu wrote:
...
> order to support the above service.

SRV or CNAME would do it.

   Brian

---

From: Robin Whittle <[email-masked]>
Date: Wed, 03 Feb 2010 10:46:17 +1100

Short version:   CEE would change the current naming model to a
                 "Locator / Identifier Separation" model.  This would
                 leave the routing system unaltered, but would be the
                 biggest change ever made to architecture of IPv4 or
                 IPv6.

                 The "Locator / Identifier Separation" model is
                 widely by RRG folks as being desirable or essential.
                 I argue it is undesirable and must be avoided -
                 because adopting it would mean that most
                 communication sessions would take longer to
                 establish and involve more data being sent, more
                 packets being sent, more work and state for hosts
                 more delays due to global lookups and/or lost
                 packets etc.  This would be much worse than the
                 long-path problem and other causes of "initial
                 packet delay/loss" in LISP-ALT.

Hi Javier,

> There are no DNS queries done after the initial connection.

This is only true if the second host, which you refer to as the
"server", doesn't care whether the packet it sends goes to the host
with the Identifier which was in the first packet, or to some other host.

Just having a packet arrive with a particular Identifier and Locator
doesn't establish reliably that the host with this Identifier can be
reached with that Locator.  With some servers, such as DNS, which
don't care about the identity of the hosts they send their replies
to, what you say is true.

For many other applications, it is important that the respondent know
for sure that the packet it sends won't go to any other host than the
one with the same Identity as that contained in the packet it received.

This is easy with today's naming structure, where the IP address
functions as both Identifier and Locator.  The respondent gets a
packet with source address XYZ and can simply reply with a packet
addressed to XYZ.  (In neither naming model can the respondent know
for sure that the initial packet was sent by the host with the
Identifier and Locator indicated by the source field(s) of that
packet, but that is a separate issue.)

With today's naming model, the packet won't necessarily get to the
host whose Identity is XYZ, because it may be lost.  However, the
routing system ensures that the packet won't go to a host which does
not have Identity XYZ.  (In both models, a physical host may have
multiple Identities too - multiple IP addresses in the current model
or multiple Identifiers in the CEE Loc/ID Sep. model.)

With CEE architectures, at this early stage in the communication
process, the respondent host can only ensure its reply packet does
not go to a host which does not have the Identifier contained in the
initial packet by the the respondent doing an Identifier ->
Locator(s) lookup. At this point in the communication, the lookup is
the only way of knowing which Locators the host with a given Identity
has.  (Later, if the hosts establish nonces or some other
authentication mechanism, then one host, already known to be the one
with a given Identity, can securely tell the other that it has a new
Locator and so the other host should use that Locator for future
packets.)

CEE completely alters the naming model from the current one in which
Identifier and Locator roles are both played by the one IP address,
to one of several models in which these roles are played by different
objects in different namespaces.

This is widely regarded in the RRG as a good thing. Tony regards it
as "doing it right".  I believe that this approach will slow down
most communication establishment and that we should retain the
current naming model.

CES architectures retain the current model.  CEE architectures change
it to the "Locator / Identifier Separation" model, which is what I am
arguing against.  This model will forever burden hosts with extra
work, involve extra traffic, extra packets and longer delays and
greater sensitivity to packet loss.

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 hope you will write about why you agree or disagree with this.

> reachable locator, the rest is then done without interaction with DNS.

Yes, but only if the "server" doesn't care whether its reply goes to
the host with the Identifier which is in the query packet.  In NBS,
this is a FQDN.  In most or all other CEE architectures, the
Identifier is a separate thing from the FQDN.

> Locator pool: Set of locators.

I don't clearly understand the above.  I hope Christian will soon
join this discussion.

  - Robin

---

From: Xu Xiaohu <[email-masked]>
Date: Wed, 03 Feb 2010 10:24:07 +0800

> -----邮件原件-----
> 发件人: Brian E Carpenter [mailto:[email-masked]]
> 发送时间: 2010年2月3日 7:10
> 收件人: Xu Xiaohu
> 抄送: 'RRG'
A
> SRV or CNAME would do it.

Yes, SRV can perform the indirection role mentioned above (I'm not sure
CNAME can play the same role.). However, "SRV records will be used by
clients for applications where the relevant protocol specification indicates
that clients should use the SRV record..."(Quoted from RFC 2782 "DNS SRV
RR"). I wonder whether it is practical to require all applications to
support SRV RR.

Anyway, before using whichever tool (e.g., SRV) for indirection, the ILNP
advocators should admit that multiple I records associated with a given FQDN
CAN ONLY belong to a single host.

Xiaohu

---

From: Xu Xiaohu <[email-masked]>
Date: Wed, 03 Feb 2010 10:37:13 +0800

> -----邮件原件-----
> 发件人: Robin Whittle [mailto:[email-masked]]
> 发送时间: 2010年2月2日 20:18
> 收件人: [email-masked]
> 抄送: Xu Xiaohu; 'Tony Li'
A
> each for a different host.

No. if you see the LP record and its usage (see the following quotes) in
ILNP, you will infer that the multiple identifiers associated with a given
FQDN belong to a single host, rather than different hosts.

   "...In the new scheme, site multi-homing works in a similar manner,
   with nodes having one Locator for each upstream connection to
   the Internet.  To avoid a DNS Update burst when a site or
   subnetwork moves location, a DNS record optimisation is
   possible.  This would change the number of DNS Updates required
   from Order(number of nodes at the site/subnetwork that moved)
   to Order(1). [ILNP-DNS] "
"
2.3 "LP" Resource Record

   (Description of "LP" record use goes here.)

   An I record has the following logical components:
        <domain-name>  IN  I  <preference>   <domain-name-2>
"

Xiaohu

---

From: Robin Whittle <[email-masked]>
Date: Wed, 03 Feb 2010 20:22:52 +1100

Short version:    As far as I know, the text Xiaohu points to is
                  not relevant to the question of whether a single
                  ILNP FQDN can lead to multiple unique hosts, each
                  of which has a single Identifier and potentially
                  multiple Locators.

Hi Xiaohu,

>    to Order(1). [ILNP-DNS] "

OK, this is from the latest ID, not yet at the IETF site:

  http://ilnp.cs.st-andrews.ac.uk/docs/id/draft-rja-ilnp-intro-03.txt

Here is my understanding of how ILNP works, or should work.  I am
busy with RANGER and won't try to re-read the ILNP material now.

If a host has an Identifier ZZZZ ZZZZ (64 bits) and has two Locators:

    AAAA AAAA (64 bits, from ISP-A)

    BBBB BBBB (64 bits, from ISP-B)

then the host has, in conventional terms, two IP addresses, each one
being an "upstream connection to the Internet."

    AAAA AAAA ZZZZ ZZZZ  128 bit address, with packets arriving via
                         ISP-A.

    BBBB BBBB ZZZZ ZZZZ  128 bit address, with packets arriving via
                         ISP-B.

There may similarly be another host in the same end-user network,
with Identifier YYYY YYYY.  Its two (in conventional terms) IPv6
addresses would be:

    AAAA AAAA YYYY YYYY
    BBBB BBBB YYYY YYYY

The paragraph you quoted refers to a mechanism by which, if this
end-user network stops using ISP-B, but instead starts using ISP-C
(which gives all the hosts in this network a new Locator CCCC CCCC,
then there will be a protocol for the end-user network to tell the
DNS server, with a simple command, that all the BBBB BBBB xxxx xxxx
entries should be deleted, one for each host, and be replaced by CCCC
CCCC xxxx xxxx entries.  This is more concise then having to tell the
DNS server:

   For Identifier YYYY YYYY, delete Locator BBBB BBBB
   For Identifier YYYY YYYY, add Locator    CCCC CCCC

   For Identifier ZZZZ ZZZZ, delete Locator BBBB BBBB
   For Identifier ZZZZ ZZZZ, add Locator    CCCC CCCC

etc. for each of the hosts in this network.

As best I understand it, the implementation if this in the zone files
is something like specifying, for each host in this end-user network,
two place holders for Locators, rather than the actual locators.

If all the hosts, YYYY YYYY, ZZZZ ZZZZ etc. each have the same two
place holders:  JJ and KK, and JJ was elsewhere defined to be AAAA
AAAA and KK was elsewhere defined as BBBB BBBB, then it will be easy
for the end-user network to tell the DNS server that all its hosts
are no longer using BBBB BBBB as their second locator, but are using
CCCC CCCC instead, simply by sending a single command to redefine KK.

>         <domain-name>  IN  I  <preference>   <domain-name-2>

This is from:

  http://ilnp.cs.st-andrews.ac.uk/docs/id/draft-rja-ilnp-dns-02.txt

I think these last two lines are incorrect.  I think Ran did a copy
and paste operation from the previous section, and forgot to modify
them to be the LP record.

The LP record is explained in page 8 of draft-rja-ilnp-intro-03.
This LP record and the paragraph you quoted above do not seem to have
anything to do with the question:

   How does ILNP do the equivalent of "round-robin DNS", in which
   a single FQDN leads to multiple hosts - and in ILNP, how this
   works with each host having multiple locators.

My understanding is that in ILNP a FQDN can return, when looked up in
the DNS, one, two or more Identifiers, each with one or more
Locators.  Since each Identifier uniquely identifies a host which
could be anywhere at all, each such host (each such Identifier) could
have one or more Locators, independently of whatever the other hosts
(Identifiers) have.

So looking up the FQDN "www.example.com" may return:

   Identifier  MMMM MMMM   Locator(s)  AAAA AAAA
                                       DDDD DDDD

   Identifier  NNNN NNNN   Locator(s)  AAAA AAAA
                                       DDDD DDDD

   Identifier  OOOO OOOO   Locator(s)  CCCC CCCC

   Identifier  PPPP PPPP   Locator(s)  FFFF FFFF
                                       GGGG GGGG

Each character represents 8 bits.  Locators go into the most
significant 64 bits of the IPv6 address and Identifiers go into the
least significant 64 bits.

In this case, the first two would be hosts in the one physical
network, which is connected to the Net via two ISPs, one of which
provides a PA prefix AAAA AAAA /64 and the other which provides a PA
prefix DDDD DDDD /64

The third host, the one with Identifier OOOO OOOO, would be in
another physical network somewhere, which is served by a single ISP,
which provides that network with a PA prefix CCCC CCCC /64.

The fourth host, with Identifier PPPP PPPP would be in yet another
network somewhere, served by two other ISPs.

Exactly how ILNP does this, I am not sure.  Maybe it doesn't!  This
is my understanding of how ILNP could and should work.

I am pretty sure my naming model diagram for ILNP is correct:

          Role             Level            Some CEE architectures
                                            such as ILNP
          Text name  <---- FQDN
          Identifier <----           IIII IIII } Combined into
          Locator    <---- LLLL LLLL           } one IPv6 address

Ideally, Ran would confirm this.

  - Robin

---

From: Xu Xiaohu <[email-masked]>
Date: Wed, 03 Feb 2010 18:02:56 +0800

<skiped>
>    Identifier  PPPP PPPP   Locator(s)  FFFF FFFF

Hi Robin,

Yes, the ILNP DNS SHOULD have worked as what you said. However, it can't do
that since there is no direct association between I record and L record,
instead, both I record and L record are only associated with a FQDN.

By the way, IMHO, maintaining the FQDN->ID mappings and ID->Locator mappings
in two separate tables respectively is a better choice from the database
design (e.g., table structure and the relationship between tables)
perspective.

Xiaohu

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 03 Feb 2010 09:52:08 -0500

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.
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.

Yours,
Joel

---

From: Robin Whittle <[email-masked]>
Date: Thu, 04 Feb 2010 03:32:05 +1100

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.

> does not deal with the case of a DNS name that points to multiple

I think you probably mean that Xiaohu is correct.

> mechanisms available in DNS to do this, and the logic doesn't break

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,

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:

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:

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

---

From: Javier Ubillos <[email-masked]>
Date: Wed, 03 Feb 2010 17:45:06 +0100

Sorry for the spam Robin, I forgot to include the rrg-list. 

> with the Identifier which was in the first packet, or to some other
host.

As I see it, this is the same model as we use today.
The initiator resolves an FQDN to an IP and then chats with that IP.
In NBS, the initiator resolves the FQDN and sends it's packets to that
IP. The fact that it attaches its own name to the sent packets dosen't
affect what you are commenting.

I can see that it is desirable to be able to verify the link between the
ID (FQDN) and the locator (IP). But I wouldn't claim that it is a
_requirement_ in this case.

> one with the same Identity as that contained in the packet it
received.

Yes, and the solutions to that are many.
E.g. TLS (SSL). But I don't see why it _must_ be part of the
network/transport implementation.

> packet, but that is a separate issue.)

No, it cannot be certain that a packet comming form IP a.b.c and claims
to be from FQDN "host_name" is actually from "host_name". Rather,
"host_name" is used as a label for abstraction.
Perhaps this _should_ be verifiable. If it is however, I would suggest a
path where it does _not_ require an initial negotiation to happen, but
rather where the verification happens during the connection.
The trade-off is no first-packet-delay in exchange for no cool
multi-homing/mobility features for the first few packets.

The bottom line is:
Yes, I believe you do loose verification of the source identity
comparable to IP addresses and IP ranges. Perhaps this property is
important, I for sure don't use it in my day to day life (other than
filtering in my NAT box).
Does any one else have any views on this?

> objects in different namespaces.

But, it is not "completly altering the naming model".
To my knowlege, the majority of software on enduser devices resolve a
FQDN to an IP.
Unless you are programming against the socket-interface directly, you
don't even perceive the resolution to IP.

Yes, I do need to have "hard-coded" locators to be able to find a DNS
service. But after that, I don't use IP's any more.

> greater sensitivity to packet loss.

I disagree :)
In particular if this is in comparison between CEE and CES (read 'client
change' and 'network change').

* Assuming end-host always do FQDN -> IP resolutions, independent of the
underlying architecture.
* Assuming end-hosts _want_ to be mobile, and applications _will_
implement their own extensions to achieve that.

CES dosen't solve those points.

> I hope you will write about why you agree or disagree with this.

I'll do so later, it's quite a mass of text :)

I guess this whole reply can be condensed to:
"We already live in an FQDN (id) => IP (loc) world."

// Javier

---

From: Tony Li <[email-masked]>
Date: Wed, 03 Feb 2010 07:43:51 -0800

Hi Xiaohu,

> instead, both I record and L record are only associated with a FQDN.

Agreed, this is a bug, however there is a trivial fix.  Note that this isn't
architectural, it's simply a mechanism change.

Note that Ran still needs to confirm this bug.

What's needed is a mapping from FQDN -> (I, {L}) and FQDN -> (I, {LP}).
These are actually combined, but writing FQDN -> { (I, {L | LP } ) } seems
like a bit much to parse.  ;-)

Implementing this is not hard.  Let me propose a fix:

An IL record that provides a FQDN -> (I, L) mapping and an ILP record that
provides a FQDN -> (I, LP) mapping.   Thus, the records would look something
like:

Www.google.com  IL  iiiiiiii iiiiiiii llllllll llllllll

Or 

Www.google.com ILP  iiiiiiii iiiiiiii myfavorite.subnet.com

Note that in the latter case, L records as proposed are still useful.

Ran is welcome to adopt this fix (or not ;-).

> design (e.g., table structure and the relationship between tables)

Except that identifiers aren't globally unique, so that doesn't work.

Tony

---

From: Tony Li <[email-masked]>
Date: Wed, 03 Feb 2010 09:25:33 -0800

Hi Xiaohu,

>    to Order(1). [ILNP-DNS] "

I've read this over multiple times and am not following you.

Yes, there needs to be a clarification that multiple I records are
independent hosts.  There should be one identifier per host, no more, no
less.

There are, of course, multiple locators per host.

Tony

---

From: Xu Xiaohu <[email-masked]>
Date: Thu, 04 Feb 2010 08:48:06 +0800

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 代表 Joel M.
> Halpern
> 发送时间: 2010年2月3日 22:52
> 收件人: Robin Whittle
> 抄送: RRG
> 主题: Re: [rrg] Another concern about using FQDNs as host identifiers
(ILNP)
> does not deal with the case of a DNS name that points to multiple

Agree.

> mechanisms available in DNS to do this, and the logic doesn't break

Sure.

Best wishes,
Xiaohu

---

From: Robin Whittle <[email-masked]>
Date: Fri, 05 Feb 2010 15:01:04 +1100

Hi Javier,

I started writing a reply, but I need to do more work on it.

I plan to make a web page with a complete description of the current
IP naming model:

          Role             Level           Conventional IP & with CES

          Text name  <---- FQDN
          Identifier <---] IP address
          Locator    <---]

and then do the same for the naming models of Name Based Sockets,
ILNP and ideally the other CEE proposals.

 - Robin