draft-ietf-ipngwg-esd-analysis-03.txt   draft-ietf-ipngwg-esd-analysis-04.txt 
INTERNET-DRAFT Matt Crawford INTERNET-DRAFT Matt Crawford
Fermilab Fermilab
<draft-ietf-ipngwg-esd-analysis-03.txt> Allison Mankin <draft-ietf-ipngwg-esd-analysis-04.txt> Allison Mankin
ISI ISI
Thomas Narten Thomas Narten
IBM IBM
John W. Stewart, III John W. Stewart, III
Juniper Juniper
Lixia Zhang Lixia Zhang
UCLA UCLA
November 18, 1998 February 12, 1999
Separating Identifiers and Locators in Addresses: Separating Identifiers and Locators in Addresses:
An Analysis of the GSE Proposal for IPv6 An Analysis of the GSE Proposal for IPv6
<draft-ietf-ipngwg-esd-analysis-03.txt> <draft-ietf-ipngwg-esd-analysis-04.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft and is in full conformance with
documents of the Internet Engineering Task Force (IETF), its areas, all provisions of Section 10 of RFC2026 except that the right to
and its working groups. Note that other groups may also distribute produce derivative works is not granted.
working documents as Internet-Drafts.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
To view the entire list of current Internet-Drafts, please check the The list of current Internet-Drafts can be accessed at
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow http://www.ietf.org/ietf/1id-abstracts.txt
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
Distribution of this memo is unlimited.
This Internet-Draft expires May 15, 1999. The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract Abstract
On February 27-28, 1997, the IPng Working Group held an interim On February 27-28, 1997, the IPng Working Group held an interim
meeting in Palo Alto, California to consider adopting Mike O'Dell's meeting in Palo Alto, California to consider adopting Mike O'Dell's
'GSE - An Alternate Addressing Architecture for IPv6' proposal [GSE]. "GSE - An Alternate Addressing Architecture for IPv6" proposal [GSE].
In GSE, 16-byte IPv6 addresses are split into distinct portions for In GSE, 16-byte IPv6 addresses are split into distinct portions for
global routing, local routing and end-point identification. GSE global routing, local routing and end-point identification. GSE
includes the feature of configuring a node internal to a site with includes the feature of configuring a node internal to a site with
only the local routing and end-point identification portions of the only the local routing and end-point identification portions of the
address, thus hiding the full address from the node. When such a address, thus hiding the full address from the node. When such a
node generates a packet, only the low-order bytes of the source node generates a packet, only the low-order bytes of the source
address are specified; the high-order bytes of the address are filled address are specified; the high-order bytes of the address are filled
in by a border router when the packet leaves the site. in by a border router when the packet leaves the site.
There is a long history of a vague assertion in certain circles that There is a long history of a vague assertion in certain circles that
IPv4 'got it wrong' by treating its addresses simultaneously as IPv4 "got it wrong" by treating its addresses simultaneously as
locators and identifiers. Despite these claims, however, there was locators and identifiers. Despite these claims, however, there was
never a complete proposal for a scaleable network protocol which never a complete proposal for a scaleable network protocol which
separated the functions. As a result, it wasn't possible to do a separated the functions. As a result, it wasn't possible to do a
serious analysis comparing and contrasting a 'separated' architecture serious analysis comparing and contrasting a "separated" architecture
and an 'overloaded' architecture. The GSE proposal serves as a and an "overloaded" architecture. The GSE proposal serves as a
vehicle for just such an analysis, and that is the purpose of this vehicle for just such an analysis, and that is the purpose of this
paper. paper.
We conclude that an architecture that clearly separates locators and We conclude that an architecture that clearly separates locators and
identifiers in addresses introduces new issues and problems that do identifiers in addresses introduces new issues and problems that do
not have an easy or clear solution. Indeed, the alleged not have an easy or clear solution. Indeed, the alleged
disadvantages of overloading addresses turn out to provide some disadvantages of overloading addresses turn out to provide some
significant benefits over the non-overloaded approach. significant benefits over the non-overloaded approach.
Contents Contents
skipping to change at page 3, line 7 skipping to change at page 3, line 7
4.2.2. End-System Designator.......................... 18 4.2.2. End-System Designator.......................... 18
4.3. Address Rewriting by Border Routers................. 19 4.3. Address Rewriting by Border Routers................. 19
4.4. Renumbering and Rehoming Mid-Level ISPs............. 20 4.4. Renumbering and Rehoming Mid-Level ISPs............. 20
4.5. Support for Multi-Homed Sites....................... 21 4.5. Support for Multi-Homed Sites....................... 21
4.6. Explicit Non-Goals for GSE.......................... 22 4.6. Explicit Non-Goals for GSE.......................... 22
5. Analysis: The Pros and Cons of Overloading Addresses..... 22 5. Analysis: The Pros and Cons of Overloading Addresses..... 22
5.1. Purpose of an Identifier............................ 23 5.1. Purpose of an Identifier............................ 23
5.2. Mapping an Identifier to a Locator.................. 25 5.2. Mapping an Identifier to a Locator.................. 25
5.2.1. Scalable Mapping of Identifiers to Locators.... 27 5.2.1. Scalable Mapping of Identifiers to Locators.... 27
5.2.2. Insufficient Hierarchy Space in ESDs........... 28 5.2.2. Insufficient Hierarchy Space in ESDs........... 27
5.3. Authentication of Identifiers....................... 28 5.3. Authentication of Identifiers....................... 28
5.3.1. Identifier Authentication in IPv4.............. 29 5.3.1. Identifier Authentication in IPv4.............. 29
5.3.2. Identifier Authentication in GSE............... 30 5.3.2. Identifier Authentication in GSE............... 30
5.4. Transport Layer: What Locator Should Be Used?....... 30 5.4. Transport Layer: What Locator Should Be Used?....... 30
5.4.1. RG Selection On An Active Open................. 31 5.4.1. RG Selection On An Active Open................. 31
5.4.2. RG Selection On An Passive Open................ 31 5.4.2. RG Selection On An Passive Open................ 31
5.4.3. Mid-Connection RG Changes...................... 32 5.4.3. Mid-Connection RG Changes...................... 31
5.4.4. The Impact of Corrupted Routing Goop........... 33 5.4.4. The Impact of Corrupted Routing Goop........... 33
5.5. On The Uniqueness Of ESDs........................... 34 5.5. On The Uniqueness Of ESDs........................... 34
5.5.1. Impact of Duplicate ESDs....................... 34 5.5.1. Impact of Duplicate ESDs....................... 34
5.5.2. New Denial of Service Attacks.................. 35 5.5.2. New Denial of Service Attacks.................. 35
5.6. Summary of Identifier Authentication Issues......... 36 5.6. Summary of Identifier Authentication Issues......... 35
6. Conclusion............................................... 37 6. Conclusion............................................... 37
7. Security Considerations.................................. 38 7. Security Considerations.................................. 38
8. Acknowledgments.......................................... 38 8. Acknowledgments.......................................... 38
9. References............................................... 39 9. References............................................... 38
10. Authors' Addresses...................................... 40 10. Authors' Addresses...................................... 40
Appendix A: Increased Reliance on Domain Name System (DNS)... 41 Appendix A: Increased Reliance on Domain Name System (DNS)... 41
Appendix B: Additional Issues Related to GSE................. 45 Appendix B: Additional Issues Related to GSE................. 45
Appendix C: Ideas Incorporated Into IPv6..................... 46 Appendix C: Ideas Incorporated Into IPv6..................... 46
Appendix D: Reverse Mapping of Complete GSE Addresses........ 47 Appendix D: Reverse Mapping of Complete GSE Addresses........ 47
skipping to change at page 14, line 38 skipping to change at page 14, line 38
1) The site can number a distinct set of hosts out of each of the 1) The site can number a distinct set of hosts out of each of the
prefixes. Consider a configuration where a site is connected to prefixes. Consider a configuration where a site is connected to
ISP-A and ISP-B. If the link to ISP-A goes down, then unless ISP-A and ISP-B. If the link to ISP-A goes down, then unless
the ISP-A prefix is announced to ISP-B (which breaks the ISP-A prefix is announced to ISP-B (which breaks
aggregation), the hosts numbered out of the ISP-A prefix would aggregation), the hosts numbered out of the ISP-A prefix would
be unreachable. be unreachable.
2) The site could assign each host multiple addresses (i.e., one 2) The site could assign each host multiple addresses (i.e., one
address for each ISP connection). There are two problems with address for each ISP connection). There are two problems with
this. First, it accelerates the consumption of the address this. First, it accelerates the consumption of the address
space, albeit this is less problematic for the IPv6 address space. While this may be a problem for the (limited) IPv4
space, and the related important problem is overall size of the address space, it is not a significant issue in IPv6. Second,
routing tables. Second, when the connection to ISP-A goes down, when the connection to ISP-A goes down, addresses numbered out
addresses numbered out of ISP-A's space become unreachable. of ISP-A's space become unreachable. Remote peers would have to
Remote peers would have to have sufficient intelligence to use have sufficient intelligence to use the second address. For
the second address. For example, when initiating a connection example, when initiating a connection to a host, the DNS would
to a host, the DNS would return multiple candidate addresses. return multiple candidate addresses. Clients would need to try
Clients would need to try them all before concluding that a them all before concluding that a destination is unreachable
destination is unreachable (something not all network (something not all network applications currently do). In
applications currently do). In addition, a site's hosts would addition, a site's hosts would need a significant amount of
need a significant amount of intelligence for choosing the intelligence for choosing the source addresses they use. A host
source addresses they use. A host shouldn't choose a source shouldn't choose a source address corresponding to a link that
address corresponding to a link that is down. At present, hosts is down. At present, hosts do not have such sophistication.
do not have such sophistication.
In summary, how best to support multi-homing with IPv4/CIDR faces a In summary, how best to support multi-homing with IPv4/CIDR faces a
delicate balance between the scalability of routing versus the site's delicate balance between the scalability of routing versus the site's
requirements of robustness and load-sharing. At this point in time, requirements of robustness and load-sharing. At this point in time,
no solution has been discovered that satisfies the competing no solution has been discovered that satisfies the competing
requirements of route scaling and robustness/performance. It is requirements of route scaling and robustness/performance. It is
worth noting, however, that some people are beginning to study the worth noting, however, that some people are beginning to study the
issue more closely and propose novel ideas [BATES]. issue more closely and propose novel ideas [BATES].
4. The GSE Proposal 4. The GSE Proposal
skipping to change at page 22, line 15 skipping to change at page 22, line 15
4.6. Explicit Non-Goals for GSE 4.6. Explicit Non-Goals for GSE
It is worth noting explicitly that GSE did not attempt to address the It is worth noting explicitly that GSE did not attempt to address the
following issues: following issues:
1) Survival of TCP connections through renumbering events. If a 1) Survival of TCP connections through renumbering events. If a
site is renumbered, TCP connections using a previous address site is renumbered, TCP connections using a previous address
will continue to work only as long as the previous address still will continue to work only as long as the previous address still
works (i.e., while it is still "valid" using RFC 1971 works (i.e., while it is still "valid" using RFC 1971
terminology). No attempt is made to have existing connections terminology). No attempt is made to have existing connections
switch to the new address. In contrast, TCP on hosts with IPv6 switch to the new address.
mobility features can survive renumbering events [MOBILITY6].
2) It is not known how multicast can be made to work under GSE. 2) It is not known how multicast can be made to work under GSE.
3) It is not known how mobility can be made to work under GSE. 3) It is not known how mobility can be made to work under GSE.
4) The performance impact of having routers rewrite portions of the 4) The performance impact of having routers rewrite portions of the
source and destination address in packet headers requires source and destination address in packet headers requires
further study. further study.
That GSE didn't address 2-4 above does not mean they cannot be That GSE didn't address the above does not mean they cannot be
solved. Rather, the issues simply weren't studied in sufficient solved. Rather, the issues simply weren't studied in sufficient
depth. depth.
5. Analysis: The Pros and Cons of Overloading Addresses 5. Analysis: The Pros and Cons of Overloading Addresses
At this point we have given complete descriptions of two addressing At this point we have given complete descriptions of two addressing
architectures: IPv4, which uses the overloading technique, and GSE, architectures: IPv4, which uses the overloading technique, and GSE,
which uses the separated technique. We now compare and contrast the which uses the separated technique. We now compare and contrast the
two techniques. two techniques.
skipping to change at page 24, line 23 skipping to change at page 24, line 20
but the identifier used by the sending node has changed, the but the identifier used by the sending node has changed, the
recipient would be unable to distinguish this case from that of a recipient would be unable to distinguish this case from that of a
packet received from a completely different node. packet received from a completely different node.
In the specific case of TCP and IPv4, connections are identified In the specific case of TCP and IPv4, connections are identified
uniquely by the tuple: (srcIPaddr, dstIPaddr, srcport, dstport). uniquely by the tuple: (srcIPaddr, dstIPaddr, srcport, dstport).
Because IPv4 addresses contain a combined locator/identifier, it is Because IPv4 addresses contain a combined locator/identifier, it is
not possible to have a node's location change without also having its not possible to have a node's location change without also having its
identifier change. Consequently, when a mobile node moves, its identifier change. Consequently, when a mobile node moves, its
existing connections no longer work, in the absence of special existing connections no longer work, in the absence of special
protocols such as Mobile IP [MOBILITY]. Note that in IPv4 mobility, protocols such as Mobile IP [MOBILITY].
the mobile host's address is preserved, but in IPv6 mobility
[MOBILITY6], the mobile host can functionally have a new address,
because the packet includes an option storing the old and the
correspondent's IP rewrites it transparently to the transport
protocol. The identifier of the mobile's packet remains its original
address.
In contrast, connections in GSE are identified by the ESDs rather In contrast, connections in GSE are identified by the ESDs rather
than full IPv6 addresses. That is, connections are identified than full IPv6 addresses. That is, connections are identified
uniquely by the tuple: (srcESD, dstESD, srcport, dstport). uniquely by the tuple: (srcESD, dstESD, srcport, dstport).
Consequently, when demultiplexing incoming packets to their proper Consequently, when demultiplexing incoming packets to their proper
end point, TCP would ignore the Routing Stuff portions of addresses. end point, TCP would ignore the Routing Stuff portions of addresses.
Because the Routing Stuff portion of an address is ignored during Because the Routing Stuff portion of an address is ignored during
demultiplexing operations, a mobile node is free to move -- and demultiplexing operations, a mobile node is free to move -- and
change its Routing Stuff -- without changing its identification. change its Routing Stuff -- without changing its identification.
skipping to change at page 38, line 5 skipping to change at page 37, line 38
to-date locators. However, relying on the locator provided at the to-date locators. However, relying on the locator provided at the
time communication is established as GSE does is inadequate when the time communication is established as GSE does is inadequate when the
remote locator can change dynamically, precisely the scenario that is remote locator can change dynamically, precisely the scenario that is
supposed to benefit from the separation. That is, the benefits of supposed to benefit from the separation. That is, the benefits of
separating the identifier from the locator are largely lost, if the separating the identifier from the locator are largely lost, if the
changes in the identifier to locator binding are not tracked quickly. changes in the identifier to locator binding are not tracked quickly.
Secondly, when communicating with a remote site, if the RG changes Secondly, when communicating with a remote site, if the RG changes
there begins to be uncertainty as to whether a reliable TCP handshake there begins to be uncertainty as to whether a reliable TCP handshake
is possible (because of the need for passively opened TCP to use the is possible (because of the need for passively opened TCP to use the
RG's it obtains from the packets). There cannot be an reliable byte RG's it obtains from the packets). Because the reliability of TCP's
stream without the TCP handshake, and this technology seems strongly byte stream is critically dependent on its three-way handshake, this
tied to locator/identifier coupling in one address. is a significant issue.
Finally, when communicating with a remote site, a receiver must be Finally, when communicating with a remote site, a receiver must be
able to insure (with reasonable certainty) that received data does able to insure (with reasonable certainty) that received data does
indeed come from the expected remote entity. In IPv4, it is possible indeed come from the expected remote entity. In IPv4, it is possible
to receive packets from a forged source, but the potential for to receive packets from a forged source, but the potential for
mischief between communicating peers is significantly limited because mischief between communicating peers is significantly limited because
return traffic will not generally reach the source of the forged return traffic will not generally reach the source of the forged
traffic. That is, communication involving packets sent in both traffic. That is, communication involving packets sent in both
directions will not succeed. In contrast, architectures like GSE directions will not succeed. In contrast, architectures like GSE
that decouple the identifier and locator functions lose the built-in that decouple the identifier and locator functions lose the built-in
protection available in classical IP and thus face great difficulty protection available in classical IP and thus face great difficulty
assuring that traffic from a source identified only by an identifier assuring that traffic from a source identified only by an identifier
actually comes from the correct source. Short of using cryptographic actually comes from the correct source. Short of using cryptographic
techniques (e.g. IPsec, which would encounter its own difficulties techniques (e.g. IPsec), there is no known mechanism that can use an
with the separation of locator from identifier), there is no known identifier alone to perform this remote entity authentication. Using
mechanism that can use an identifier alone to perform this remote an identifier alone for authentication of received packets is
entity authentication. Using an identifier alone for authentication dangerously unsafe.
of received packets is dangerously unsafe.
In summary, although overloading the address field with a combined In summary, although overloading the address field with a combined
identifier and locator leads to difficulties in retaining the identifier and locator leads to difficulties in retaining the
identity of a node whenever its address changes, analysis in this identity of a node whenever its address changes, analysis in this
paper suggests that the benefit of the overloading actually out- paper suggests that the benefit of the overloading actually out-
weighs its cost. Completely separating an identifier from its weighs its cost. Completely separating an identifier from its
locator renders the identifier untrustworthy, thus useless, in the locator renders the identifier untrustworthy, thus useless, in the
absence of an accompanying authentication system. absence of an accompanying authentication system.
7. Security Considerations 7. Security Considerations
skipping to change at page 40, line 14 skipping to change at page 39, line 45
Microprocessor systems: Control and Status Registers (CSR) Microprocessor systems: Control and Status Registers (CSR)
Architecture for microcomputer buses." Architecture for microcomputer buses."
[IPv6-ADDRESS] "An IPv6 Aggregatable Global Unicast Address [IPv6-ADDRESS] "An IPv6 Aggregatable Global Unicast Address
Format", R. Hinden, M. O'Dell, S. Deering, RFC 2374, July, Format", R. Hinden, M. O'Dell, S. Deering, RFC 2374, July,
1998. 1998.
[MOBILITY] "IP Mobility Support", C. Perkins, RFC 2002, October, [MOBILITY] "IP Mobility Support", C. Perkins, RFC 2002, October,
1996. 1996.
[MOBILITY6] "Mobility Support in IPv6", D. Johnson, C. Perkins, ,
(Work in progress).
[RFC1752] "The Recommendation for the IP Next Generation Protocol", [RFC1752] "The Recommendation for the IP Next Generation Protocol",
S. Bradner, A. Mankin, RFC 1752, January, 1995. S. Bradner, A. Mankin, RFC 1752, January, 1995.
[RFC1788] "ICMP Domain Name Messages", W. Simpson, RFC 1788, April, [RFC1788] "ICMP Domain Name Messages", W. Simpson, RFC 1788, April,
1995. 1995.
[RFC1884] "IP Version 6 Addressing Architecture", R. Hinden & S. [RFC1884] "IP Version 6 Addressing Architecture", R. Hinden & S.
Deering, Editors, RFC 1884. Deering, Editors, RFC 1884.
[RFC1958] "Architectural Principles of the Internet", B. Carpenter, [RFC1958] "Architectural Principles of the Internet", B. Carpenter,
 End of changes. 20 change blocks. 
58 lines changed or deleted 46 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/