[rrg] GLI-Spit: discussion and draft critique

[Robin Whittle <[e-mail]>]

Here is a draft critique followed by a longer piece describing my
understanding of GLI-Split.  The longer piece should explain everything
in the draft critique.

I hope to improve these with feedback from the proponents and other list
members.  When I get substantial feedback from the GLI-Split designers I
will revise both of these pieces and write a 500 word version of the
revised critique.

This is not tightly edited or carefully checked.

The following is longer than the GLI-Split proposal.  It takes a lot of
work to understand GLI-Split and imagine how it would actually work in
various settings.  Only then can I describe my understanding and provide
a critique of what I understand about the proposal.  Some of what
follows is probably relevant to other CEE architectures too.

  - Robin





GLI-Split - critique (V1 = draft)
---------------------------------

GLI-Split is an innovative Core-Edge Elimination (CEE) architecture
involving new network elements, changes to host stacks and both global
and local mapping systems.

The new network elements are "GLI-gateways" which are located at (or on
path with) the the CE routers of networks which support GLI-hosts, which
are known as "GLI-domains".  GLI-gateways rewrite some source and/or
destination address bits of packets entering and leaving the network, if
they are addressed to and/or sent by GLI-Split hosts.  This behaviour
may be dependent on flags in these addresses and on the presence and
contents of a new IPv6 extension header - the "Address Buffer" (AB).
ABs are used only in local networks, not in the DFZ.  They are added or
removed by GLI-gateways and the GLI stack in upgraded hosts.

Like GSE - and unlike other CEE proposals - GLI-Split does not require
any changes to applications.  GLI-aware applications could be
accommodated via a new API, although these are not contemplated in the
current design.

Like all other CEE proposals, GLI-Split is applicable only to IPv6 and
the benefits - portability, multihoming and inbound TE only apply to
communications with other GLI-Split hosts.

At this early stage of GLI-Split's design, there are no details of the
length of the Locator and Identifier fields within the IPv6 address.
Nor are there any details of how the required global mapping system
would be implemented.  GLI-Split uses an unmodified DNS, but there needs
to be an elaborate global mapping system by which any host can query an
Identifier, and receive one or more Locators - probably with (as yet
unspecified) information about which to use in a multihoming scenario if
two or more enable the host to be reached.  There may also be other, as
yet unspecified, mapping information to implement load sharing or other
aspects of inbound TE from the point of view of the host with this
Identifier.

The current design does not specify or discuss caching times for this
mapping information.  In the absence of any such details, it is
impossible to estimate the performance and scaling properties of a fully
deployed GLI-Split system.

Nor is there any stated target for the number of end-user networks to be
supported by GLI-Split.  As with other CEE proposals, scalable routing
benefits only occur to a significant degree when networks are able to
rely on GLI-Split for portability, multihoming and inbound TE for all,
or almost all their communication.  GLI-Split needs to be attractive to
initial adoptors - even though it can only provide benefits when their
hosts when they are communicating with hosts of other adoptors (assuming
the hosts have upgraded stacks, which will not always be possible).
This attraction needs to be strong enough to lead to essentially full
adoption in some timeframe.  Only then can the adoptors with PI space
relinquish these prefixes and operate from PA prefixes.

The current implies that a single physical host can have multiple
Identifiers.  This should be stated more clearly - since this is a
valuable feature.

While the proposal does have examples and some good diagrams, generally
these diagrams and explanations do not go into enough detail about the
transformations performed by the host stacks, and therefore exactly what
the application (or the transport layers used by the applications) send
and receive.

A general potential problem with GLI-Split is that the actual IP address
of a GLI-Split host is only locally usable - within the physical
network, known as a GLI-domain, within which it is located.  To make it
reachable from outside this physical network - such as that of an
office, campus or factory - the global DNS returns another IP address,
one which includes a GL (Global Locator) so ordinary IPv6 hosts can send
packets to it via one of its potentially multiple ISPs.

It is possible that some applications will not operate correctly when
the IP address of the host does not match that returned for it by the
global DNS.   For instance any application which sends its own host's IP
address to another host, for later use in contacting the first host.

There are also some scenarios where split-horizon DNS is employed - a
different IP address must be returned to queriers inside a GLI-domain
than for queriers outside it.  Split-horizon DNS is complex and likely
to disrupt some applications which rely on referrals.

It is not clear how the Identifier equivalents of today's IP-address
based ACLs (Access Control Lists) can be implemented with GLI-Split, or
any other CEE architecture.

It appears that GLI-Split hosts can only multihome with other GLI-Split
hosts.  Multihoming with ordinary IPv6 hosts appears to be impossible -
as is probably the case with all other CEE architectures.

I have not fully analysed the ability of a GLI-Split host to communicate
and multihome with ordinary IPv6 hosts in GLI-domains


While CES architectures permit the use of "edge" addresses in any part
of the world, and while some CEE architectures enable an Identifier to
be likewise used with any Locator, it seems that each GLI-domain has its
own contiguous set of Identifiers.  These Identifiers can only be used
within that GLI-domain.  GLI-domains are necessarily physically cohesive
routing systems, although multi-site GLI-domains could be realized with
tunnels or private network links.  Generally, a GLI-domain will be a
single physical site such as a factory, office, school, hospital or
university.  It will generally not span cities or countries.

Therefore, a large number of GLI-domains will be needed.  If a company
has 500 offices, each one will be a separate GLI-domain, with its own
one or more GLI-gateways which link it to its one or more ISPs.

Each GLI domain has its own contiguous set of Identifiers. These
Identifiers can't be used in any other GLI-domain.

Consequently, a mobile device would be frequently acquiring not just new
Locators, but new and unpredictable Identifiers as well, as it connects
to different access networks.


Like all CEE architectures, GLI-Split implements the "Locator/Identifier
Separation" naming model, by using separate, independent, objects for
the Identifier and Locator roles.

This forces all hosts to do more work when establishing communications,
and typically adds two global mapping lookups to the basic two-packet
initial exchange which is used at the start of most protocols.  While
many people regard this naming model as superior to the current one, in
which the IP address plays both roles, Loc/ID Separation will generally
slow down the establishment of communications, and put burdens on all
hosts, which are particularly undesirable for hand-held hosts operating
over slow, potentially unreliable, 3G wireless links.

GLI-Split contains no details of how its local and global Identifier to
Locator(s) (and other information) mapping systems will be implemented.
 There are only references to LISP-ALT and some Distributed Hash Table
proposals.  Yet the scaling, security, and performance of these mapping
systems - especially the global one - is crucial to the performance of a
fully adopted system.

It appears that for any GLI-domain, the authoritative query servers for
handling global mapping queries for this GLI-domain's Identifiers,
cannot be operated by any host in that GLI-domain.  This is due to
circular dependencies, and due to the fact that no host in the
GLI-domain can have an Identifier belonging to any other GLI-domain -
such as that of the global mapping system.

Also, it is not clear how the local mapping system could be implemented
with the GLI-domain's own hosts, since these are only reachable via
local locators which are available only via the local mapping system.

There are no details of caching arrangements, or caching times, for the
global mapping system - which affect the ability of GLI-Split to work
with mobile hosts, and the general scaling of the global mapping system.


CEE architectures, including GLI-Split, suffer from disadvantages
compared to today's two-level IP naming model, in which the IP address
performs both the Identifier role and the Locator role.  CES
architectures maintain this naming model, and so do not suffer from
these disadvantages.

The first disadvantage is that the sending host starts with an
Identifier for the destination host, and must perform a global mapping
lookup on this identifier so it can obtain the one or more Locators on
which the host with this Identifier might be reached.  It then has to
choose one of these, if there were more than one, before it can send the
packet.

The second is that in many or most scenarios, as a respondent host, the
host cannot send a reply packet until it has performed a similar lookup,
on the Identifier in the source address of the initial packet - because
it cannot trust any source Locator in the initial packet.

Some CEE architectures - those which require modified applications - can
leave this decision to the application in the responding host.

Because GLI-Split (as currently designed) works with unmodified
applications, the GLI stack cannot send a reply packet until it has done
such a lookup.

With the current IPv4 / IPv6 naming model, an application can send a
packet to a given destination address, and know that the routing system
will never deliver the packet to any host with an Identity other than
the Identity inherent in that address.  To provide the same assurance to
the unmodified applications, the GLI-stack must perform a lookup of the
Identifier portion of the destination address of any packet the
application tells it to send.  This is always the case, since there is
no way the GLI-stack can determine whether or not the application is
assuming that any resulting communication really is occurring with the
host whose Identity is inherent in the destination address of the packet
the application has generated.  In this respect, a CEE architecture such
as ILNP has an advantage, since the application is responsible for doing
a lookup if it needs to.

The stack cannot rely on the Locator which was part of the source
address in the initial packet, since this could be spoofed.

Like most proposals (the exception is Ivip), GLI-Split's ability to
provide reliable and prompt multihoming service restoration, and
recovery after the failure is rectified, depends on the architecture's
own network elements, protocols and/or host stacks.  These are required
to test reachability through various ISPs to the destination network,
and to make decisions about which ISP link to send traffic packets to.
There are few details in the current GLI-Split design about reachability
testing, its scalability and about the decision algorithms for changing
the choice of which GLI-gateway to send traffic packets to.


There are two major objections to all CEE proposals.  Firstly, that
their change of the naming model to "Locator/Identifier Separation" is
undesirable (slower, more complex and more burdensome on all hosts) and
secondly that these architectures require complete, or almost complete,
adoption before there are substantial benefits to adoptors or to
scalable routing.

If such objections were for some reason unimportant, and a CEE
architecture was considered for development and global adoption, then
GLI-Split could be compared against other CEE architectures such as
ILNP, Name Based Sockets and others.

Some of these architectures avoid the need for any new network elements
- but all the other CEE proposals before the RRG require all
applications be rewritten, which is a far steeper set of barriers to
adoption than those which appear to be inherent in GLI-Split, because it
is intended to operate with unmodified applications.




GLI-Split - discussion of my understanding
------------------------------------------

This was written on 2010-02-15 based primarily on the 2009-12-22 version
of the GLI-Split paper:

http://www3.informatik.uni-wuerzburg.de/~menth/Publications/papers/Menth-GLI-Split.pdf

and the Summary:

http://tools.ietf.org/html/draft-irtf-rrg-recommendation-04#section-10.1


I wrote some queries to the RRG list on February 11 and 12:  Michael
responded off-list to the following points:

  (msg06004):  Michael sent me an updated version of the paper with
               the text corrected as I suggested.  ("Beyond Compare"
               from Scooter Software enables comparisons between many
               file formats, including PDF files.)

               There was no response to the "Also, the ID hijacking"
               and later text.


  (msg06006):  Neither question answered, but this reply provides
               new information about GLI-Split:

                  "Applications usually communicate with identifier
                   addresses, but also a more advanced API must be
                   offered in addition to allow active multipath
                   routing through applications or at least by
                   transport layer protocols. We'll add a note to
                   this."

  (msg06007): An answer to my concerns about PMTUD due to "Address
              Buffers":

                  "Good point. The simplest solution would be that
                   the GLI-gateway know the MTU of its domain and
                   bounces packets that are too big. More in the
                   coming days ...".


While it has taken me a long time to reach this understanding of
GLI-Split, which is no-doubt far from perfect, I was able to do this
almost entirely be reading the proposal.  This is in contrast to having
to go back and forth asking questions, getting answers, asking more
questions etc. with some other proposals.  A major part of the reason
for this is that GLI-Split has numerous examples with excellent colour
diagrams.

Below I used "host" instead of "node".


GLI-Split is a Core-Edge Elimination (CEE) architecture applicable to
IPv6 only.  While some CEE proposals - such as ILNP - involve changes
to host stacks and applications, but require no additions to the
routing system, GLI-Split is unique among the RRG CEE architectures
in not requiring alterations to applications.  However, it does require
additional network elements - address rewriting "GLI-gateways"
approximately located in or near each network's CE router.

I am using "GLI-domain" as a synonym for "an end-user network which has
adopted GLI-Split address space exclusively".  Below, I further define
my understanding of exactly what a "GLI-domain" must be, which goes
somewhat beyond what is explicitly stated in the proposal

GLI-Split requires:

  1 - Significant enhancement to host stacks.

  2 - The provision of a new mapping system, the mechanisms of which
      are currently unspecified.  This system accepts an Identifier
      (perhaps 64 bits or so?) in the query and returns one or more
      Locators (perhaps 32 bits or so?) to which this Identifier value
      is currently mapped.  Perhaps it returns complete IPv6 addresses.
      In addition to the Identifier, it returns an L/G flag (Local or
      Global, as in Figure 2) and a "GAP" (Global Address Preservation)
      flag denoted, if it is true, as "(g)".

      For each Identifier and its Locators, the global part of the
      mapping system also returns information which enables the GLI
      stack in a sending host to choose which of multiple Global
      Locators to use when the destination host is multihomed, and it
      appears that the host is reachable via two or more Global
      Locators.  There can also be, again in a so-far unspecified
      format, information for load sharing across multiple Global
      Locators, or the subset of them which the sending host has
      reason to believe can be used to deliver packets to the
      destination host.

      Each "GLI-domain" - end-user network (EUN) which adopts
      GLI-Split - has its own local mapping system which returns one
      (or more?) LLs (Local Locators), if this Identifier belongs to
      this GLI-domain.  If the Identifier does not belong to this
      GLI-domain, then no Locators are returned - and the local
      mapping system may automatically pass the query to the global
      Identifier --> Locator(s) mapping system.

      See below for my understanding of how ID space would be
      assigned to GLI-domains.

      The local mapping system for each GLI-domain only needs to
      respond to queries from within that GLI-domain, about
      hosts in that GLI-domain.

      Below I give an example of 64 bit Identifiers, with a
      GLI-domain being defined solely by a 32 bit value for
      the most significant 64 bits, which therefore gives each
      GLI-domain up to 2^32 Identifiers which it can use
      however it likes.  This is because the global mapping
      system doesn't can't just return the same Locator(s) for
      every Identifier in this 2^32 subset - it must be able
      to return any one or more Locators for each Identifier.

      There is nothing in detail in the current design about the
      mapping system, but I will assume that the map reply doesn't
      necessarily just apply to the one value of Identifier for
      which the query was made, but potentially to a contiguous
      range of values including the queried value.  The most likely
      way of specifying this would be with a binary boundary prefix.

      It is my clear understanding of GLI-domains as described
      in the current design that they can only contain hosts
      with Identifiers which belong to the one sub-range of the
      Identifier values which is what defines each GLI-domain.

      It is implied in the current design that a single host can
      have two or more Identifiers, but it is clear from the
      current design that the above sentence is true - which means
      that no host in a given GLI-domain can have an identifier
      from any other GLI-domain.

      Therefore, the one or more (two at least for robustness)
      authoritative query servers which respond to global
      queries for each GLI-domain cannot be any of the GLI-domain's
      hosts - because those are only reachable after a mapping lookup
      using Identifiers of this GLI-domain.

          (I can imagine a different form of GLI-split where
           "GLI-domain" means a defined contiguous range range of
           Identifier values and a new concept of "GLI-supportive
           networks" is for any network with GLI-Split hosts in it.
           Then, hosts with Identifiers from various GLI networks
           could be in the same network, and some or all could
           have Identifiers from two or more GLI networks.

           This, in principle, would enable a GLI-domain to run
           its own authoritative mapping servers for the global
           mapping system in its own hosts, one of its one or
           more physical networks.

           But this is different from the GLI-Split proposal and
           raises a number of questions about administering
           the GLI-gateways of each "GLI-supportive network".)

      So the the globally authoritative query servers for each
      GLI-domain's range of Identifiers need to reside in some
      other GLI-domain.  This is not mentioned in the current
      design.

      The security, robustness and speed of these mapping systems
      are crucial to the performance of a GLI-Split enhanced
      Internet.  So the exact design of these mapping systems, and
      their ability to scale to the large query volumes and the
      vast number of Identifiers, is a vital factor in being able
      to assess the practicality of GLI-Split.  The proposal refers
      to some DHT proposals and LISP-ALT's mapping system as examples
      of how both the local and global mapping systems could be
      implemented.  I think the global one is the one which really
      matters for scaling.

      The local mapping system can and probably must be run by
      hosts in the GLI-domain - but if these are only reachable
      by looking up the local mapping system to find their Local
      Locators, then there appears to be a circularity problem.

      The query rate for each GLI-domain's part of the global
      mapping system would depend in large part on the caching time
      which is  presumably returned with each map reply.  No details
      have been given of this caching time, which would also directly
      affect the ability of the system to respond rapidly to changes
      in which Locators are used for a host with a given Identity.

      A short caching time is particularly important with GLI-Splits
      support for Mobility, since the MN (Mobile Node) relies on
      signed (or nonce-authenticated) messages to its CHs (Correspondent
      Hosts), and the initial exchanges of keys or nonces can only
      proceed when the MN is using a Locator which is returned by
      the global mapping lookup of its Identifier.

      So a long caching time means a MN may not be able to establish
      such nonces or keys until the cache time has expired, if it
      has just moved to a new network, and so acquired a new Identifier
      in that GLI-domain.  (I think this whole approach to mobility is
      questionable - more on this below.)


  3 - The provision of GLI-gateways for each GLI-domain at either the
      CE router, the PE router or some  other router within the ISP.
      All packets flowing in and out of the GLI-domain via its one or
      more ISPs must pass through the GLI-gateway, which may alter the
      source or destination address, and add or delete a new extension
      header called an "Address Buffer" (AB).

      These GLI-gateways supposedly operate in a stateless fashion
      (page 25, second line) - but there is significant state in the
      Figure 5 "NAT" scenario and in the "locator gleaning" scenario
      of Figure 6.  However, I argue below that neither should be
      part of GLI-Split.

      These GLI-gateway devices, or extra functions in routers, present
      cost, reliability and scaling difficulties - in respect of traffic
      volume.  They are required to query the local mapping system,
      and to hold packets until a reply arrives.  This may involve
      resending mapping requests.


My attempt to understand address bits and Identifier values
-----------------------------------------------------------


Figure 2 represents the use of the 128 bits in the IPv6 address, but
there are no exact details of how long the various fields are.  For
the purposes of this discussion, I will assume:

  GLI prefix            8 bits    0 - 7           8 bits so far

  L/G                   1 bit     8               9

  LL/GL                38 bits    9 - 46         47

  GAP                   1 bit     47             48

  Identifier           64 bits    48 - 111      112

  Checksum             16 bits    112 - 127     128

My understanding is that each ISP which supported GLI-domains would
advertise its own prefix in the DFZ which gave it part of the
GLI-Split space.  Let's say each such ISP needs to be able to
accommodate 4 million GLI-Split-using EUNs (GLI-EUNs), so within each
such prefix they advertise, they need 22 bits of address space so they
can split it up internally for the GLI-gateways of 2^22 GLI-Split-using
EUNs.

Therefore (with the above assumptions, which are mine - not in the
GLI-Split proposal), the length of the ISP's GLI-Split prefix would be
47 - 22 = 25:


  GLI prefix            8 bits    0 - 7           8 bits so far

  L/G                   1 bit     8               9

  Enough of the LL/GL   16 bits   9 - 24         25
  to uniquely identify
  each of potentially
  2^16 ISPs.

(This is probably not enough ISPs - but the assumptions are just for
exploring my understanding of the proposal.)

Between ISPs - in the DFZ - GLI-Split packets always travel with
source and destination addresses in the Global form (Figure 2).

Each GLI-domain has one or more GLs (Global Locators).  These are
derived from whichever ISPs it is using.  A given ISP-A will have a /25
advertised in the DFZ, and will assign to the GLI-domain a particular
/47 GLI-prefix within that.  This is basically GL (Global Locator) to be
used with the GLI-gateway between this ISP and this GLI-domain.

If this is the only ISP the GLI-domain is using, then this GLI-domain
has only one Global Locator (GL).

If the GLI-domain chose another ISP instead, it would use a completely
different GL, involving bits 9 to 24 being whatever was assigned to
that new ISP and the bits 25 to 46 being which of this new ISP's 2^22
/47 prefixes the new ISP assigned to this GLI-domain.

The GLI-domain would have a particular range of the 64 bit ID "address
space" for its own permanent use.  These are not IP addresses, but a
64 bit range of IDs which is divided up in order that GLI-domains now
and into the indefinite future will have enough unique IDs for all
their hosts.

A simple way of doing this would be to allow for 2^32 GLI-domains and
give each one of them 2^32 of these IDs.  So within the ID range, each
GLI-EUN would have a range where the most significant 32 bits were
fixed and the least significant 32 bits variable.

This could be done on a sequential basis the first applicant gets the
2^32 IDs with their 32 most significant bits set to 0..0.  The next
gets 0..1, the next 0..10 etc.

Then, the global mapping system would accept a 64 bit ID in its query,
and use the most significant 32 bits to look up an entry for each
GLI-domain.  Then, this must be used to find one or more authoritative
query servers for this GLI-domain.  As with DNS, the reply might be to
tell the querier where those authoritative query servers are, or perhaps
to find the mapping, cache it and send it back to the querier.  But the
latter approach should involve scaling difficulties in this initially
responding global query server.

The global query server system needs to be able to return different
mapping for each Identifier.

It is not stated in the current proposal, but I think the map reply
should not just be applicable to the particular Identifier in the query,
but could be made to apply, in the querier's cache, to a contiguous
range (such as a binary boundary prefix) of Identifier values.

As previously noted, as far as I know, the authoritative query servers
for each GLI-domain's mapping needs to be hosts in one or more
GLI-domains other than the one they are authoritative for.

So they would need to be run by a separate company, and the GLI-domain
needs to communicate a potentially large and rapidly changing set of GL
mapping information to these one or more authoritative query servers.

This raises scaling and security problems.  It also raises questions
about the GLI-domain paying some other organisation to run their
authoritative query servers, since the task is likely to be burdensome
in terms of query and response packets and the task of storing the
particular GLs, priorities and load-sharing information for each
Identifier value, or groups of Identifier values.



Hierarchical GLI-domains?
-------------------------

The easiest way I can understand GLI split is as follows:

  A "GLI-domain" entails all of:

  1 - It is a particular physical routing system, with one or
      more GLI-gateways, each one being the sole link to a
      given ISP.  Each GLI gateway advertises a prefix of
      space - a /47 in my example - and a small proportion
      of the addresses within this space match the
      Identifiers in the range this GLI-domain has.

  2 - A single contiguous range of Identifier values which
      belong, permanently, to this GLI domain.

  3 - The above range is defined as a binary boundary prefix -
      such as a /32 within the 64 bit range of Identifiers.

  4 - Therefore, in the global mapping system, this GLI-domain's
      range of the Identifier space is defined by the integer
      of the prefix and the integer length of the prefix.

This allows for each GLI-domain to have differing prefix lengths, which
is messy.

If you further agree:

  a - There are never going to be more than 2^32 GLI-domains.

  b - No GLI-domain will ever need more than 2^32 Identifiers

  c - There is no problem providing 64 bits for Identifier in the
      GLI-Split division of IPv6 address bits.

then you might accept a further three points:

  5 - 64 bits will be used to specify the Identifier.

  6 - Every GLI-domain has 2^32 Identifiers.

  7 - There are 2^32 GLI-domains.

  8 - Therefore, each GLI domain is uniquely identified by a
      32 bit number.

Now the Identifier space can be assigned in these 2^32 Identifier
chunks, in any order, such as on a first-come-first served basis.
Identifiers have no geographic or organisational meaning, and packets
are not routed according to them, so they can in principle be assigned
in any fashion.

In this case, there is no such thing as  "hierarchical GLI-domains".

However, the proposal includes (2.2.3):

   HIP-like IDs may be also supported using the concept in [18].

I am not going to try to imagine this.

   GLs and IDs are hierarchically assigned to ISPs and organizations
   like IP addresses are today assigned in the Internet.

I don't understand the meaning of hierarchy here.

I can't see how you could have hierarchical GLI-domains according to my
current understanding.

In hex, here is an example GLI-domain range of Identifier addresses,
using my above assumptions:

         1  2   3  4  4  5  64
   0  8  6  4   2  0  8  6 /

   00 00 01 02  xx xx xx xx

This is for the GLI-domain uniquely identified by decimal "258".  This
could be thought of as "245 /32".

This could be used for a given physical network, which might be in an
office, a city or perhaps spanning a country or the entire Earth.
Generally, it will be a physical network in a given city - and in a
particular office, factory or single geographic site within that city -
since end-user networks can't easily afford dedicated links between
multiple sites.

Let's say a company in Melbourne Australia gets this GLI-domain of
Identifier addresses and uses it in its fruit-juice factory and office
in a Melbourne suburb.  It uses a DSL link to one ISP and an HFC cable
link to another and is nicely multihomed - at least its GLI-split hosts
are multihomed with the GLI-split hosts of other network.  GLI-split
can't support multihoming with conventional IPv6 hosts in other
networks, and I am not sure if it can multihome any IPv6 hosts it has in
its own GLI-domain with the GLI-hosts in other GLI-domains.

Business expands and the company builds a factory closer to the
fruit-growing areas in Mildura, 500km to the north-west.

In my understanding, it needs to get a second GLI-domain to use at the
new site.  There it will have links to two other ISPs, perhaps with DSL
and HFC again.  The GLI-gateways in Mildura will have different and
unrelated GL prefixes from their respective ISPs than the GLI-gateways
of the Melbourne factory.

If the company had 1000 branch offices all over the world, each using
GLI-Split, it would need 1000 GLI-domains on the same basis.

There's no reason for the 32 bit numbers which define these multiple
GLI-domains to be related in any way.


However, if your idea is that the first GLI-domain would be split
hierarchically into smaller ranges of Identifiers for the Mildura and
other factories and offices, then I think this raises some problems.

There's no way the Melbourne office could retain the original GLI-domain
of 2^32 Identifiers and let the Mildura factory use half of these, or
any other subset.  This is because the global mapping system needs to
return two Locators for each Identifier.  If an Identifier is used in
Mildura, its Locators will be within the prefixes given by the Mildura
ISPs - not those given by the Melbourne ISPs.

I could imagine the /32 prefix which defines the original "GLI-domain"
being split into two /33s, or into 1024 /42s (ready for a thousand
branch offices), each of which still has 2^22 Identifiers each.

But I can't see how you could have a range of addresses such as:

  "245 /32":    00 00 01 02  xx xx xx xx

really be a "GLI-domain" while it was split up to be used in other
"GLI-domains" - since each GLI-domain must have its own internal
mapping system and its own unique GLI-gateways.


If you have this multi-level, variable-length-prefix approach to
GLI-domains, then I think it will make the global mapping system more
complex.  There's no need for hierarchy, since there's plenty of
Identifier space - and Identifiers have no role in routing packets.


I will assume for now that all GLI-domains have a /32 of Identifier space.


Rewriting addresses
-------------------

GLI-Split is an address-rewriting system where parts of the source
and destination IP addresses are rewritten as the packet is processed
and forwarded.

One set of transformations occurs in the stack of the GLI-upgraded
hosts.  Two other sets occur in the GLI-gateways.

The results include:

  1 - Packets in the DFZ - that is those flowing:

        a - From a GLI-domain to another GLI-domain.
        b - From a GLI-domain to an ordinary IPv6 network.
        c - From an ordinary IPv6 network to a GLI domain.

      all have whichever addresses are GLI-Split addresses using GLs
      - Global Locators.

      They may also have an Address Buffer extension header.

      No packets exist in the DFZ with Identifier forms of GLI address
      or Local forms.  (See Figure 2.)

  2 - Packets in the GLI-domain may have GLI-split addresses using
      LLs (Local Locators) or GLs (Global Locators).   (See Fig 4.)

      They may also have an Address Buffer extension header.


  3 - Below I am going to use "application" to include the
      application and the TCP or UDP transport layer.

      Packets as presented by the stack to applications - and by
      applications to the stack - in general (always?) have neither
      LLs or GLs, so their addresses are of the Identifier type.
      (See Fig 2 and 4.)  But after a DNS lookup, or perhaps a
      referral, the address used by the application may have a
      LL or a GL, so Fig 4 can't be a complete description.

      I think the current proposal needs to be clarified, since
      Fig 4 indicates applications only see addresses in the
      "Identifier address" format - with bits 8 to 47 (in my
      example) zeroed.  However 2.3.1 indicates the application
      gets an address in Global form, with the GAP bit set.

      This makes it hard for me to imagine how GLI-Split works,
      even for the most basic operations.


There are three classes of host:

  1 - GLI-upgraded hosts in GLI-domains.

  2 - Ordinary IPv6 hosts in GLI-domains.

  3 - Ordinary IPv6 hosts (or GLI-upgraded hosts not using their
      GLI functions) in ordinary IPv6 networks.

Here I focus on a basic communication between a GLI-upgraded
"initiator" HA host and a "respondent" host HB, which is also
GLI-upgraded.  Later I consider if just the initiator or just the
respondent is GLI-upgraded.

I assume the initiator and responder are in different GLI-domains, so
the packets need to traverse GLI-gateways as the leave one GLI-domain
and enter the other.

I will assume these are single-homed networks for each host and that
each such network (and therefore the network's GLI-gateways) only serve
a single GLI-domain.  I also consider security arrangements where the
initiator may be an attacker trying to impersonate HA.

I am using the term "application" to include the transport layer, since
applications choose the IP address of the other host for TCP or UDP
communications, and know their own host by the one IP address (or one
of multiple IP address) for the host they are running in.

There is a difficulty understanding the current proposal.

On one hand, and initiating application in a GLI-upgraded host HA may
get an IP address for HB via DNS lookup or referral.  In the former case
and in some of the referrals this would be a Global address, with the
GAP (g) flag set.  However, referrals could be from another application
which only saw the Identifier version of HA's address.

Figure 4 shows the initiator application on the left creating a packet
with the destination address being in the Identifier format.  But this
doesn't depict a typical situation from DNS lookup or some referrals,
where it gets one of potentially multiple Global with (g) format
addresses for HB.

The following exploration assumes it started with a referral from
another application, or from stored state when this application ran
previously, and the address of HB is in Identifier format.

Later I consider if the HB address used by the application was in Global
format.  When the application uses such an address as a destination for
a packet, the GLI-upgraded stack ignores its GL component, so the
processing is identical to the situation where the application is using
a destination address in Identifier format:  bits 8 to 47 inclusive (in
my example) zeroed.  However the result is not the same from the point
of view of the application.


   On page 6, 2.3.2, this sentence applies to our example, since
   HB's Identifier is not part of HA's GLI-domain's range of
   Identifiers.  This sentence describes HA's stack, not its
   application, doing this:

      Then, the GLI-node requests the global MS (mapping system)
      which returns a set of global GLI-addresses.

   The proposal would be easier to understand if it was more explicit
   about which part of a host is performing the various tasks.

   Does the global mapping system return complete GLI IPv6 addresses,
   with GLs built in - or does it return just the GLs and flags?  I
   can't understand why the former approach would be needed, since the
   host stack already has the 64 bit Identifier bits.  However, maybe
   the global mapping system would return complete 128 bit IP addresses,
   with these same 64 Identifier bits, and with the checksum bits
   (really TCP checksum compensation bits) already computed.  If so,
   then I assume HA's stack will reject any such IPv6 addresses if the
   64 Identifier bits don't match those of HB.  This text in 3.1.2
   indicates that the lookup returns complete 32 bit addresses:

       "... one of the returned global GLI-addresses of ID 3 as
        destination address for communication with node 3."

   In this simple example, HB is in a single-homed GLI-domain, so
   there is no choice to be made between multiple GLs.  (I am not
   sure how this choice would be made for load sharing or choosing
   the currently best ISP if HB's GLI-domain was multihomed.)

   My best guess is that the application presents the destination
   address to the stack as shown at the top of the top left box in
   Figure 4:

      Dst: ident. address

   This means a 128 bit address with bits 8 to 47 inclusive (in my
   example) zeroed.

   According to 2.3.2, the bits 8 to 47 are ignored, and are
   rewritten with the Locator returned by DNS in response to HA's
   stack sending a query with HB's 64 bit identifier.

   We are now up to 3.1.2.  HA is like the host "1" in in the left
   GLI-domain of Figure 3.  The destination address is depicted as
   "N.3" and in our examples this means the Global Locator of HB's
   GLI-domain's GLI-gateway, without the GAP bit set (not "(g)") and
   with HB's Locator - and then with the last 16 checksum compensation
   bits set to a value so the checksum of the whole set of 8 16 bit
   words is zero.

   The application created the packet with the source address being
   (Figure 4):

      Src: ident. address

   This is the application's idea of its own IP address a GLI address
   with zeros where the Global or Local Locator might be.

   I don't see how all applications can be expected to work when they
   do a DNS lookup of their own FQDN and get an address with a
   Global locator, yet they are configured to have a different address -
   an "Identifier" form, with all zeroes in place of that Locator.

   Surely some applications do this to test whether the host they are
   running on is the one with an IP address returned from a particular
   FQDN DNS lookup.   Such an application would fail on a GLI-Split
   host.

   HA's GLI stack rewrites the source address to have HA's Local
   Locator.  Then it sends the packet to the local routing system of
   the GLI-domain.

   The packet goes to the GLI-gateway of HA's GLI-domain (there is only
   one in my simple example, since both HA and HB are in singlehomed
   GLI-domains).  The GLI-gateway over-writes the source address of the
   packet, which was HA's Local format address, with that of HA's
   Global format address.  This means that bits 8 to 47 are
   overwritten.  ("substitutes" is the word used for this overwriting.)
   The destination address was already that of HB's Global format
   address, as set by HA's stack.

   The DFZ contains /25 prefixes for each ISP's GLI prefix, and the
   DFZ routers forward packet to the BR of the ISP which HB's GLI-domain
   is using.  Then the ISP's routers forward the packet to the
   GLI-gateway of HB's network.

   At HB's GLI-domain's GLI gateway, the destination address is partly
   overwritten, so bits 8 to 47 now contain the Local Locator (LL)
   of HB.

   The packet is delivered to HB in this form, and now we turn to
   diagram 4.  The section on the right shows the just arrived packet
   having bits 8 to 47 inclusive zeroed, for both the source and
   destination address.

   So far, so good.  The application (or TCP layer or whatever) in
   HA has prepared a packet with its Identifier format address in the
   source and either the Identifier form of HB's address in the
   destination field.

   HA's stack ignored the bits 8 to 47 of both (which were zero
   anyway), and wrote in:

      Destination:  HB's Global Locator GL (with the GAP flag clear)
      Source:       HA's Local Locator  LL (with the GAP flag clear)

   HA's GLI-domain's GLI-gateway changed:

      Source:       HA's Global Locator GL (with the GAP flag clear)

   HB's GLI-domain's GLI-gateway changed:

      Destination:  HB's Local Locator  LL (with the GAP flag clear)

   HB's stack changed:

      Destination:  HB's bits 8 to 47 = 0 = Identifier format.
      Source:       HA's bits 8 to 47 = 0 = Identifier format.

   So the packet got from HA's application to HB's application with
   any Global or Local locators in its address fields zeroed.

   As with today's IPv4 and IPv6 naming model and routing system,
   HB's application can't be sure that this packet really was sent
   by HA.

   Now, I will assume that HB's application replies, by creating
   a packet:

      Destination:  HA's address in Identifier format.
      Source:       HB's address in Identifier format.

   To follow the explanation in the 2nd para of page 8, we need to
   consider the right-most host ("3" in diagram, HB in my example)
   as being the left host in Figure 4.

   Now, as long as HB's stack does as described above (2.3.2):

      Then, the GLI-node requests the global MS (mapping system)
      which returns a set of global GLI-addresses.

   I think the system will work OK.

   HB's stack will ignore the bits 8 to 47 of both source and
   destination address (which are zero in this example anyway) and
   write in:

      Destination:  HA's Global Locator GL (with the GAP flag clear)
      Source:       HB's Local Locator  LL (with the GAP flag clear)

   The same pattern should be followed for this reply packet:

   HB's GLI-domain's GLI-gateway changes:

      Source:       HB's Global Locator GL (with the GAP flag clear)

   HA's GLI-domain's GLI-gateway changes:

      Destination:  HA's Local Locator  LL (with the GAP flag clear)

   HA's stack changes:

      Destination:  HA's bits 8 to 47 = 0 = Identifier format.
      Source:       HB's bits 8 to 47 = 0 = Identifier format.

   This is how HA's application receives the reply packet.

Between two upgraded hosts, I think this will work fine, but note the
extra work which needs to be done compared to today's IP arrangement.  I
am also concerned that the hosts are configured with a different IP
address from what is returned by DNS for their FQDN.

If the HA application got HB's address in the Global form, either via a
DNS lookup or a referral, then I understand this also has the GAP bit
"(g)" set.

Then, does HA's GLI-stack overwrite this Global Locator and GAP bit?  I
recall it does, but I can't easily find where in the proposal this is
specified.

I think it would be good to list all the transformations a GLI stack
could make to source and destination addresses, when accepting them from
an application to send the packet to the local network, or when
receiving a packet from the network and preparing it for the application
- what types of address and GAP bits are valid for these four situations
and what does the stack do with them.

Likewise, it would be good to have a list of all the transformations a
GLI-gateway could make, including listing things which are not expected,
such as packets arriving from the DFZ with an AB extension header.


Just looking at this basic packet exchange, here is the work which must
be done with GLI-Split.  Some steps are labelled "F" or "LC".

          F  = extra work which is fixed each time - the first and
               subsequent packets.  However, some of these are
               a GLI-gateway writing a Local Locator, which will
               probably involve a lookup into the local mapping
               system, and subsequent caching.

         LC  = extra work which at first is a global mapping system
               Lookup followed by Caching the information, and then
               operating from that cached information (which itself
               involves an internal lookup into the cache) - and
               cache management to eventually delete the cached
               information.

This is assuming the mapping lookup is a direct process, not in itself
depending on mapping lookups to reach an authoritative query server.
There are no details of how GLI-Split would implement the global mapping
system, but even if it is as fast as possible, this is a major challenge
and there will delays due to the globally distributed nature of the
system and the chance of lost query or response packets.

  1 - HA's application gets HB's IP address as a referral or via
       looking up an FQDN which returns this address.  The resulting
       packet uses HB's Identifier (zeroes) form address or Global
       Locator +(g) format for the Destination address, and HA's
       HA's Identifier (zeroes) format address for Source.

 LC2 - HA's stack does a global lookup on HB's Identifier and writes
       the resulting Global Locator into the Destination address.

  F3 - HA's stack writes HA's Local Locator (LL) into the Source address
       and sends the packet.

   4 - HA's GLI-domain's local routing system forwards the packet to
       the GLI-gateway of that network.

  F5 - The GLI-gateway writes the Global Locator (GL) of HA's network
       into the Source address and forwards it towards the DFZ.

   6 - HA's GLI-domain's ISP, the DFZ and HB's GLI-domain's ISP forwards
       the packet to the  GLI-gateway of HB's GLI-domain.

  F6 - That GLI-gateway writes HB's Local Locator into the destination
       field.

   7 - HB's GLI-domain's local routing system forwards the packet to HB.

  F8 - HB's stack zeroes bits 8 to 47 of both Source and Destination
       addresses.

   9 - HB's stack presents the packet to HB's application - which
       generates the reply packet.

LC10 - HB's stack does a global lookup on HA's Identifier and writes
       the resulting Global Locator into the Destination address.

 F11 - HB's stack writes HB's Local Locator into the Source address and
       sends the packet.

  12 - HB's GLI-domain's local routing system forwards the packet to
       the GLI-gateway of that network.

 F13 - The GLI-gateway writes the GL (Global Locator) of HB's network
       into the Source address and forwards it towards the PE router of
       that network's ISP.

  14 - HB's GLI-domain's ISP, the DFZ and HA's GLI-domain's ISP forwards
       the packet to the GLI-gateway of HA's GLI-domain.

 F15 - That GLI-gateway writes HA's Local Locator into the destination
       field.

  18 - HA's network's local routing system forwards the packet to HA.

 F19 - HA's stack receives the packet and zeroes bits 8 to 47 of both
       Source and Destination addresses.

  20 - HA's application receives the reply packet.


For today's arrangement, the work is (with the same step numbers):

   1 - HA's application gets HB's IP address as a referral or via
       looking up an FQDN which returns this address.  The resulting
       packet uses HB's and HA's IP address for Destination and Source.

   3 - HA's stack sends the packet.

   4 - HA's network's local routing system forwards the packet to
       the PE router of HA's ISP.

   6 - HA's network's ISP, the DFZ and HB's network's ISP forwards the
       packet to the CE router of HB's network.

   7 - HB's network's local routing system forwards the packet to HB.

   9 - HB's stack receives the packet and HB's application generates
       the reply packet.

  11 - HB's stack sends the packet.

  12 - HB's network's local routing system forwards the packet to
       the PE router of that network's ISP.

  14 - HB's network's ISP, the DFZ and HA's network's ISP forwards the
       packet to the  CE router of HA's network.

  18 - HA's network's local routing system forwards the packet to HA.

  20 - HA's application receives the reply packet.


In any CEE architecture, during the initial exchange of packets (SYN and
SYN-ACK, for instance, with TCP) there usually needs to be two extra
global lookups compared to today's IP arrangement - LC2 and LC10 in the
above example.  The second one (LC10) is not required, in principle, if
the responding host doesn't care about the identity of the host which
will receive its reply packet - and an many cases with which it will
continue a communication session with.

With ILNP, I think the application in the responding host is responsible
for deciding whether to do this second look-up.  Since ILNP only works
(or works fully?) with applications written for ILNP, the application
can make this decision, and so potentially not do the second lookup.
For instance, if the respondent was a simple query server like a DNS
server, then it makes no difference what the Identity of the host is
which will receive the reply packet, so there is non need for second lookup.


An application in the respondent host (HB above) - either using a a
normal stack or a GLI-Split stack - doesn't know for sure which host
sent the packet it just received.

An application running on an ordinary stack can assume something important:

  The reply packet will not go to an host other than the one with
  the Identity of the packet's destination address.

The only way GLI-Split can ensure the same is true for the respondent
application is to do the second lookup - LC10.

Since GLI-Split works with unmodified IPv6 applications, there is no way
the GLI-Split stack can know whether the application assumes the packet
it sends can only go to a host with the Identity of that destination IP
address.  Therefore, the GLI-Split stack (when handling a packet the
application wants to send, with a GLI address in the Destination) must
always do this second mapping lookup of the Destination's Identifier,
and write into the address the one Locator which is returned by the
mapping lookup, or choose one if multiple are returned.



So we can see that compared to ordinary IP, with GLI-Split (or, I think,
any other CEE architecture - any system which applies "Locator/Identity
Separation" to the IP layer) it is mandatory to do one and often two
global lookups before the initial packet exchange can be completed.   Of
course, maybe neither would be required, due to the information already
being cached.  But we must think about the frequent and typical
situation of communications involving hosts which are not covered by
whatever information is already cached.

LC2 and LC10 are both global lookups by hosts.  This places load on the
hosts in terms of CPU power and memory for processing, caching, timing
out if the reply doesn't come in a certain time etc.  It also involves
the host sending and receiving at least two extra packets.

So what was a 2 packet exchange with the current IP system now involves
at last 6 packets, two pairs of which are to and from the global mapping
system.

If the host is to achieve these mapping lookups with a single query and
response packet, then the query needs to go to a local resolver, which
does all the work required to get a reply from an authoritative query
server, and then caches the results to save this trouble if and when
some other host makes the same sort of query.

This sort of lookup is most likely to resemble a DNS lookup, unless some
more complex (and I think arguably slower and less useful) arrangement
such as LISP-ALT is to be used.  At present, the GLI-Split proposal
simply refers to Distributed Hash Table mapping proposals and to LISP-ALT.

There is no global mapping system which can instantly respond to
queries.  There always needs to be a chain of events finding one server,
then the next, etc. until the authoritative one can be queried.
(Caching in some DNS-like servers can be used to collapse this, but that
creates scaling problems and difficulties with the short caching times.)

So GLI-Split clearly involves more delays and work for all hosts than
today's IP arrangement.  Other CEE architectures would be much the same,
as far as I know.

The important comparison is with CES architectures.

With LISP-ALT, there are two similar global query server lookups - not
by HA and HB, but the ITRs which handle the packets sent by these hosts.

This is arguably better than GLI-Split, since it avoids hosts having to
do this work.  Also, the ITRs have a better chance of having the mapping
already cached than any host, since the ITRs serve multiple hosts.

Hosts can be on slow, less than reliable, wireless links - and I think
we really want to avoid burdening those already busy and perhaps
congested links with easily dropped UDP-based mapping queries and
responses.  Also, with LISP-ALT, the ITR caches the mapping information
for the end-user network EID prefix and so in future, other hosts in the
same catchment area may not need to wait for the ITR to lookup and gain
mapping information.

Still, with LISP-ALT - even if it worked supremely efficiently - the
ITRs are relying on a global query server system which frequently
involves significant delays and higher risk of lost packets.

With Ivip, or with APT (no longer under development) there are likewise
two mapping lookups.  However, these are served within a few tens of
milliseconds, and with much greater reliability, than any global mapping
system, such as is used with LISP (apart from LISP-NERD, no longer under
development) or with GLI-Split or any other CEE proposal.

Ivip (and APT) would introduce only slight and insignificant delays to
this initial exchange of packets.

LISP-ALT would frequently introduce significant delays.

So would GLI-Split (and I guess other CEE architectures) - with the
additional problem of the host's having to make the queries, get the
responses and cache the information.


There are other basic scenarios to be considered compared to today's IP
arrangements:

Here is a table of the various combinations of host scenarios for the
basic two-way packet exchange.

   N = Normal IPv6 host, normal IPv6 network.
   H = Half-way to GLI:  Normal IPv6 host in a GLI-domain.
   G = GLI-Split: GLI-Split host in GLI-domain.


HA    HA's      HB is:          IPv6     IPv6      GLI
is:   network:  HB's network:   IPv6     GLI       GLI

IPv6  IPv6                      NN       NH        NG

IPv6  GLI                       HN       HH        HG

GLI   GLI                       GN       GH        GG


NN is the current IP arrangement.

GG I have analysed above.

I haven't had time to think about the extra work in the other 7 cases,
though I guess these would be similar:

  NH ~= HN     NG~= GN    HG ~=GH


Further comments
----------------

Sorry these are not very organised.


"Locator Gleaning"
------------------

I think the whole section 3.8.1 and Figure 6 is mistaken and should be
removed, for a number of reasons:

  1 - I don't recall where else in the proposal a GLI-gateway is
      required to use a mapping which returns a Global Locator of
      some host outside its own GLI-domain.

  2 - Even if it did, this "locator gleaning" idea is obviously insecure
      and so whatever purpose it might serve would be performed by
      what is currently referred to as the "countermeasure".  If that
      really is needed, give that a proper name and explanation, and
      point out that the GLI-gateway must do the lookup, since it
      can't rely on using Locators from incoming packets, which might
      be spoofed.

  3 - I think this whole section is a result of copying from a "locator
      gleaning" scenario of an ITR/ETR combination box in LISP.

      LISP has nothing to do with GLI-Split.

      LISP is not a "Locator/Identifier Separation" system.  It is a
      Core-Edge Separation architecture.  GLI-Split and other
      Core-Edge Elimination architectures do genuinely implement
      "Locator/Identifier Separation".  The phrase LISP is an acronym
      for is a misnomer.

This whole section is confusing and I think is irrelevant.


The diagrams, in general
------------------------

I think the diagrams and explanations are generally good, but what is
missing is the actual processing of packets by the stacks.

The current diagrams show the packets being moved and rewritten by the
GLI-gateways, and what emerges from and is received by the hosts.  We
also need to see clearly what the GLI stacks do to the addresses of just
arrived packets before passing them to the application (or transport
layer or whatever) - and what they do to addresses of packets the
application wants to send, before they are sent.

For instance, I think the following text is confusing (page 8).  Node
(AKA host) 3 has just received a packet with the source address including:

     Global Locator = E
     Identifier     = 1

      "When GLI-node 3 sends a response back to node 1, it uses
       the global GLI address of node 1 that it received in the
       first packet as destination address and its own local
       GLI-address as source address.

But why does node 3 send a packet with

     Global Locator = F
     Identifier     = 1

?

According to the above sentence, the reply packet should be addressed
to "E.1".

I thought that the GLI-stack ignored the Locator bits, and looked up, or
used cached information, to use the destination Identifier to return one
of potentially several Locators (Global Locators in this case), which is
then written into the Destination field before the stack sends the
packet.  This is what is specified to occur in the left side of Figure4.

If this first sentence was followed, then host/node 3 could be
responding to a host, apparently with Identifier 1, but is actually
sending the reply packet to an attacker.  This sentence doesn't fit with
the more expansive but still incomplete, second sentence:

      "When both GLI-domains are multihomed, different GLI-
       gateways may be chosen. As a result, different global
       GLI addresses may be used in the two directions of a
       single communication session (see Figure 3)."

OK - but how could the host with Identifier = 3 know the host with
Identifier = 1 is multihomed without first doing a mapping lookup for "1".

Generally, when you refer to a host-stack or a GLI-gateway
"substituting" an existing set of Locator bits in an address with
another set of bits, shouldn't you also be noting that this will involve
a changed set of "checksum" bits?

I think it might be better to refer to these as "checksum compensation"
bits, because they exist to make all changes to addresses invisible to
the header checksum mechanism used in transport protocols headers.


Why in Figure 3 is host 3 on the right sending a packet with a GL Global
Locator in the destination field while in Figure 6 it sends it with
zeros in that part of the IPv6 address - as an Identifier format address
(Figure 4)?  I think the whole "Locator Gleaning" section should be deleted.

In 3.3.1, you refer to a "GLI-node" sending a packet with an Address
Buffer extension header.  It might be clearer if you noted that the
application does not do this (assuming non-upgraded applications) but
that the GLI-stack does so, for some reason - and then explain the
reasons.  Would this "To enforce a certain GLI-gateway for outgoing
traffic" be for upstream TE load sharing from the perspective of this
sending host's GLI-domain?  How would a GLI-host stack know to do this?


To aid discussion, here is how I want to depict addresses, not counting
the L/G or GAP flags:

      GGLLLLllllddddhhhhssss

  GG GLI 8 bits fixed.

  LLLL  16 bits specifying ISP                         ] Global
  llll  22 bits specifying GLI-gateway within this ISP ] Locator

  dddd  32 bits specifying the GLI-domain              ] Identifier
  hhhh  32 bits specifying the Identifier within this  ]
        GLI domain                                     ]

  ssss  16 Checksum compensation bits (my term)


      GGLLLLllllddddhhhhssss
        XXXXyyyyJJJJtttt

           Global Locator form of an address for host with Identifier

             JJJJtttt

           meaning this host is part of GLI-domain number JJJJ and
           within that GLI-domain, its lower 32 bits of the Identifier
           are tttt.

           This Locator is the prefix advertised by the yyyy'th possible
           GLI-gateway in the ISP whose GLI prefix is GGXXXX.


      GGLLLLllllddddhhhhssss
        XXXXyyyyJJJJuuuu

           Likewise, but for another host, (or perhaps the same
           host but with another Identifier) with Identifier:

             JJJJuuuu


      GGLLLLllllddddhhhhssss
        PPPPeeeeJJJJtttt

           A second Global Locator form of an address for host with
           Identifier

             JJJJtttt

           So this host is multihomed with at least two ISPs, and the
           second ISP is the one with prefix:

             GGJJJJ

           This Locator is the prefix advertised by the eeee'th possible
           GLI-gateway in this ISP.


GLI-Split can't multihome with an ordinary IPv6 host
----------------------------------------------------

Here is a significant critique of GLI-Split.

Figure 5 is intended to depict how a GLI host with Identifier 3 (on the
right) is multihomed via two ISPs, with two GLI-gateways M and N, can
multihome with an ordinary IPv6 host in an ordinary IPv6 network.

I believe this can't be done.

I haven't worked on whether host 3 on the right could multihome with an
IPv6 host on the left, if that IPv6 host was in a GLI-domain.

In section 3.4.2 (Figure 5) I understand the purpose of the Address
Buffer (AB) and the use of the (g) bit in the IPv6 addresses returned by
DNS.  Whichever GLI-gateway receives from the DFZ (this is the
left-to-right packet, the top pair of boxes) a packet (apparently) from
an ordinary IPv6 host (as can be seen by the source address not being in
a GLI prefix) with with destination Identifier = 3, the GLI-gateway will
attach an AB to the packet as it forwards it into the local routing
system.  The host with Identifier 3 receives the packet and the GLI
stack recognises the AB contains a global address of this host, with
the G bit "(g)" set.  This causes the stack to cache this address, and
will use it whenever an application in this host sends a packet to . . .
this is where it gets tricky.

     BTW, what happens if the address in the AB doesn't have
     its G bit set?  The explanation says the stack only acts
     as described because it is set.  Does it ignore the
     AB contents if the G bit there isn't set?  Is there a
     circumstance when this could occur?

     I assume GLI-gateways deletes any AB found in a packet
     arriving from the DFZ - otherwise an attacker could
     get a packet with a bogus AB to any GLI-split host.

The stack needs to associate the global address "N(g).3" with
"2001:db8::11" if it finds the application has generated a packet with
"2001:db8::11" as the destination address.

The addresses in the received packet as it is presented to the
application are as follows, after the GLI stack zeros the Locator bits
in the Destination address:

      Destination:  Host 3's address in Identifier format:

                      GGLLLLllllddddhhhhssss
                      GG0000000033333333ssss

                    Where the L/G, Locator and GAP bits are
                    all zero and the Identifier field contains
                    host 3's Identifier value.  I think the
                    GLI-Split notation for this is "ID.3".



      Source:       2001:db8::11

The application now creates a return packet:

      Destination:  2001:db8::11

      Source:       Host 3's address in Identifier format:

                      GGLLLLllllddddhhhhssss
                      GG0000000033333333ssss

                    AKA "ID.3".

and before the GLI stack sends the packet, it does some quite complex
transformations:

     1 - It takes the application-generated Destination address
         "2001:db8::11" and writes this into an AB it inserts
         after the IPv6 header.

     2 - It writes into the Destination address the base
         address of the N GLI-gateway.  This is from the
         cached information it associates with "2001:db8::11".

     3 - It writes this host's Local Locator into the source
         address.

The GLI-stack will do this for any packet the application generates
which has "2001:db8::11" as its destination address.

Then the GLI-stack sends the packet and the local routing system
forwards it to the N GLI-gateway, which advertises the its own /47 or
/48 prefix to the DFZ and to the internal routing system.

This GLI-gateway transforms the packet by:

     1 - Copying the contents of the AB into the Destination
         field, and deleting the AB.

     2 - Writing its own prefix address, which is the "N"
         Global Locator, into the locator field of the source
         address, and sets the G flag there too.

Then the GLI-gateway forwards the packet towards the DFZ and it arrives
in this form at the IPv6 host.

But it seems this is a change in stack behavior - which could persist
indefinitely - is based on a packet which could have come from an attacker.

Let's say the application involved sending a long stream of packets to
2001:db8::11 without getting any packets in return, or just occasional
return packets.  By some means such as that described above the GLI
stack had cached "N" as the prefix to write into the AB of packets it
was about to send.  So the 2001:db8::11 host receives a stream of
packets with their source address being N(g).3, as shown in the
right-to-left path of Figure 5.

Now, an attacker sends a packet with a spoofed source address:

       Destination:    M(g).3
       Source:         2001:db8::11

The M GLI-gateway does as described and the GLI stack in host 3 will now
have a cached address of "M(g).3" which it will associate with
2001:db8::11.  This will overwrite the previously cached association of
"N(g).3" with 2001:db8::11.

Consequently, the ongoing stream of packets will now be sent via the M
GLI gateway and the IPv6 host at 2001:db8::11 will receive these packets
with a source address totally different from what it is expecting.
These packets will not be recognised by the IPv6 stack or application.

So with a single packet, the attacker can clobber an ongoing
communication, until such time (which won't necessarily occur, since
perhaps the application protocol does not require it) when the
2001:db8::11 host sends a packet to "N(g).3", which will restore the
cached information in 3's GLI stack to its former state.

Its not just an attacker which could clobber an ongoing communication
like this.  The IPv6 host itself could easily send a packet to "M(g).3".
 Maybe the same application, or another application on the same host
could do this, for all sorts of reasons, such as getting this address by
a referral, or getting it from a DNS lookup.  The GLI-host could have
multiple DNS entries - and mistakes in DNS entries of other
organisations than the one host 3 is owned by could also result in the
IPv6 host at 2001:db8::11 sending packets to "M(g).3".

I think there is a fundamental problem with the process you are using
here.  The GLI stack controls the source address of all outgoing
packets, and it will change which source address it uses for all packets
going to a given IPv6 host - 2001:db8::11 - just on the basis of a
single packet arriving at one of the GLI gateways of the GLI-domain
host 3 is located in.  There is no method of authenticating those
packets as not being sent by an attacker - and it is easy to imagine
ordinary host behaviour by 2001:db8::11 causing such packets to be sent.

Assuming the GLI-Split host is multihomed, I conclude:

    1 - A GLI-split host can't be multihomed for communication with
        an ordinary IPv6 host.

    2 - The system needs to ensure that IPv6 hosts only get from
        DNS the address of the host via exactly one of its GLI-gateways,
        such as N in this example.  Therefore, the DNS must only return
        "N(g).3" when queried for host 3's one or more FQDNs.

          (I still think there will be trouble with some applications
           because the GLI-host's application's view of its own IP
           address does not match the IP address returned by DNS for
           the FQDN which points to this host.)

    3 - All packets going out of the host to ordinary IPv6 hosts must
        go out, from whichever GLI-gateway, with the source address of
        "N(g).3".  (I am not sure if the ISP to which the M gateway
        would allow this.)

    4 - If any packet arrives at any a GLI-gateway from the DFZ, with
        an ordinary IPv6 address, and is addressed to another of 3's
        addresses, such as "M(g).3" in this example, then the
        GLI-gateway (GLI-gateway M) must drop the packet and should
        probably send a  destination unreachable ICMP message to the
        sender.  Otherwise, the sending host would behave as if the
        packet was potentially deliverable to host 3 at this address.

        If the packet was delivered to host 3, the stack would be able
        to discern that it was sent by an IPv6 host to a disallowed LG
        address of 3, but it would not be able to present the packet to
        the application, since when it does so, the LG is stripped out -
        and the ordinary application which has no idea of GLI-Split,
        would then behave as if it could send a packet to the IPv6 host.
        If the application did send a packet to this IPv6 host, then
        than that packet would go out with the only allowed GL address
        for host 3, and the IPv6 host would not recognise it as being
        a response to the packet sent by the IPv6 host.

As far as I know you need to do all this.


Can a GLI-Split host multihome with an IPv6 host in a GLI-domain?
-----------------------------------------------------------------

I am not sure whether your proposal specifically addresses this.  There
is no chart of what benefits are provided for communications between the
various combinations of types of host.

Section 4.3 and Figure 8 depict one aspect of the above question.  This
involves a very complex looking "NAT" function, with stored state, in
the GLI-gateway, which contradicts claims elsewhere (I recall) that the
GLI-gateway's address rewriting is always stateless.

The diagram shows how the IPv6 host (11) in an IPv6 network can
communicate with an IPv6 host (4) in a GLI-domain.  It relies on the 11
host using an address for 4 which it gets from DNS or some other source,
with the Global Locator format, with the "(g)" (GAP bit) set.  But what
if there was some referral from the 4 host itself?  The 4 host's IP
address which host 4's applications know is the "Identifier" format of
the 4 address.  If that is sent to the 11 host, and the 11 host tries to
send a packet to this address, it won't get to the 4 host, because there
is no Global Locator in this address.

I think many applications would not work if the 4 host is receiving
packets with source Identifier of some host apparently in the local
GLI-domain: "n.41" while in fact the packets were sent by a real IPv6
host in another network, with address 2001:db8::11.

This explanation only works if the external, ordinary, IPv6 host (11)
initiates the communication.  There's no attempt to show how this could
work with host 4 initiating the communication.  Maybe the NAT
arrangement could support that too.

But NAT sucks - and this is IPv6, which is not supposed to suck!

NAT will make at least some applications fail.

Also, this explanation is just about communication.

It does not show that multihoming could be achieved.

It is impossible to multihome host 4 with host 11, since host ll only
sends packets to, and expects replies from, address "N(g).4".  If the
ISP of GLI-gateway N, or GLI-gateway N itself, fails, then there's no
way host 11 can get packets to host 4, since it has no way of sending
them via GLI-gateway M.

Here are the combinations:

  GLI-host in GLI-domain <--> GLI-host in GLI-domain

     Supports portability of Identifier, with no need to
     rely on IP addresses for session establishment or
     continuity.

     Supports multihoming, and I guess inbound TE.


  GLI-host in GLI-domain <--> IPv6 host in GLI-domain

     I have not had time to analyse this.


  GLI-host in GLI-domain <--> IPv6 host in IPv6 network.

     May be able to communicate in this <---- direction.
     Not sure about this ---> direction.

     No multihoming or inbound TE.



ICMP - Traceroute, Ping, PMTUD?
-------------------------------

How would traceroute work, considering the packet has different
source and destination addresses as it leaves the traceroute application
and is processed by the GLI stack, the outgoing GLI-gateway and the
GLI-gateway of the receiving GLI-domain - with ICMP packets coming back
with some kinds of transformations I have not had time to analyse?

Likewise Ping?

What about Path MTU Discovery RFC 1981 - Packet too Big messages?

Even if these got back to the sending host, they may not be recognisable
because the packet which generated them would have differing source or
destination addresses from the traffic packets sent by the GLI-Split
host.  Perhaps the stack upgrade could handle some of this, but how
could it do so securely?  An attacker may be able to more easily have
their bogus PTBs accepted if the GLI-Split stack's PMTUD implementation
has to be less fussy about authenticating the initial part of the
traffic packet which is returned in the PTB.


Why would an GLI-Split host or gateway ask the local mapping system...?
-----------------------------------------------------------------------

There is mention of sending a query to local mapping system and getting
a negative reply, or having that system forward the query to the global
mapping system.  However, each GLI host and gateway surely knows the
GLI-domain it is located in, than this *defines* the subset of the
Identifier values which can be used in this GLI-domain.

So why wouldn't the querier simply look at the Identifier and see
whether its most significant bits matched whatever prefix (such as
/32 in my example) which defines this GLI-domain?  Then the querier
would know to send the query to either the local or the global mapping
system.


Naming model
------------

The current 2 level Internet naming model is:

        Role             Level

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

I think GLI-Split implements a full "Locator/Identifier Separation"
naming model, in that different objects in different namespaces play the
roles of Identifier and Locator:


        Role             Level

        Text name  <---- FQDN
        Identifier <---- 64 bit (e.g.) Identifier field, in IPv6 address
        Locator    <---- 48 bit (e.g.) Locator field, in IPv6 address,
                         may be:

                               Zero  - no Locator.
                               Global Locator
                               Local Locator

The Identifier object and the Locator object are in separate namespaces
- and would still be so even if they had the same bit-length.

The Zero and Global Locators are two sub-ranges of the one 2^40 range of
values and each Global Locator is globally unique.  So they are all in
the same namespace.  The Local Locators are in a separate namespace for
each GLI-domain.

I think you should make it clear that a single physical host can have
multiple Identifiers.  This is implied in section 3.6.2:

 [ A node may offer different services: one requires best
 [ effort transport and another requires premium transport.
 [ The DNS name for the best effort service should resolve,
 [ e.g., to E(g).1 and the name  for the premium service
 [ should resolve, e.g., to F(g).10.

1 an 10 are different Identifiers, for the same host.

I think the explanations of how the stack processes incoming and
outgoing packets, and the state this involves, needs to be explained in
terms of how the stack knows which set of state to use, since this may
be different for the different Identifiers used in the same host.


I am opposed to this Locator/Identifier Separation model.  Firstly, it
is slower than the current model.  See:

   Today's "IP addr. = ID = Loc" naming model should be retained
   http://www.ietf.org/mail-archive/web/rrg/current/msg05864.html

Secondly, it is much more complex trying to organise communications when
the host has to worry about separate Locators and Identifiers.   This is
particularly the case with the mixed cases where one host know about
such things and the other doesn't, or is only partially able to know
about these things via support from the GLI-domain.

For instance, Loc/ID Separation doesn't work for hosts behind NAT.

In GLI-Split, the only way you can support ordinary IPv6 hosts being
able to send packets to and get replies from GLI-hosts is to have a
global DNS which returns a different IP address for the GLI-host than it
knows for itself.


PMTUD problems from Address Buffers
-----------------------------------

I think the optional use of ABs inside GLI-domains leads to PMTUD
problems.  I am not sure that GLI-Split can support PMTUD anyway, but
ABs certainly make it more complex, and would require GLI-gateways to
monitor all PTBs leaving the network, rewriting their contents to make
them valid to the sending host, and to have an appropriate MTU value
which is different from the value in the original PTB.

The workaround, as you suggest, is to have each GLI-gateway know the
lowest PMTU in the GLI-domain, including the optional use of ABs - and
to generate a PTB whenever a packet arrived from the DFZ which exceeded
this value.  However, this would lower the maximum size of all packet
sent to the GLI-domain, which is a general loss of efficiency.  Also, if
some paths and hosts were ready to do ~9kbyte packets and just one or a
few were not, then the GLI-gateways of the GLI-domain would all limit
packet sizes to 1500 or so, minus the length of the AB.


Multipath SCTP
--------------

I haven't looked at this in detail.  I understand an upgraded stack
would involve GLI-specific changes to the SCTP layer.


Mobility
--------

Mobile IP is very messy.

I have not tried to understand exactly how GLI-Split operates with MIP.

One of the big limitations of GLI-split is that a host can only retain
its Identity in a single GLI-domain, which means a single physical
routing system.

If there is a laptop which moves between branch offices, it needs a
different Identity in each one, since each branch office is its own
GLI-domain.

Likewise, when a cell-phone connects to a 3G network, it gets a totally
different and unfamiliar Identity from that network to the one it got
from the previous, and perhaps still current, connection via a WiFi link.

No MIP-based mobility or any other kind of mobility seems to be as
useful as the TTR Mobility architecture:

  http://www.firstpr.com.au/ip/ivip/TTR-Mobility.pdf

which would work well with Ivip, and could work with LISP.

This works for IPv4 and IPv6, and includes working with hosts which are
using MIP.  It works when the MN is behind NAT.  It works for all
protocols and for all hosts and applications.

The MN keeps its own one or more IPv4 addresses of SPI space (scalable
PI space) no matter where it connects, including from behind multiple
levels of NAT, or even using an address which itself is provided by TTR
Mobility.  There is no need for a mapping change when the MN gets a new
address - it just tunnels to its current TTR, which is generally nearby.

Rather than me fully critique GLI-Split and mobility, perhaps you could
read TTR Mobility and explain why GLI-Split would produce better results.


In section 3.8.2, you mention mobility involving Mobility Update
messages which are secured by nonces or in some way signed.

Assuming you are using nonces, or the hosts themselves establish
security credentials needed to later verify a signed Mobility Update,
then I think you need to consider the caching times of the global
mapping system and perhaps DNS for Mobility.

The idea of a Mobility Update is so the MN can tell its CH
(corresponding host) that it just got a new Locator.  In fact, it
probably will need to tell the CH it just got a new Identifier too,
since as soon as it gets a connection to another access network, it will
be in another GLI-domain and the Identifiers available in that
GLI-domain are different from those available in the GLI-domain of the
previous access network.

The purpose of the Mobility Update message is to enable the CH to
reliably use the new Locator, and probably Identifier, to continue the
communication - *before* the MN has had a chance to make the DNS or the
global mapping system reliably return the new Locator and/or Identifier.

In order to be able to authenticate the Mobility Update, the CH must
have exchanged nonces, keys or whatever at a prior time when the MN was
using a Locator and an Identifier which the CH was able to authenticate
via the mapping system.

So if the mapping system involves 10 minute caching times, then
generally a MN will need to be using a particular Locator and Identifier
for 10 minutes before all its CH's would be able to do the nonce or key
exchange.

I think there are many problems for MIP and Mobility, and caching times
in the mapping system of a CEE architecture probably need to be really
short in order to support the attempt to make the CEE mechanisms work
with hosts which are frequently, and without notice, getting new
Locators and (in GLI-Split) new Identifiers as well.


Identifiers are not portable!
-----------------------------

With a CES architecture such as LISP or Ivip, the edge addresses are
individually portable (IPv4 - or the /64s for IPv6) to any ISP in the
world.  These addresses combine Identity and Locator functions - but the
CES architecture does the Location work for these addresses via ITRs, so
they can be used anywhere.

I think some or many other CEE architectures provide globally portable
Identifiers.  However, GLI Identifiers can only be used within the one
GLI-domain, which is a physical network - and in most scenarios no
larger than an office, a factory or a campus.

The FQDN can be made to point to any Identifier, so in principle you can
regard the FQDN as the true identifier for one or more hosts, which
remains under the control of the DNS domain owner, no matter which hosts
it points to, in which GLI-domains.

But overall, I think this restriction is severe and at odds with the
general goals of scalable routing.




LISP is not Locator/Identifier Separation
-----------------------------------------

In section 3.8:

   3.8. Security Concerns and Countermeasures

     We first consider a problem that is common to all Loc/ID split
     approaches [29] ...

[29] is a reference to LISP.  But LISP does not implement
Locator/Identifier Separation.  Please see:

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



Split horizon DNS
-----------------

Sections 4.1 and 4.4 mention a DNS for hosts in a GLI-domain which
returns different IP addresses than the global DNS.

I can't imagine how this is desirable or practical - applications can
normally assume DNS returns the same results no matter where the query
is made from, except where it is for services of a CDN, or some globally
distributed set of servers such as Google.


Multihoming reachability testing and decision-making
----------------------------------------------------

It is not clear how a GLI stack in a sending host can determine which of
multiple GL Global Locators for a given destination host are currently
usable.

If a GLI-gateway fails, or can't reach its GLI-domain's routing system,
then the little prefix it has is not withdrawn from the DFZ, since it is
a small part of a much bigger (shorter) prefix advertised by the ISP.

Will the GLI-split system properly support ICMPv6 destination
unreachable messages getting back to the sending host?

What if no such messages are sent?

There is way specified in the current design by which the GLI-Split
stack in the sending host can test reachability of the destination
GLI-Split host via multiple Global Locators.

Nor is there any mention of how long one GL would need to be apparently
out of action before the GLI-stack decides to use another GL.  Also, how
long after the first one was found to be good would it be before the
traffic was restored to the first one?

Since these functions are built into the GLI-Split protocols and
devices, it needs to be specified - and different end-user networks may
want different approaches to reachability testing and decision making.

LISP, IRON-RANGER, and I think all the proposals apart from Ivip face
the same difficulties with reachability testing and providing the right
range of decision-making algorithms to suit the varying requirements of
the multihomed end-user networks.  For instance, frequent reachability
testing is needed for quick multihoming service restoration, but scales
badly and could generate prohibitive amounts of probe and response
traffic for a host, or GLI-domain, or its GLI-gateways, if there are a
large number of hosts currently sending packets to it.

Ivip avoids all this by externalising the reachability testing and
decision making.  End-user networks are responsible for this, and they
will generally hire a company to do it for them, in any way they wish.
This is only possible because Ivip provides the end-user networks with
essentially real-time control of the tunneling behavior of all ITRs
which are currently handling packets addressed to their network.



Confusion over CEE and CES
--------------------------

In section 6:

   The authors of [32] identified two different strategies:
   "separation of core and edge networks" and elimination of
   de-aggregated provider-independent and provider-aggregatable
   addresses from BGP routing tables.

Please see:

   CES & CEE: GLI-Split; GSE, Six/One Router; 2008 sep./elim. paper
   http://www.ietf.org/mail-archive/web/rrg/current/msg06009.html

I trace the history of these terms, and suggest that while this 2008
paper did focus on the "separation of core and edge networks", the
important distinction is the separation of a new, scalable, "edge"
subset of global unicast address space from the remainder, which is
known as "core".

This is the common feature of all CES architectures.  Most of the
authors were designers of APT, a CES architecture - and APT was unique
among CES architectures in having a long term goal of genuinely
separating the entire set of edge networks from the core network.  This
is not a defining feature of CES architectures.

  Proposals implementing separation can be subdivided into address
  rewriting, map-and-encaps, and source routing approaches.

This seems to be following what I regard as mistakes in the 2008
paper.  Please see (msg06009).  I am not sure what you mean by "source
routing approaches".

The categories of CEE and CES are valid and important.

There is one architecture which I think has some CES characteristics
which involves address rewriting: Six/One Router - but it is IPv6-only
and requires split horizon DNS, with one set of results for hosts within
a network and another for those outside it.   I am not really sure if
Six/One router should be classified as a CES architecture.  It is
no-longer being developed, and I recall it needed a bit in the IPv6
header to function.

"map-and-encaps" means encapsulation and the CES architectures LISP,
APT, Ivip, TRRP, TIDR and IRON-RANGER all use encapsulation for
tunneling.  However, Ivip in the long term will tunnel with Modified
Header Forwarding, rather than encapsulation - so it is not really valid
to state that CES architectures always involve encapsulation.

   With address rewriting, border routers add global locator
   information to packets destined for a different domain
   by coding this information into source and destination
   addresses for transit purposes.  GLI-Split falls into that
   class.

This is a statement that GLI-Split is a CES architecture.  I am sure it
is not.  I believe GLI-Split is a CEE architecture, as is GSE.  The 2008
paper mistakenly classified GSE as a CES architecture.

CES architectures give special treatment (with ITRs and ETRs usually) to
a special "edge" subset of the global unicast address space.  Ordinary
hosts can treat these addresses just like any other.  The hosts
themselves on these address use these addresses naturally.

This is not true of GLI-Split.  The hosts get a local IP address and
this cannot be used to reach them from outside the local GLI-domain.
Instead, a single IP address is in the DNS for each such host, with one
of the potentially multiple GL addresses for this host.

CES architectures make the edge addresses usable anywhere in the world,
but GLI-Split's Identifiers, and their potentially multiple global
usable IP addresses which use GL Global Locators, can only be used in a
single GLI-domain.

Also, LISP is a CES architecture - it does not implement
Locator/Identifier Split.  All CEE architectures implement
Locator/Identifier Split and your proposal correctly states that
GLI-Split implements Locator/Identifier Split.

    The Identifier Locator Network Protocol (ILNP) [34, 35, 10]
    is similar to GLI-Split in the sense that it splits the IPv6
    address into a locator and identifier part, but there are
    many differences.

OK - ILNP is a CEE architecture, and there are many similarities with
this and GLI-Split, which is also a CEE architecture.

    GLI-Split, ILNP, and Six/One Router have evolved from the early
    ideas of GSE (global, site, and end-system address elements)

This is true of GLI-Split and ILNP, but not of Six/One Router.  The
final version of Six/One Router:

http://conferences.sigcomm.org/sigcomm/2008/workshops/mobiarch/papers/p13.pdf

does not mention GSE or "Locator/Identifier Separation".

On page 24:

   GLI-Split implements the Loc/ID split concept within today’s IPv6
   Internet.

Yes.  GLI-Split is a CEE architecture with the unique (apart from GSE)
aim of using conventional IPv6 applications in a genuine Locator/ID
Separation naming model.

Like all CEE architectures, and unlike the better CES architectures, the
benefits for adoptors and the routing scaling benefits only really occur
after all hosts in all networks have adopted the system.


ACLs
----

How can ACLs be implemented with Locator/Identifier Separation?  At
present, simple filtering of hosts by their IP address, or prefixes of
IP addresses, is a simple and robust method of controlling access to
VPNs, to publications licensed to particular universities etc.

How can the equivalent functionality be provided for hosts with
particular Identifiers?