Re: [rrg] GLI-Spit: discussion and draft critique

[Matthias Hartmann <[e-mail]>]

Hi Robin,

thanks for your very thorough review/critique of GLI-Split!
It took me a while to work through all of it...
You pointed out many issues and I will first comment on the issues
that I think are important, before answering the remaining issues inline.

First: GLI-Split is by far not yet at "standard RFC" level, it is more a proposal
to push our ideas into the RRG and help to achieve a good final recommendation.


1. Your assumption that GLI-Domains require a contiguous set of identifiers,
which can only be used inside that GLI-Domain, is wrong.
Actually, this is one of the benefits of GLI-Split that you can freely move
- inside a GLI-domain (also to areas with different routing areas)
- to other GLI-domains
without having to acquire a new identifier.



2. This are the essential features of GLI-Split:
It separates global routing in the DFZ (using so called global locators)
from local routing in the edge networks (so called GLI-domains),
while maintaining a stable identifier for all nodes.
The big advantage compared to many other proposals (e.g., LISP using LISP-MN or TTR)
is that a host can move to other routing areas and can communicate "normally"
without any additional mobility solution.
Example: The LISP host A has the IP/EID 2001.db8:1234::ABCD:1 and is located in a 
routing area with all other 2001.db8:1234::ABCD:* hosts. Even when A moves only 
inside its OWN domain to an area with a different routed prefix
(e.g., 2001.db8:1234::CDEF:*), either the routing has to be changed, so that packets 
for host A (2001.db8:1234::ABCD:1) are also routed to the new area 
(2001.db8:1234::CDEF:*), or node A has to acquire a new EID/IP (e.g. 
2001.db8:1234::CDEF:1) that is routeable there, or A must use TTR or another triangle 
routing mobility mechanism even to
communicate with hosts in its own domain.
With GLI-Split, host A simply acquires a new local locator in the new routing domain
and is still reachable using the same ID.
Host A can even have multiple local locators inside a GLI-Domain, e.g., using an
ethernet connection and the companies WLAN at the same time.



3. You criticize that we do not present a mapping-mechanism for GLI-Split.
As you might be aware of, we have proposed the mapping system FIRMS, independent
from GLI-Split.

http://www3.informatik.uni-wuerzburg.de/~menth/Publications/papers/Menth09-FIRMS.pdf

We are aware that routing/addressing proposals and mapping systems are
highly dependent, but in the GLI-Split proposal, we wanted to focus only
on the routing and addressing mechanisms.



4. The next issue you mention is that the hosts have to perform ID->locator lookups
themselves, which burdens them with additional mapping-look-ups and slows down
the communication initialization. You say that a lookup by the gateways is
better because they can cache the information more efficiently and a lookup
there is more reliable than a lookup performed by the host, which is possibly
connected over unreliable wireless links that might drop mapping replies.
In a first version of GLI-Split, we also had thought that the gateways should
do the lookup, but when the gateway does not have a mapping yet, it must either
drop packets, cache the packets until a mapping is returned, or send the packets
over the mapping system to the destination. All these options are not optimal.
To avoid these problems, we decided that the hosts should do the lookup.
The short additional delay is no problem in the hosts because it happens BEFORE
the first packets are sent. So no packets are lost or have to be cached.
GLI-Split could also easily be adapted to GLI-hosts (e.g., low power sensor nodes)
that do not have to do any lookup and simply let the gateway do all the work. This
functionality is included anyway for backward compatibility with regular IPv6-hosts
inside the GLI-domain.



5. The next problem you mention is, that hosts might have a problem, when the
DNS lookup returns a global address with the global-locator included, while
the host itself is configured only with its identifier address.
In my opinion (correct me if I am wrong), the DNS lookup process is usually
part of the operating systems/programming language API. So it could/should
be adapted to only return identifier addresses.



6. You found a security issue that we were not aware yet, which can easily be resolved.
The gateway-selection/preservation method that is used for communication
from "legacy" hosts outside a GLI-domain with multihomed GLI-hosts has the
problem that an attacker might be able to interrupt an ongoing communication session!
It is not as simple as you state, as the attacker would have to intercept
packets to find out the used source and destination addresses and the source
and destination ports, but if it has this information and it knows another
GLI-gateway of the GLI-host, it could send a packet to the GLI-host with a
spoofed source address/source port using the second gateway and the GLI-host
would then use this GLI-gateway for the ongoing communication, so that
packets returned to the legacy host have the "wrong" global locator in the source
address and can no longer be matched to the same communication session.
  To resolve this issue, a GLI-host must not dynamically update the binding between
a communication session with a legacy host and the used GLI-gateway.
It is very unlikely, that a legacy host performes a DNS-lookup during an ongoing
communication session and suddenly uses a different global locator of the GLI-host.
Actually, a regular IPv6 host would not even know that the "new" address with a 
different global locator returned from DNS belongs to the same GLI-host as before
and would initiate a new communication session with that new address.
This new communication session would use a different source-port
at the legacy IPv6 host and thus the GLI-host would recognize it and store
a different binding from the session to the utilized GLI-gateway/global locator.


Please find the remaining answers inline:



Am 16.02.2010 16:42, schrieb Robin Whittle:
> 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

double "the"

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

7. The last point is not completely true:
The IDs are totally portable between GLI-domains and no renumbering is required.
Incoming communications from legacy hosts are dependent on DNS-updates when switching 
providers, which is not worse than the current situation.
Multihoming is working, though only using one gateway at a time.
Inbound TE can be performed by announcing different default gateways in the DNS
for different services / IDs.

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

see answer 3.)


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

see answer 7.)

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

I will state it more clearly!

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

I will think about this.

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

this is not true! see answer 1.)

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

see answer 5.)

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

E.G. EID-based


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

what do you exactely mean with "multihome"?

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


wrong, see answer 1.)


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


might be a (solvable) problem, but could be a benefit! (see answer 4.)

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


see answer 3.)

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


wrong, see answer 1.)

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


8.) I admit, this should be stated explicitely in the proposal. The GLI-hosts get the 
local address of their local mapping service via the DHCP service that also gives 
them their local locator in the first place.

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

see answer 3. This belongs to the mapping service, not the routing and addressing.

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

9.) true

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

still true (see answer 9.)


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

true, this is an issue, which is not completely described in the current version.

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

why slower?
pure CES as you think of must perform all lookups in the gateways and store or drop 
packets, which is also complex. The burden on the host is not high.


> architectures require complete, or almost complete, adoption before there are
> substantial benefits to adoptors or to scalable routing.

not true. There are benefits. See answer 7.)

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

yes, that's the way we think about it right now. But it is not an ultimate requirement...

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

In the following you again use the false assumption that ID-addresses belong to a 
GLI-domain and stay there for ever... (see answer 1.)


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

yes, this is correct.

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

this is wrong (see answer 1.)

>
> It is implied in the current design that a single host can have two or more
> Identifiers,

true

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.

this is wrong (see answer 1.)

>
> 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 "GLI-supportive networks" is actually almost the design that we had intended
( I do not know where you got the idea from, that Identifiers can only reside in one 
domain )

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


correct.

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

wrong (see answer 8.)


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

correct


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

see answer below.

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


actually, mose of the mapping-request-reply logic is inside the hosts, not in the 
gateways.

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


sounds correct so far.

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


not correct. See answer 1.).
10.) We assume for FIRMS, that the ID-space is assigned hierarchically. Internet 
registries assign ID-space to ISPs which can give them out to customers.
This hierarchy is then only important for distributing changes in the mapping
for these IDs. The IDs themselves can move freely to other GLI-domains.


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

wrong

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

they could be run by a separate company

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

so if they pay another organisation what is the problem with it being "burdensome"?

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


ok.

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

partially wrong (see answer 1.)


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

there is only hierarchy in the ID-assignment and in the GL assignement

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

see answer 10.)


>
> 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, only packets inside a GLI-domain can 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.
>

true, this needs some clarifikation. I will try to make it clear in the next revision 
of our paper.


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

Yes, this issues needs some more thought and an easier description.

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


I do not consider this an important issue in the current state. This would have to be
clarified and described in detail for an actual implementation. But either way works,
so no need to worry about it.

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


See answer 5.)


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



The following description is correct


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


Yes, page 7, 3.1 "...extracts ID..:"

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


The "locator gleaning" section is NOT a technology we propose to use, but it is
a description of a security issue with CES architectures and should be avoided.
We simply describe this here and state, that we should avoid doing it (otherwise,
a software engineer implementing GLI-split could have to idea to this!)
We should describe it also for hosts, not only the gateway, but the mechanism is the 
same.


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


Sorry, there was a bug in this figure...

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

I agree, checksum compensation is a better name for it.

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

This should not happen.

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

correct

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


the following is answered in answer 6.)

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

No this is not stated in the paper (at least I cannot remember... )

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

No need for NAT there. If host 4 initiates the communication, packets are forwarded
to one of the GLI-domains gateways. As long as the general routing inside the domain
is not changed, packets are always forwarded to the same gateway and thus have
the same external address.
If host 4 would be a mobile host inside this GLI-domain and it's point of attachement
would change, it could use the same gateway preservation methods as described before,
to ensure that always the same gateway is used.


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


You are correct, the resilience part of multihoming is tricky when communicating
with legacy IPv6 nodes. This needs some more thoughts.



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

wrong! see answer 1.)

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


The gateway could also know the lowest PMTU for each routing AREA inside its network,
so the problem can be mitigated.


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

and this limitation is non existent. See answer 1.)

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


see answer 2.)

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

wrong, see answer 1.)

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


Yes, these addresses can be used anywhere, but they are not INDIVIDUALLY portable.
If you move just one address to a different domain that is not completely switched,
  the routing inside this other LISP-domain would NOT forward packets for the
unknown address somewhere inside its network.


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


wrong, see answer 1.)

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

I know ...,
LISP should not be named "locator identifier split protocol", but rather 
"global/local naming and routing split protocol" but "GLNRSP" is not as easy to 
pronounce ;-)

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


And what would be the problem, when there is an internal DNS server (not accesible 
from the outside) that returns
local addresses for hosts that are inside the same GLI-domain?
What would break?


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


Yes, this is a critical point. There is ongoing work in the LISP community to solve 
this. GLI-Split could work with any of the solutions that we could think of in the RRG.

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

It is halfway true for GLI-Split. Look at the GLI-Prefix and the "Local-locator-bit".
All local addresses have this prefix and they are unique, because the identifiers are 
unique. So actually, the local addresses ARE an "edge" subseof of the global unicast 
address space. The fact, that LISP for example announces all these addresses
aggregated in the DFZ and routes them to a Proxy-ITR is just a backward-compatibility 
measure. GLI-Split uses a different mechanism and uses the DNS
to announce routable global addresses instead to reach the hosts with the 
not-globally-routable local addresses

So I am not sure whether this CES/CEE debate helps us in any way here...


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

wrong, see answer 1.)

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


How about using the Identifiers in ACLs?




Thanks again Robin for all your comments!

Best regards,

   Matthias Hartmann


-- 
Dipl.-Inform. Matthias Hartmann
University of Wuerzburg, Institute of Computer Science
Chair of Distributed Systems (Informatik III)

Am Hubland, 97074 Wuerzburg, Germany

http://www3.informatik.uni-wuerzburg.de/staff/hartmann/
[e-mail]
phone: [phone]