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. _______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg
