Subject: [rrg] RANGI questions

From: Robin Whittle <[email-masked]>
Date: Sat, 20 Feb 2010 01:11:47 +1100

Hi Xiaohu,

Here are some questions about RANGI.  If you and perhaps others can
discuss these I will create a revised version in the form of a critique.

Some of the arguments concern other CEE proposals - GLI-Split, ILNP and
Name Based Sockets.

  - Robin

Reference documents
-------------------

IDs:

   http://tools.ietf.org/html/draft-xu-rangi-03
   http://tools.ietf.org/html/draft-xu-rangi-proxy-01

Summary, critique (by Paul Francis):

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

Rebuttal:

  http://www.ietf.org/mail-archive/web/rrg/current/msg06008.html

Discussion and questions
------------------------

RANGI is a Core-Edge Elimination (CEE) architecture which requires
as-yet undocumented changes to host stacks and applications, starting
from the base of IPv6.  Since many applications today are written solely
for IPv4, the requirement for IPv6 compatibility and then changing
applications substantially to presents an enormous hurdle to the
widespread adoption of a solution such as RANGI.  Since benefits only
arise when two RANGI applications (on hosts with RANGI stacks) are
communicating, substantial benefits to adopters only occur when most or
all of the hosts in the world have been upgraded and given IPv6 access.

RANGI is intended to interwork with IPv4 - but there are insufficient
details to conclude that this would be practical.  One problem is Path
MTU Discovery (PMTUD) difficulties due to the changing packet size - due
to the IPv4 and RANGI header formats being different lengths.  The proxy
servers for this interworking would need to translate PTB packets in
both directions with suitable caching of the initially sent packets in
order to be able to construct valid PTBs, and with suitable adjustment
of MTU values to account for differing header overheads in the two
systems.  The necessary IPv4 - RANGI proxies cannot support multihoming
and are required to alter the information contained in DNS replies,
which is likely to disrupt some applications.

Proxies can also be used for interworking between IPv6 hosts and RANGI
hosts, but these do not support multihoming.

RANGI packets are like IPv6 packets, but have a Destination Option
Header to carry the source and destination Identifiers, both of which
are 16 bytes.  So RANGI packets would have headers of at least:

   40 bytes IPv6
   36 bytes Destination Option Header

 = 76 bytes

This is significant extra overhead.  In addition these packets may be
encapsulated in IPv4 in some settings, making 96 bytes of headers, not
counting TCP or UDP headers.

The VoIP packet size for RANGI would be:

    40 bytes IPv6
    36 bytes Destination Option Header
     8 bytes UDP
    12 bytes RTP
    20 bytes payload

 = 116 bytes total, compared to 60 bytes for IPv4 or 80 bytes for IPv6.

Without more detail of the mapping systems - both the global DNS system
and the Identifier -> Locator mapping systems, it is impossible to
estimate the actual performance of a RANGI system.  The ID->Loc mapping
system will frequently be used, since it is the only way of ensuring
that a given Locator is valid for any particular Identifier.  The
caching time is set to zero (page 7) so all queries must go to the
authoritative servers, which may involve traversing multiple
intermediate servers - all of which could be anywhere in the world.

Likewise, it is impossible to estimate how RANGI would handle
multihoming service restoration without details of how each host HA can
reliably probe the reachability of another host HB via:

        HA's two or more ISPs, assuming it is multihomed,
and/or  HB's two or more ISPs, assuming it is multihomed.

There are serious scaling problems with large numbers of hosts probing a
single host - and there are currently no details of what algorithms
would be used to decide when to switch to an alternative near or far
ISP, and when to switch back after some (unspecified) probing has
revealed that the preferred path is working again.  The current proposal
provides no details of how hosts would find out about from the ID->Loc
mapping system how to probe and make these decisions.  Nor are there any
details about how the ID->Loc map reply could specify load sharing or
any other inbound TE preferences for when two or more ISP paths are working.

On page 5, the local host IDs are required to be unique within an AD.
This would require an AD-wide registration system whereby each new local
host was required to choose another key-pair if its current key pair
resulted in a clash - its local host ID being identical to that of
another host.

I think the use of the term "IPv4" addresses in section 2.2 (Host
Locators) is confusing, because readers will typically assume this means
existing IPv4 addresses.  Yet, if RANGI is to use the full addressing
range of IPv6, it clearly can't be using IPv4 addresses in the global
unicast sense, with each one being only used by a single host in the world.

Perhaps it would be better to specify that the right-most 32 bits of the
 Host Locator may involve globally unique global unicast IPv4 addresses,
but that these 32 bits need not be associated with the IPv4 Internet at
all.  My understanding is that if the networks being converted to RANGI
already have their hosts on IPv4 addresses, and have an IPv4 routing
system, then this can be used to tunnel packets to these hosts without
them having IPv6 stacks or using IPv6 routers.  I don't understand the
various scenarios here in a way which makes any practical sense.

I understand that when these hosts in a RANGI LD don't have IPv4
addresses, then they are basically IPv6 hosts or IPv6-RANGI hosts.
Then, the 32 bit values need have nothing to do with IPv4 at all.
Although they are still called "IPv4" bits, the text (page 5):

   LD IDs are used to globally identify each site network which
   is allowed to adopt independent IPv4 address space (either
   public or private IPv4 addresses).

indicates the values of these 32 bits need only be unique within a given LD.

RANGI has an advantage over GLI-Split (msg06056) in that a host
Identifier can be used on any host in the world - in any LD.  Each LD -
each physical routing system of a "site" - is a completely independent
concept from the AD-based structure of the Identifier system.

CEE architectures such as RANGI implement Locator/Identifier Separation,
which involves hosts in extra routing and addressing management work
compared to today's IPv4 and IPv6 naming models, in which the IP address
plays both the Identifier and Locator roles.  In today's naming model, a
respondent host can reply to a packet it receives without any any
further work, because the routing system ensures that the packet will
not be delivered to any host other than the one whose Identity is that
of the destination address.

Compared to the simplicity and speed of today's arrangements, CEE
architectures in general require two additional global mapping lookups
before a basic two-packet initial exchange can take place.  In addition
to any initial DNS lookup which may be involved, the first lookup is by
the initiating host, looking up the respondent host's Identifier.  This
returns the one or more Locators by which the respondent host can
currently be reached.

When the resulting packet arrives at the respondent host, a second
lookup is typically required - though this is not documented in the
current RANGI IDs.  In some cases, the respondent host does not need to
be sure of the Identity of the host to which it sends the response
packet.  For instance a DNS server may not need to know this - so the
second mapping lookup is not required.

Assuming the respondent needs to be sure the packet it sends goes to the
host whose Identity was in the source field of the initial packet, it
cannot trust the Locator which was in the source field of the initial
packet - since this packet could have been generated by an attacker.
Therefore, a second lookup is required, by the respondent host, querying
the presumed initiator's Identifier (at least, the Identifier found in
the source field of the initial packet).  Only if the initial packet's
source Locator matches the one or more Locators returned by the mapping
system can the respondent proceed to send a reply packet.

These are lookups of a global mapping system, with the answers coming
from authoritative query servers, due to the zero caching time
preventing the results being cached in any resolvers which might be
involved in the query.

These mapping lookups, and the original DNS lookup, are likely to
involve further mapping lookups due to the need to gain Locators for
each Identifier of a server which needs to be queried, as part of
finding the Identifier and then the Locator of the authoritative server
which can actually provide the reply.

If the DNS can be enhanced to return not just one or more Identifiers
for a given FQDN, but one or more Locators specific to each Identifier,
then this would remove the need for the initiating server to perform the
first ID->Loc lookup mentioned above.  Sometimes the second can be
omitted too.  However, these proposed DNS mechanisms are for queries by
RANGI hosts only - and must not disrupt the ability of IPv6 hosts to
obtain an IP address which they can use to initiate communications with
RANGI hosts by one of the IPv6-RANGI proxy arrangements.

Circularity needs to be avoided in the global ID-Loc mapping system.  A
given AD needs to run its own authoritative servers, or have some other
organisation run them on its behalf - and then handle secure updates to
it as hosts change their Locators.  If an AD's authoritative mapping
servers are implemented on its own servers, these servers need to be
accessible via Identifiers which are not part of this AD.  This appears
to be impossible in GLI-Split, where an Identifier can only be used in a
given GLI-domain (roughly equivalent to a site).  However, assuming that
in RANGI, each physical host can have multiple Identifiers (which
appears to be neither mentioned nor disallowed in the current IDs), then
circularity problems can be avoided by having the authoritative query
servers accessible to queriers via Identifiers from some other AD-y than
the AD-x for whom they are answering ID->Loc queries.  These hosts may
be owned and run by this AD-x, and may also be accessible globally via
Identifiers of AD-x.

Many more details of Mobility are required before the effectiveness of
RANGI for Mobility could be estimated.  A host could retain its
Identifier as it moves to any access network - which it cannot in
GLI-Split.  However, its accessibility in that new network depends upon
it rapidly updating its ID-Loc mapping entry to include the new Locator.
 While a mobile RANGI host may be able to securely inform its
correspondent RANGI correspondent hosts, including those which are
mobile too, of its new Locator, if this precedes the availability of the
new Locator in the ID-Loc mapping system, then nonces or keys must have
been securely exchanged previously.  This secure exchange would
presumably only be possible if it took place while the mobile node was
using a Locator which was returned by the ID-Loc mapping system.  So
short update times for that system would be vital so that the nonce or
key exchange could take place before the host had to use a different
Locator again due to leaving one access network and connecting to another.

RANGI, like all CEE architectures, is only practical for IPv6 and cannot
support hosts which are behind NAT, including any mobile hosts.  Mobile
hosts and all other hosts require global unicast addresses.

As with GLI-Split at least (ILNP too), there is no mention of how RANGI
would work with private address ranges.  For instance, two hosts which
share access to a private address range should communicate via the LAN
or WAN which supports that range, rather than use RANGI's globally
scoped Locators.

While RANGI is described as involving a mixed IPv6 and IPv4 deployment,
this can be hard to understand - it would be good to have a description
of the system being deployed on IPv6 without any reference to IPv4 at all.

RANGI, like (apparently) all other CEE architectures only provides the
benefits of (Identifier) portability, multihoming and inbound TE for
communication sessions between two upgraded hosts.

While some CEE architectures can use existing IPv6 applications (GSE and
GLI-Split) RANGI is like ILNP and Name Based Sockets in requiring IPv6
applications to be rewritten to use Identifiers and Locators.  This may
be relatively easy for some applications.  It may be very difficult for
others, since the current protocols may rely strongly on the currently
valid assumptions that sending a packet to a given IP address will not
result in it being delivered to a host other than the one whose identity
is specified by that IP address.  (Most applications are written for
IPv4 only - though some of the most popular applications such as major
Web browsers are able to use IPv6.)

RANGI requires the installation of a new router, or an upgrade to an
existing one, to perform the "source-based policy routing" described in
section 2.6.  However, a much greater barrier to adoption is likely to
result from the combination of:

   1 - Need for stack upgrades and substantially rewritten applications.

   2 - Benefits only arising for adopters in the case of communications
       between two hosts with these upgrades.

   3 - No obvious reason why applications should be rewritten, just to
       serve an initially small number of RANGI adoptors.  The task
       of writing and debugging an application to use both IPv6 and
       RANGI protocols, including at the same time to multiple
       correspondent hosts at the same time, may be very challenging
       - particularly when the existing protocols cannot be directly
       adapted to RANGI.

   4 - Substantial benefits to adoptors (complete portability and
       multihoming for all their communications) are not available until
       all their hosts and applications are updated - and essentially
       all other hosts on the IPv6 Internet, and their applications are
       upgraded too.

   5 - Routing scaling benefits only occurring when the above conditions
       are met - because until this occurs, PI space will be the only
       method of ensuring portability, multihoming and inbound TE on
       all communications and no PI-less end-user network would have
       portability, multihoming and inbound TE for all their
       communications.

The central technique of CEE architectures, including RANGI, is to
implement Locator/Identifier Separation as a means to achieving routing
scalability - since universal adoption of this would mean that
portability, multihoming and inbound TE could be achieved just as easily
on PA space as on PI space.   However, this brings with it a continual
burden of extra packets and frequently extra delays due to non-cacheable
global mapping system queries.  This will slow down all communications
compared to today's arrangements - including some DNS lookups.  In the
case of RANGI, there is an additional burden of longer packets.

The extra burden of these new host responsibilities falls particularly
heavily on those devices which are battery powered hand-held devices
relying on slow and potentially unreliable 3G and similar wireless
links.  These are likely to be the majority of all hosts - and the most
frequently used ones - within ten years.

Compared to some other CEE proposals - such as ILNP GLI-Split and Name
Based Sockets - RANGI has a further burden in the form of the 36 or so
byte Destination Options headers which are part of every RANGI packet.
Name Based Sockets involves long FQDNs being sent in initial packets,
but RANGI involves this 36 byte overhead on all packets.

RANGI cannot contribute to the solution of the IPv4 routing scaling
problem.  Perhaps with further work it could be developed into a viable
solution for IPv6 - but in order to be chosen as the best solution, it
would not only have to be shown to be superior to ILNP, which has no 36
byte header burdens, but it would also need to be established that
changing all host communications to the more burdensome and delay prone
Locator/Identifier Separation naming model was desirable.

CES (Core-Edge Separation) schemes retain the current naming model and
some of them use local full database query servers - so avoiding initial
packet delays due to the slow and unreliable nature of any global
mapping system.  Even if the need to rewrite stacks and applications was
not a barrier to adoption, a choice to replace the current IPv4 / IPv6
naming model with Locator/Identity Separation would need to be made in
order for any CEE architecture to be seriously contemplated as the best
solution.  While there are arguments for this in terms of "architectural
elegance" and in terms of not having to add anything to the routing
system, the counter-arguments are formidable:

  1 - The current naming model involves less computational load and
      traffic to and from all hosts compared to Locator/Identifier
      Separation.

  2 - The current naming model involves none of the additional mapping
      lookups and therefore delays which Locator/Identifier Separation
      typically requires.

  3 - The CES upgrades to the network are justifiable because they are
      easier than upgrading all host stacks and especially applications,
      and because of the argument that the routing system should serve
      the reasonable needs of hosts.

  4 - CES mapping lookups are performed from ITRs which are typically
      not located behind slow, potentially unreliable wireless links so
      the delays and costs of these lookups will be less than with
      CEE.  CES ITRs' mapping lookups will generally be less numerous
      in total because each ITR's cache covers the activities of
      multiple sending hosts - which in a CEE architecture would each
      need to make the mapping query themselves.

---

From: Michael Menth <[email-masked]>
Date: Fri, 19 Feb 2010 15:21:06 +0100

Hi Robin,

just a quick and short response.

Robin Whittle schrieb:
> Identifier can be used on any host in the world - in any LD.  
> This appears
> given GLI-domain (roughly equivalent to a site).  
>   
> A host could retain its
> GLI-Split. 

What you say here is not true. The identifiers in GLI-Split are global 
and can retained when hosts move among GLI-domains. This is an essential 
feature of GLI-Split. We'll send you later a more detailed answer to 
your previous email.

Best wishes,

    Michael

-- 
Dr. Michael Menth, Assistant Professor
University of Wuerzburg, Institute of Computer Science
Am Hubland, D-97074 Wuerzburg, Germany, room B206
phone: (+49)-931/31-86644 (new), fax: (+49)-931/31-86632 (new)
mailto:[email-masked]
http://www3.informatik.uni-wuerzburg.de/research/ngn

---

From: Xu Xiaohu <[email-masked]>
Date: Sun, 21 Feb 2010 16:04:53 +0800

Hi Robin,

Thanks a lot for your comments. Please see my response inline.

> -----邮件原件-----
> 发件人: Robin Whittle [mailto:[email-masked]]
> 发送时间: 2010年2月19日 22:12
> 收件人: RRG
> 抄送: Xu Xiaohu
> 主题: RANGI questions
> 
> Hi Xiaohu,
> 

With the site proxy or transit proxy mechanisms
(http://tools.ietf.org/html/draft-xu-rangi-proxy-01), legacy IPv6 hosts can
initiate communications to RANGI hosts, and vice versa. In this way, the
early adopters of RANGI could gain substantial benefits before most or all
of the hosts in the world have been upgraded.

> of MTU values to account for differing header overheads in the two

I believe the PMTU issue is not specific to RANGI. Once this issue is solved
during the IPv4/IPv6 transition period, it will disappear involuntarily when
adopting RANGI.

> systems.  The necessary IPv4 - RANGI proxies cannot support multihoming

RANGI proxy CAN support multi-homing since the multi-homed proxy can use
either locator when translating from IPv4 to RANGI. 

> hosts, but these do not support multihoming.

RANGI proxy CAN support multi-homing since the multi-homed proxy can use
either locator when translating from IPv6 to RANGI.

>  = 116 bytes total, compared to 60 bytes for IPv4 or 80 bytes for IPv6.

Yes, your observation is correct. However, do you think this extra bit
overhead will bring any serious burden on the high-speed Internet? 

> intermediate servers - all of which could be anywhere in the world.

It is said as "...To prevent DNS recursive servers caching antique
ID->Locator mapping information, the TTL of a RANGI RR for a _mobile host_
should be set to 0 or a very small value." In normal cases, there wouldn't
be too many correspondence nodes for a mobile node simultaneously, IMHO. For
those hot-spot servers which are usually fixed hosts, the TTL for their
RANGI RRs can be set to a large value.

> any other inbound TE preferences for when two or more ISP paths are
working.

These details will be considered in the further version.

> resulted in a clash - its local host ID being identical to that of

Not necessary for a host to choose another key-pair in case of ID collision.
We borrow the ideas from CGA for handling the ID collision issue.

> unicast sense, with each one being only used by a single host in the
world.

The intention that IPv4-embeded IPv6 addresses are used as locators in RANGI
is to reduce the deployment cost of such a new architecture and avoid
renumbering the site internal routers when changing ISPs. For those site
networks where private or public IPv4 addresses are used, it is only
required to upgrade the hosts and the site border routers in order to
support RANGI. In other words, there is no need to touch the site internal
routers.

> indicates the values of these 32 bits need only be unique within a given
LD.

If a site network is already IPv6 only, locators of the hosts within that
network are just ordinary IPv6 PA addresses.

> concept from the AD-based structure of the Identifier system.

Correct.

> of the destination address.

Each model has its pros and cons.

> returns the one or more Locators by which the respondent host can

This host-initiated lookup eliminate the mapping work done by ITR in CES. As
for host mobility, this lookup also eliminates the route optimization work
in Mobile IP since the route is already optimal.

> system can the respondent proceed to send a reply packet.

I believe the CES model will also face this issue. For example, the ITR of
the responder's site will also need an ID->Locator lookup when it can't
trust the RLOC of the incoming packets.

> first ID->Loc lookup mentioned above.  Sometimes the second can be

Assuming that not all hosts possess their own FQDNs, the ID->Locator mapping
system is a must. Hence, the hosts should update its locator in the
ID->Locator mapping system in the event of mobility or re-homing. If you
want the DNS to store the locator information, the host would have to update
its locator information in DNS besides updating the ID->Locator mapping
system. Do you believe it is still worthwhile?

> or WAN which supports that range, rather than use RANGI's globally

The site network could use private IPv4 addresses. As said in the RANGI
draft,    "If the communication parties share a same LD ID, they can
exchange packets directly over an IPv4 tunnel (between them). Otherwise, the
traffic will be relayed by LDBRs through IPv4 tunnels."

> of the system being deployed on IPv6 without any reference to IPv4 at all.

OK, I will add some statement about such case.

> communication sessions between two upgraded hosts.

This statement is not true once we take the RANGI proxy mechanisms into
account. 

> existing one, to perform the "source-based policy routing" described in

Note that the source-based policy routing is not a new feature. Only the
source address rewriting requires an upgrade.

Again, thank you for these detailed comments.

Best wishes,
Xiaohu

---

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

Hi Xiaohu,

> of the hosts in the world have been upgraded.

I don't understand how this could be an advantage for them over
leaving their host as an ordinary IPv6 host.  Someone has to install
and run the proxies.

> during the IPv4/IPv6 transition period, it will disappear involuntarily when

There are other problems, such as IPv4 hosts sending fragmentable
packets, and the tunnel ingress router being required to fragment
them - but perhaps not knowing yet what the PMTU is to the egress
router.  The tunnel involves IPv6 routers, which can't handle
fragmentable packets.

> either locator when translating from IPv4 to RANGI. 

OK - but overall I find it difficult to imagine what applications
will do running on an IPv6 machine while communicating with an IPv4
host or vice-versa.  It might be OK for HTTP and some other
protocols, I guess.

> either locator when translating from IPv6 to RANGI.

This is multihoming of the RANGI end.  The proxy itself isn't
multihomed - nor is the IPv6 host unless it is on PI space.

> overhead will bring any serious burden on the high-speed Internet? 

The overhead is not going to stop things working, but I think we
should avoid, as much as possible, adopting architectural
enhancements which bloat all headers.  Most of the Internet may be
high-speed, but in the near future, there are going to be billions of
hosts - probably the majority of hosts - relying on slow, potentially
flaky, potentially expensive, wireless links.

> RANGI RRs can be set to a large value.

OK - sorry, I misunderstood the sentence:

   To prevent DNS recursive servers caching antique ID->Locator
   mapping information, the TTL of a RANGI RR for a mobile host
   should be set to 0 or a very small value.

as applying to all map replies, not just for mobile hosts.

> These details will be considered in the further version.

OK.

> We borrow the ideas from CGA for handling the ID collision issue.

OK - I haven't looked at CGA.

> support RANGI. In other words, there is no need to touch the site internal

OK - I wasn't questioning the techniques, just that the term "IPv4"
to me indicated addressing compatible with the global IPv4 network.
In fact, as I understand it, these 32 bits could be used in this way,
as you suggest - but they could also be used with addresses which
duplicate those in the IPv4 Internet without any problems.  So I
think a more open term than "IPv4" would be better.

> network are just ordinary IPv6 PA addresses.

Yes, this is what I understood - so I think referring to these 32
bits primarily as "IPv4" is confusing.

>> concept from the AD-based structure of the Identifier system.

OK - I am yet to hear from Michael Menth and colleagues about my
attempt to understand GLI-Split.  I started by assuming the
Identifiers could be used anywhere, but then I thought - incorrectly
according to Michael - that they could only be used within a given LD
"site".

> Each model has its pros and cons.

Some CEE architectures avoid encapsulation, which is a big benefit
over CES.   Still, I think this extra work for hosts in CEE is a
really strong reason not to adopt CEE.

> in Mobile IP since the route is already optimal.

Yes, but the ITR is usually better connected than the host, and won't
be doing lookups over a wireless link.  Also, the CES ITR will
generally do less lookups than the hosts it serves would with CEE,
because the ITR will more frequently already have the mapping cached
due to another host having also sent a packet which required the same
mapping.

In the TTR Mobility architecture, all the MN needs to do is establish
a two-way tunnel to one or more (typically, but not necessarily)
nearby TTRs, and that's it.  The MN doesn't need to do any mapping
lookups, tell correspondent hosts it has a new Locator / CoA IP
address etc.

> trust the RLOC of the incoming packets.

Yes, but this assumes that both hosts are using "edge" space.

In CEE - all hosts adopt the new system.  In CES, only those hosts in
networks which want or need portability, multihoming and inbound TE
adopt it.  So it will frequently be the case that one host is on PA
space, and so the ITR either never gets the packet, or if it does
(being implemented in an on-path router) then it simply forwards the
packet by the usual conventional algorithm, rather than doing a
mapping lookup and tunneling it to an ETR.

> system. Do you believe it is still worthwhile?

I think the idea of mobile hosts updating their own mapping is
complex and unnecessary.  In the TTR Mobility approach, the MN only
needs to tunnel from its new address to its one or more TTRs,
authenticating itself with each.  There is no need for mapping
changes, since the mapping is to one of the TTRs.  Mapping only needs
to be changed when a new TTR is used - which is typically only the
case if the MN's new point of access is more than 1000km or so away
from the current TTR.  Even then, the change is not urgent, since the
old TTR can be used perfectly well.  The change is to use a closer
TTR to minimise path lengths.  The 1000km figure is a rough guide -
the system will still work with the MN in London and the TTR in New
Zealand - its just that there will be greater delays and risk of
packet loss.

> traffic will be relayed by LDBRs through IPv4 tunnels."

I was thinking of IPv6 private addresses - I should have used the
term "Unique Local Addresses (ULA)" RFC 4193.

> OK, I will add some statement about such case.

OK.

> This statement is not true once we take the RANGI proxy mechanisms into

What I was trying to say is that if you have two hosts, and one or
both of them is multihomed, then if the requirement is for
multihoming to work when either of the hosts initiates
communications, then both hosts need to be upgraded.

I think this is true of all CEE architectures.

CES architectures are different.

  HA is on conventional space - multihomed with PI or not multihomed
  on PA space.

  HB is on "edge" space and is multihomed via two ISPs, two ETRs etc.
  via the CES architecture.

Full multihoming of HB is supported no matter whether HA or HB
initiates the communication.

As far as I know, if HX is ordinary IPv6, and (via a RANGI proxy)
initiates a communication with HY which is a multihomed RANGI host,
then HY's multihoming will be supported.  However, as far as I know,
if HY initiates the communication with HX, this does not go through
the proxy, and HY behaves like an ordinary IPv6 host.  HX sees it as
such and has no way of sending packets to an alternative address if
the one HY chose to use becomes unreachable.

> Again, thank you for these detailed comments.

OK - thanks.  Perhaps you can confirm or correct what I wrote about
multihoming.  My initial statement was too terse.

  - Robin

---

From: Robin Whittle <[email-masked]>
Date: Wed, 24 Feb 2010 17:40:33 +1100

As noted in (msg06105), in a number of messages I stated or implied
that ILNP requires upgrades to applications.  This was a mistake.
ILNP works with non-upgraded IPv6 applications.

Still, since AFAIK most applications only work with IPv4, ILNP would
require upgrades to most applications.

I wrote (msg06075, 2010-02-20):

> applications to be rewritten to use Identifiers and Locators.  

I now understand that GSE, GLI-Split and ILNP work with non-upgraded
IPv6 applications.  RANGI and Name Based Sockets require upgraded
IPv6 applications.  See my next message:

CES & CEE: GLI-Split; GSE, Six/One Router; 2008 sep./elim. paper (v3)

for an updated CEE architecture comparison table, which now includes
RANGI.

  - Robin

---

From: Xu Xiaohu <[email-masked]>
Date: Thu, 25 Feb 2010 17:33:27 +0800

Hi Robin,

Sorry for late response. Please see my reply inline.

> 发送时间: 2010年2月23日 15:01
> 收件人: 'RRG'
> 主题: Re: [rrg] RANGI questions
> 
> Hi Xiaohu,
> 

The site proxy has the similar incentive model as the ITR/ETR, while the
transit proxy has the similar incentive model as the PTR.

> router.  The tunnel involves IPv6 routers, which can't handle

As I said before, the issue is not specific to RANGI.

> host or vice-versa.  It might be OK for HTTP and some other

Please see the scenarios described in the BEHAVE WG charter.

> multihomed - nor is the IPv6 host unless it is on PI space.

The proxy is located on a site exit router which is multi-homed to more than
one ISP. Is that OK?

> flaky, potentially expensive, wireless links.

In fact, to reduce the packet overhead, once the session is established
through some initial packets, the communicating parties could allocate each
other a shorter local ID, which will be used as host ID in the subsequent
packets. Meanwhile the communicating node will maintain bindings between the
global host IDs and the corresponding local IDs locally. Is that trick
acceptable?

> think a more open term than "IPv4" would be better.

As stated in the draft, the IPv4 address which is embedded in the IPv6
address (i.e., locator) could be either public or private.

> >> indicates the values of these 32 bits need only be unique within a
given
> bits primarily as "IPv4" is confusing.

OK, I will also mention the usage of ordinary IPv6 address as locator in the
revision.

> > This host-initiated lookup eliminate the mapping work done by ITR in
CES.
> As

Is this greater delay acceptable?  If so, why people spent so many efforts
in the route optimization work for Mobile IPv6 specification?

> the proxy, and HY behaves like an ordinary IPv6 host.  HX sees it as

HY could also initiate a communication to HX (ordinary IPv6 host) via its
corresponding transit proxy if it wants. That's to say, HY will sent the
packets (in RANGI format) destined to HX towards one of its transit proxy
firstly, the transit proxy in turn will translate the RANGI packet to
ordinary IPv6 packet and then sent it towards HX. The source address of the
above IPv6 packet is HY's host ID. Is this workable?

The above approach is not mentioned in the current RANGI-Proxy draft yet.

Thanks a lot for your valuable comments.

Best wishes,
Xiaohu