Re: [rrg] RANGI questions

[Xu Xiaohu <[e-mail]>]

Hi Robin,

Sorry for late response. Please see my reply inline.

> -----邮件原件-----
> 发件人: Robin Whittle [mailto:[e-mail]]
> 发送时间: 2010年2月23日 15:01
> 收件人: 'RRG'
> 抄送: Xu Xiaohu
> 主题: Re: [rrg] RANGI questions
> 
> Hi Xiaohu,
> 
> Thanks for your response, in which you wrote:
> 
> >> 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.
> >
> > 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.
> 
> 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.

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

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

As I said before, the issue is not specific to 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.
> 
> 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.

Please see the scenarios described in the BEHAVE WG charter.

> >> 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 proxy CAN support multi-homing since the multi-homed proxy can use
> > 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.

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

> >> 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.
> >
> > Yes, your observation is correct. However, do you think this extra bit
> > 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.

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?

> >> 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.
> >
> > 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.
> 
> 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.
> 
> 
> >> 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.
> >
> > These details will be considered in the further version.
> 
> OK.
> 
> 
> >> 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.
> >
> > 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.
> 
> OK - I haven't looked at CGA.
> 
> 
> >> 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.
> >
> > 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.
> 
> 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.

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

> >> 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.
> >
> > If a site network is already IPv6 only, locators of the hosts within
that
> > 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.

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

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

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

> >> 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.
> >
> > 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."
> 
> I was thinking of IPv6 private addresses - I should have used the
> term "Unique Local Addresses (ULA)" RFC 4193.
> 
> 
> >> 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.
> >
> > OK, I will add some statement about such case.
> 
> OK.
> 
> 
> >> 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.
> >
> > This statement is not true once we take the RANGI proxy mechanisms into
> > account.
> 
> 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

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

> such and has no way of sending packets to an alternative address if
> the one HY chose to use becomes unreachable.
> 
> 
> >> 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
> >
> > 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.
> 
> OK - thanks.  Perhaps you can confirm or correct what I wrote about
> multihoming.  My initial statement was too terse.
> 
>   - Robin