IETF F. Templin Internet Draft March 2000 An IPv6-IPv4 Compatibility Aggregatable Global Unicast Address Format Copyright Notice Placeholder for ISOC copyright. Abstract draft-templin-ngtrans-v6v4compat-00.txt This memo specifies an IPv6-IPv4 compatibility aggregatable global unicast address format for any IPv6 host, gateway or router that has at least one globally unique IPv4 address. The approach outlined in this memo allows for large-scale incremental deployment of IPv6 hosts within heterogeneous IPv6/v4 domains without incurring aggregation scaling issues at the border gateways. This address format supports both global routing within the native IPv6 routing domain and automatic tunneling across IPv4 networks with no native IPv6 support. This memo additionally specifies a non-globally routable IPv6-IPv4 compatibility address format for use within private networks with non-globally unique IPv4 addresses. Finally, this memo proposes a method for global routing of such addresses through a combination of mechanisms specified in this document and other works in progress in the NGTRANS working group. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Templin Expires August 2000 [Page 1] Internet Draft IPv6-IPv4 Compatibility Address Format March 2000 Table of Contents: Status of this Memo.............................................1 1. Introduction.................................................2 2. IPv6-IPv4 compatibility address format.......................3 3. Routing considerations.......................................5 4. Address selection considerations.............................7 5. Multicast considerations.....................................8 6. Address autoconfiguration; router discovery considerations...8 7. Relation to other works in progress..........................8 8. Implementation status........................................8 9. IANA considerations..........................................8 10. Security considerations.....................................9 Acknowledgements................................................9 References......................................................9 Authors' Addresses.............................................10 Intellectual Property..........................................10 Full Copyright Statement.......................................10 1. Introduction The global Internet infrastructure is comprised of communications entities known as hosts, gateways and routers (hereafter collectively referred to as nodes) that exchange messages using the Internet Protocol [IPV4]. IPv4 includes a 32-bit address space which effectively limits the number of unique IPv4 addresses to 2^32. (In practice, the actual number of unique addresses available is considerably less than 2^32 due to constraints imposed by the IPv4 addressing architecture.) To eliminate the IPv4 address space limitation issue (as well as to address other limitations of the IPv4 protocol), the IPNG working group of the Internet Engineering Task Force (IETF) has developed a next-generation Internet Protocol [IPV6] to succeed IPv4. IPv6 specifies a 128-bit address space [ADDR] which expands the number of uniquely addressable entities by staggering orders of magnitude over the existing IPv4 addressing architecture. IPv6 also includes numerous additional architectural improvements over IPv4, such as address autoconfiguration, neighbor discovery, and router discovery [AUTO][DISC]. But, the IPv4 protocol is so well understood and so deeply entrenched in the existing Internet infrastructure that migration to IPv6 will require a transition period during which IPv6 will initially coexist with then gradually begin to supplant the existing IPv4 installed base. Due to these transition considerations, we anticipate an heterogeneous IPv6/IPv4 infrastructure at both the inter-domain and intra-domain levels for the near future. We further anticipate that existing IPv4 nodes will retain their IPv4 addresses, but will also receive IPv6 address assignments such that these nodes will communicate via both the IPv4 and IPv6 protocols in the near term. In order to support such a heterogeneous IPv6/IPv4 infrastructure in transition, we propose a new aggregatable global unicast address form that we call the the "IPv6-IPv4 Compatibility Address". This address will carry a standard IPv6 aggregatable global unicast address prefix (with FP = '001' and topologically correct aggregation identifiers) as specified in [ADDR] and [AGGR], but the 64-bit EUI-64 format Interface Identifier [EUI64] will be constructed from the special-purpose IEEE Organizationally Unique Identifier (OUI) reserved by the Internet Assigned Numbers Authority [IANA] along with a type field to indicate that the interface identifier encapsulates an IPv4 address of the node. Templin Expires August 2000 [Page 2] Internet Draft IPv6-IPv4 Compatibility Address Format March 2000 This address format will allow a pair of nodes with IPv6-IPv4 compatibility addresses to exchange messages either directly across a native IPv6 routing infrastructure or automatically tunneled over the existing IPv4 routing infrastructure with no pre-configured tunnel state. Thus it is compatible with the intermediate network cloud between the nodes being either IPv6 or IPv4 initially, but gradually transitioning to IPv6. It will further enable incremental intra-domain deployment of IPv6 nodes in heterogeneous IPv6/v4 intranets without incurring aggregation scaling issues at border gateways, yet still support inter-domain operation in both the IPv6 and IPv4 domains in cases where privacy concerns are not a factor. Thus the intra-domain transition to IPv6 can be gradual and not necessarily done all at once. Finally, if combined with other emerging approaches from the NGTRANS working group [6TO4][MECH] this address format will also support heterogeneous IPv6/v4 intranets which use non-globally unique IPv4 addresses and heterogeneous IPv6/v4 intranets which use globally unique IPv4 addresses but employ firewalls or other special border gateways to avoid exposure of internal IPv4 addresses to the public Internet to protect privacy. Some examples of such cases are discussed in the body of the text. 2. IPv6-IPv4 Compatibility Address Format Before we discuss our IPv6-IPv4 compatibility address format, sections 2.1 and 2.2 will motivate our proposed extensions of the existing IEEE OUI reserved by IANA to support IEEE EUI-64 format addresses. While these proposed extensions are necessary to support our IPv6-IPv4 compatibility address format, they also provide a flexible framework for future IANA use. Therefore, we believe the extensions proposed in sections 2.1 and 2.2 may provide beneficial future use to the IANA beyond the scope of IPv6-IPv4 compatibility addresses. We present our IPv6-IPv4 compatibility address proposal in sections 2.3 through 2.5. 2.1 IEEE EUI-64 Interface Identifiers in IPv6 Addresses IPv6 aggregatable global and local-use unicast addresses [ADDR] include a 64-bit interface identifier in IEEE EUI-64 format [EUI64], which is specified as the concatenation of a 24-bit company_id value (also known as the OUI) assigned by the IEEE Registration Authority (IEEE/RAC) and a 40-bit extension identifier assigned by the organization owning that OUI. IEEE EUI-64 interface identifiers are formatted as follows: |0 1|1 3|3 4|4 6| |0 5|6 1|2 7|8 3| +----------------+----------------+----------------+----------------+ |ccccccugcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm| +----------------+----------------+----------------+----------------+ Where 'c' are the company-specific bits of the OUI, 'u' is the universal/local bit, 'g' is the individual/group bit and 'm' are the extension identifier bits. (NOTE: [ADDR] specifies that the 'u' bit is inverted from its normal sense in the IEEE context; therefore u=1 indicates global scope and u=0 indicates local scope). In order to support encapsulation of legacy IEEE EUI-48 (24-bit) extension identifier values, [EUI64] specifies that the first two octets of the EUI-64 40-bit extension identifier (bits 24 through 39 of the EUI-64 address itself) SHALL BE 0xFFFE if the extension identifier encapsulates an EUI-48 value. [EUI64] further specifies that the first two octets of the extension identifier SHALL NOT be 0xFFFF, as this value Templin Expires August 2000 [Page 3] Internet Draft IPv6-IPv4 Compatibility Address Format March 2000 is reserved by the IEEE/RAC. However, all other 40-bit extension identifier values are available for assignment by the addressing authority responsible for a given OUI. 2.2 An EUI-64 Interface Identifier Format for IANA The IANA owns IEEE OUI: 0x00005E (also written as: 00-00-5E), and [IANA] specifies EUI-48 format (24-bit) interface identifier assignments within that OUI. But, [IANA] does not specify how these legacy EUI-48 assignments will be written in EUI-64 format, nor does it specify a format for future 40-bit extension identifier assignments. We propose the following format for EUI-64 addresses within IANA's OUI reservation: |0 2|2 3|3 3|4 6| |0 3|4 1|2 9|0 3| +------------------------+--------+--------+------------------------+ | OUI ("00-00-5E"+u+g) | TYPE | TSE | TSD | +------------------------+--------+--------+------------------------+ Where the fields are: OUI IANA's OUI: 00-00-5E with 'u' and 'g' bits (3 octets) TYPE Type field; indicates how (TSE, TSD) are interpreted (1 octet) TSE Type-Specific Extension (1 octet) TSD Type-Specific Data (3 octets) And the following interpretations are defined based on TYPE: TYPE (TSE, TSD) Interpretation ---- ------------------------- 0x00-0xFD RESERVED for future IANA use 0xFE (TSE, TSD) together contain an embedded IPv4 address 0xFF TSD is interpreted based on TSE as follows: TSE TSD Interpretation --- ------------------ 0x00-0xFD RESERVED for future IANA use 0xFE TSD contains 24-bit EUI-48 intf identifier 0xFF RESERVED by IEEE/RAC Essentially, if TYPE=0xFE, TSE is treated as an extension of TSD. If TYPE=0xFF, TSE is treated as an extension of TYPE. Other values for TYPE (and hence, other interpretations of TSE, TSD) are reserved for future IANA use. This format conforms to all requirements specified in [EUI64] and supports encapsulation of EUI-48 interface identifiers in the manner described by that document. For example, an existing IANA EUI-48 format multicast address such as: 01-00-5E-01-02-03 would be written in the IANA EUI-64 format as: 01-00-5E-FF-FE-01-02-03 Templin Expires August 2000 [Page 4] Internet Draft IPv6-IPv4 Compatibility Address Format March 2000 But, this proposed format also provides a special TYPE (0xFE) for embedding IPv4 addresses within the IANA 40-bit extension identifier. This special TYPE forms the basis for our IPv6-IPv4 compatiblitiy aggregatable global unicast address format proposal as described in sections 2.3 through 2.5. 2.3 IPv6-IPv4 Compatibility Aggregatable Using the proposed IANA-specific method for interface identifier construction discussed in sections 2.1 and 2.2 (with TYPE=0x00), and with reference to [ADDR], we can construct IPv6-IPv4 compatibility aggregatable global unicast addresses. Using this methodology, we propose an IPv6 address format with embedded IPv4 address in the EUI-64 interface identifier. The following diagram shows the construction: | 3| 13 | 8 | 24 | 16 | 8 | 8 | 8 | 8 | 32 bits | +--+-----+---+--------+--------+---+---+---+---+---+---+---+----+ |FP| TLA |RES| NLA | SLA | 0x| 0x| 0x| 0x| IPv4 Address | | | ID | | ID | ID | 02| 00| 5E| FE| of Endpoint | +--+-----+---+--------+--------+--------------------------------+ (NOTE: the least significant octet of the OUI in the interface identifier is 0x02 instead of 0x00 since u=1 for global scope.) By way of example, an existing Internet node with the globally unique IPv4 address of 140.173.129.8 might be assigned an IPv6 64-bit prefix of 3FFE:1a05:510:200::/64. We can then construct an IPv6-IPv4 compatibility aggregatable global unicast address for this node as: 3FFE:1a05:510:200:0200:5EFE:8CAD:8108 or (perhaps more appropriately) written as the alternative form for an IPv6 address with embedded IPv4 address found in [ADDR]: 3FFE:1a05:510:200:0200:5EFE:140.173.129.8 Similarly, we can construct the link-local and site-local variants (respectively) of the IPv6-IPv4 compatibility address as: FE80::0200:5EFE:140.173.129.8 FEC0::200:0200:5EFE:140.173.129.8 2.4 Advantages By embedding an IPv4 address in the interface identifier portion of an IPv6 address as described in section 2.3, we can construct aggregatable global unicast addresses that can either be routed via the IPv6 infrastructure or automatically tunneled across portions of the IPv4 infrastructure which have no native IPv6 routing support. Thus the addressing scheme would support heterogeneous IPv6/IPv4 intra-domain and inter-domain infrastructures in transition with incremental deployment of IPv6. Additionally, a node with such an IPv6-IPv4 compatibility address could act as a router for nodes with native IPv6 addresses connected to the same link, since it could automatically tunnel messages across the IPv4 domain to reach other IPv6 "islands" on the behalf of such native IPv6 nodes. An example would be deployment of IPv6 on some subset of the hosts Templin Expires August 2000 [Page 5] Internet Draft IPv6-IPv4 Compatibility Address Format March 2000 attached to a workgroup's Ethernet LAN. In this case, one host would receive an IPv6-IPv4 compatibility address and act as a router for the other hosts which receive native IPv6 addresses. Such a scenario can be thought of as a "dense mode" IPv6 deployment. An additional advantage for our proposed method of embedding an IPv4 address in the interface identifier portion of an IPv6 address not found in other approaches such as [6TO4] is that large numbers of IPv6-IPv4 compatibility addresses could be assigned within a common IPv6 routing prefix up to the SLA ID, thus providing maximal aggregation at the border gateways. For example, the single 48-bit IPv6 prefix: 3FFE:1a05:510::/48 could include many hundreds or thousands of nodes with IPv6-IPv4 compatibility addresses. This feature would allow a "sparse mode" IPv6 deployment such as the deployment of sparse populations of IPv6 hosts on large numbers of independent links throughout a large corporate Intranet. A final important advantage is that well-formed and globally unique link-local and site-local addresses which contain embedded IPv4 addresses can be directly derived from IPv6-IPv4 compatibility addresses constructed as described in section 2.3. This would allow mobile nodes to quickly join and leave wireless clusters using their existing link-local addresses for neighbor discovery instead of having to obtain link-local addresses specific to the new clusters they visit. (This scenario in fact served as the fundamental motivating factor for the approach described in this draft.) 2.5 Interoperability Implications Our proposed IANA-specific method for the assignment of interface identifiers with embedded IPv4 addresses represents a departure from the existing convention of using the IEEE EUI-48 MAC address stored in an OEM manufacturer's network interface attached to the node. But, an interface identifier constructed in this manner would be globally unique and fully-qualified in the sense of EUI-64 and thus would present no interoperability issues. Moreover, such an interface identifier construction would actually have a number of advantages over interface identifiers derived from an OEM manufacturer's device, including: 1) The MAC address stored in an OEM manufacturer's device is permanently assigned to that device. If an old device is discarded and a new one installed in its place, the node will receive a totally different interface identifier which will require updates to the DNS. Interface identifiers constructed using the IANA OUI with a globally unique IPv4 address as described above do not suffer this problem. 2) While it is expected that OEM manufacturers will assign unique IEEE 48bit MAC addresses from their OUI(s) for the individual devices they manufacture and sell, there is no guarantee that they will act as responsible addressing authorities. In contrast, globally unique IPv4 addresses are assigned by organizations such as ARIN, APNIC, RIPE, etc which are widely regarded as trustworthy addressing authorities. Templin Expires August 2000 [Page 6] Internet Draft IPv6-IPv4 Compatibility Address Format March 2000 3) The IEEE 48bit MAC addresses assigned to OEM manufacturer's devices are volatile; when an old device is discarded there is no reliable mechanism for the OEM manufacturer to reclaim and reuse its MAC address. In contrast, IPv4 network administrators and addressing authorities such as those mentioned above strive to reclaim IPv4 addresses no longer in use. 3. Routing considerations 3.1 Intra-domain routing considerations Within a single domain (e.g. within a private Intranet, corporate network, or some other network managed under a single administrative authority) the IPv6-IPv4 compatibility address format described in section 2 provides well formed addresses suitable for either seamless routing in the IPv6 routing infrastructure or automatic tunneling across the IPv4 routing infrastructure. A source node with an IPv6-IPv4 compatibility address which sends an IPv6 message to a destination node with an IPv6-IPv4 compatibility address can employ routing policy decisions such as: - if the IPv6 routing table has an entry for the destination's IPv6 prefix, and there is a path to gateway for the destination's IPv6 prefix through the IPv6 routing infrastructure (*), send as a native IPv6 packet to the IPv6 gateway for that prefix - if the IPv4 routing table has an entry for a prefix of the destination's embedded IPv4 address, tunnel the IPv6 packet through the IPv4 routing infrastructure (using IP protocol 41) by encapsulating it in the manner described in [MECH] (**) - if the IPv6 routing table has an entry for 'default', and there is a path to the default IPv6 gateway through the IPv6 routing infrastructure (*), send as a native IPv6 packet to the default IPv6 gateway (*) If there is no path to the IPv6 gateway through the IPv6 routing infrastructure, tunnel the IPV6 packet through the IPv4 routing infrastructure using the gateway's embedded IPv4 address as the destination for the tunneled packet. This implies that the gateways must also use IPv6-IPv4 compatibility addresses. (**) [MECH] specifies an automatic tunneling mechanism for IPv4-compatible addresses formed as the 96-bit prefix 0:0:0:0:0:0/96 followed by the embedded IPv4 address. But, this same mechanism may be used for the IPv6-IPv4 compatibility address format proposed in this draft by truncating the leading 96-bits of the address. It is also important to notice that, in the intra-domain case, IPv4 addresses may not be globally unique but may be allocated through some private network addressing scheme which has meaning only within the context of that domain. But, we can construct a SECOND form of the Templin Expires August 2000 [Page 7] Internet Draft IPv6-IPv4 Compatibility Address Format March 2000 IPv6-IPv4 compatibility address described in section 2 by inverting the sense of the 'u/l' bit for private IPv4 addresses. For example, a node with the private (non globally unique) IPv4 address 10.0.0.1 could be assigned the IPv6-IPv4 compatibility address: 3FFE:1a05:510:200:0000:5EFE:10.0.0.1 (using the same example IPv6 prefix and IANA OUI given in section 2) with the 'u/l' bit in the EUI-64 interface identifier cleared to indicate that this is a LOCAL address. But, such an address could be treated using the same routing decision policies given above in the intra-domain case since private addresses are eligible for IPv4 routing within that domain. 3.2 Inter-domain routing considerations 3.2.1 Globally-unique IPv4 addresses with no privacy concerns In cases where nodes within an heterogeneous IPv6/v4 domain use globally unique IPv4 addresses and where no privacy concerns exist regarding exposure of internal IPv4 addresses to the public Internet, messages may be routed across domain boundaries using the same sort of routing policy decisions outlined in section 3.1. This will expose IPv4 addresses from within the domain across the public Internet, but some sites may not view this as a security issue. 3.2.2 Globally-unique IPv4 addresses WITH privacy concerns If the administrative authority for a domain institutes a policy of not exposing internal IPv4 addresses across the public Internet, border gateways may be established which implement another form of IPv6-IPv4 compatible routing for inter-domain operation. A perfect example of such a mechanism is given in [6TO4]. In this instance, intra-domain routing policy decisions would still resemble those found in section 3.1 and nodes within the domain would still use the IPv6-IPv4 compatibility address form found in section 2. But, border gateways would be established in the manner of [6TO4]. These border gateways would advertise the IPv6 prefix 2002::/16 as described in [6TO4] and the IPv6 prefix 2002:V4ADDR/48 where 'V4ADDR' is the (globally unique) embedded IPv4 address of the border gateway. Then, IPv6 compatibility addresses WITHIN the domain would be constructed as the concatenation of a 2002:V4ADDR/48 prefix, a 16-bit SLA ID, and a 64-bit EUI64 interface identifier constructed in the manner of section 2 of this document. Templin Expires August 2000 [Page 8] Internet Draft IPv6-IPv4 Compatibility Address Format March 2000 For example, if the IPv4 address of the border gateway is 140.173.0.1, the IPv4 address of the node within the domain is 140.173.129.8 and the node resides within SLA ID 0x001, the IPv6 address within the domain is constructed as: 2002:8CAD:1:1:0200:5EFE:8CAD:8108 ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ | | | | | | | | | | | | | | | | | | +-------+-- (TSE, TSD) = 140.173.129.8 | | | | | | | | | | | | | | | +------------ TYPE = 0xFE | | | | | | | | | | | | +-----+-------------- OUI = 02-00-5E | | | | | | | | | +---------------------- SLA ID = 0x0001 | | | | | | +----+------------------------ (RES, NLA) = 140.173.0.1 | | +--+------------------------------- (FP, TLA) = [6TO4] prefix But, if the administrative authority wished to avoid exposing internal IPv4 addresses to the public Internet, the border gateway could perform some form of "reverse network address translation" in which the IPv4 address of the node in the EUI64 interface identifier would be replaced with some other identifier not vulnerable to eavesdropping. (The border gateway would need to maintain state for the mapping of the replacement value to the actual IPv4 address of the node in order to map messages from destinations back to the actual node within the domain.) For example, if the border gateway replaced the IPv4 address 140.173.129.8 with the simple value: 0x00000001, the IPv6 address OUTSIDE the domain would be constructed as: 2002:8CAD:1:1:0000:5EFE:0:1 (NOTE: again, the least significant octet of the EUI-64 interface identifier has the 'u/l' bit set to 0 to indicate that the embedded IPv4 address is NOT globally unique.) The IPv6-in-IPv4 tunneling rules for inter-domain routing would then take the form of those documented in [6TO4]. In other words, the IPv4 source address would be derived from the IPv4 address of the gateway embedded in the 2002:8CAD:1/48 prefix. In this scheme, there may be numerous separate tunnel transitions for an IPv6 message traveling from a source to a destination, including: - intra-domain tunnels from the IPv6 source through gateways along the path to the border gateway for its domain - inter-domain tunnels from the source's border gateway through other transit gateways along the path to a border gateway for the destination - intra-domain tunnels from the destination's border gateway through intra-domain gateways along the path to the destination itself Templin Expires August 2000 [Page 9] Internet Draft IPv6-IPv4 Compatibility Address Format March 2000 3.2.3 Non globally unique IPv4 addresses A domain with private (non globally unique) IPv4 address assignments would require border gateways which implement an inter-domain routing function in the same manner as section 3.2.2. Again, [6TO4] provides a useful solution for this. For example, if the IPv4 address of the border gateway is 140.173.0.1, the IPv4 address of a node within the domain is 10.0.0.1 and the node resides within SLA ID 0x001, the IPv6 address within the domain is constructed as: 2002:8CAD:1:1:0000:5EFE:0A00:1 The administrative authority for such a domain may institute a policy that exposing non-globally unique IPv4 addresses to the public Internet constitutes an acceptable risk, in which case the reverse network address translation described in section 3.2.2 is not necessary. But, the reverse translation could still be enabled for administrators wishing to protect against eavesdropping on the non globally unique addresses. 4. Address selection considerations There will clearly need to be some strategy for communications endpoints when selecting IPv6-IPv4 compatibility addresses instead of native IPv6 addresses. Other works in progress ([6TO4] and [SELECT]) have begun to explore this subject in greater detail. The address selection considerations for this proposal will likely be identical to (or very similar to) those being explored in [6TO4] and [SELECT]. 5. Multicast considerations There may be possible application of the IPv6-IPv4 compatibility address format presented in this draft for multicast addresses. [6TO4] has investigated applicability for multicast addressing in more detail. Multicast considerations for this proposal will likely be identical to (or very similar to) those being explored in [6TO4]. 6. Address autoconfiguration and router discovery considerations Interface identifiers constructed in the methods described in this document can be treated as full-fledged EUI-64 format identifiers with global uniqueness properties, but existing address auto- configuration [AUTO] implementations may not be able to discover these addresses through normal means (e.g. by reading the IEEE 48bit MAC address assigned to a network interace attached to a node). Manual configuration of the EUI-64 identifier should be an option on most implementations, but this would need to be verified on a case-by-case basis. An EUI-64 identifier constructed in the manner of this document should be eligible for constructing aggregatable global IPv6 unicast addresses through normal router discovery [DISC] means. Templin Expires August 2000 [Page 10] Internet Draft IPv6-IPv4 Compatibility Address Format March 2000 7. Relation to other works in progress The IPv6-IPv4 compatibility address format and routing policy decisions presented in this draft evolved from SRI contractual works outside the scope of the NGTRANS working group. Additionally, the mechanisms presented in this draft were developed by the author with no prior knowledge of the activities in NGTRANS. The author recognizes that other works in progress seek to address very similar IPv4-IPv6 transition issues as those targeted by this draft. However, the approach described in this draft presents a number of unique advantages for NGTRANS that are not already covered by other works in progress. (Most specifically, advantages for incremental deployment of IPv6 nodes at the intra-domain level.) 8. Implementation status The author has implemented the mechanisms described in this draft through modifications to the FreeBSD 3.2-RELEASE [FBSD] operating system with the INRIA [INRIA] IPv6 distribution. These modifications implement the routing policy decisions as described in section 3 and enable automatic tunneling for IPv6-IPv4 compatibility addresses constructed as described in section 2. The source code is not yet ready for public distribution, but the author would be happy to discuss details with interested parties. 9. IANA considerations In order support the EUI-64 address form described in this document, we propose that IANA adopt the EUI-64 Interface Identifier format specified in section 2.2 for the existing 00-00-5E OUI owned by IANA. No other actions are required by the IANA. 10. Security considerations Administrative authorities may not wish to expose IPv4 addresses from private domains on the public Internet. Reverse network address translators may be configured as in section 3.2.2 to address this issue. Additional security issues are called out in [6TO4] and probably apply here as well. Acknowledgements The ideas presented here were derived from SRI contractual work in which the author developed these new mechanisms based on principles which emerged through ad-hoc extensions to the FreeBSD 3.2-RELEASE operating system and INRIA IPv6 implementation. The author recognizes that ideas similar to those presented in this document may have already been presented by other authors in NGTRANS (or other forums) and wishes to acknowledge any other such authors. The author also wishes to acknowledge the SRI and government contract administrators who sponsored the projects from which these works derived. Finally the author wishes to specifically acknowledge SRI colleagues with whom he has discussed and reviewed this work, including Dr. Mike Frankel, J. Peter Marcotullio and Dr. Ambatipudi Sastry. References [AGGR] Hinden., R, O'Dell, M., and Deering, S., "An IPv6 Aggregatable Global Unicast Address Format", RFC 2374, July 1998. Templin Expires August 2000 [Page 11] Internet Draft IPv6-IPv4 Compatibility Address Format March 2000 [ADDR] Hinden, R., and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998. [AUTO] Thomson, S., and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. [DISC] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) Registration Authority", http://standards.ieee.org/regauth/oui/tutorials/EUI64.html, March 1997 [IANA] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, USC/Information Sciences Institute, October 1994. [IPV4] Postel, J., "Internet Protocol", RFC 791 [IPV6] Deering, S., and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460 [6TO4] Carpenter, B., and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds without Explicit Tunnels", draft-ietf-ngtrans-6to4-04.txt (work in progress). [MECH] Gilligan, R., and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", draft-ietf-ngtrans-mech-04.txt (work in progress). [SELECT] Draves, R., Default Address Selection for IPv6, draft-ietf- ipngwg-default-addr-select-00.txt (work in progress) [FBSD] http://www.freebsd.org [INRIA] ftp://ftp.inria.fr/network/ipv6/ Authors' Addresses Fred L. Templin SRI International 333 Ravenswood Ave. Menlo Park, CA 94025, USA Email: templin@erg.sri.com Intellectual Property PLACEHOLDER for full IETF IPR Statement if needed. Full Copyright Statement PLACEHOLDER for full ISOC copyright Statement if needed. Templin Expires August 2000 [Page 12]