Network Working Group C. Schild Internet-Draft C. Strauf Expires: May 31, 2004 JOIN (WWU) December 2003 Guide to Mapping IPv4 to IPv6 Subnets draft-schild-v6ops-guide-v4mapping-00.txt 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. This Internet-Draft will expire on May 31, 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document is intended to be a guide for network administrators of enterprise sized sites that employ the Internet Protocol Version 4 (IPv4) and who would like to introduce the Internet Protocol Version 6 (IPv6) dual-stack. It applies to scenarios where IPv4 subnets must be mapped to IPv6 subnets for management purposes while keeping the option to create IPv6 subnets in parallel and independently in the future with almost no restrictions; it is not meant to be applied to scenarios where a native IPv6 address plan can be created easily and without the need to map IPv4 subnets. Schild & Strauf Expires May 31, 2004 [Page 1] Internet-Draft Guide to Mapping IPv4 to IPv6 Subnets December 2003 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Subnet Type Identifier . . . . . . . . . . . . . . . . . . . . 5 4. Dividing the Mapped IPv4 Subnet field: Preparations . . . . . 6 5. Fixed Number of IPv4 Prefixes . . . . . . . . . . . . . . . . 7 5.1 Division of Mapped IPv4 Subnet Field . . . . . . . . . . . . . 7 5.2 Enumerating IPv4 Prefixes . . . . . . . . . . . . . . . . . . 8 5.3 Final Mapping of IPv4 Subnet Bits . . . . . . . . . . . . . . 9 6. Variable Number of IPv4 Prefixes . . . . . . . . . . . . . . . 12 6.1 Division of Mapped IPv4 Subnet Field . . . . . . . . . . . . . 12 6.2 Enumerating IPv4 Prefixes . . . . . . . . . . . . . . . . . . 12 6.3 Final Mapping of IPv4 Subnet Bits . . . . . . . . . . . . . . 13 6.4 Maximal Number of IPv4 Prefixes . . . . . . . . . . . . . . . 13 7. IPv6 Prefixes without Mapped IPv4 Subnet . . . . . . . . . . . 14 8. Drawbacks and Pitfalls . . . . . . . . . . . . . . . . . . . . 15 9. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 16 10. Security Considerations . . . . . . . . . . . . . . . . . . . 17 References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . 19 Schild & Strauf Expires May 31, 2004 [Page 2] Internet-Draft Guide to Mapping IPv4 to IPv6 Subnets December 2003 1. Introduction Planning the migration of an existing Internet Protocol Version 4 (IPv4) enterprise sized site to a site that employs Internet Protocol Version 6 (IPv6) [RFC2460] dual-stack very often includes designing an addressing scheme for IPv6 to reflect the current network's structure under IPv4 as closely as possible. In a number of scenarios this can only be achieved by directly mapping IPv4 subnets to IPv6 subnets. The demands for each site are very different. Therefore, the schemes presented in this document try to match as many scenarios as possible while staying flexible and adaptable enough to fit individual demands. The intention of this document is to act as a guideline for network administrators who need to map existing IPv4 subnets to IPv6 subnets as described above. There are scenarios where this kind of mapping is necessary e.g. for technical or legal reasons (contracts that exist for IPv4 subnets need to be extended to also apply to IPv6 subnets, etc.). However, such a mapping is only recommended if the existing IPv4 address plan is stable enough and well designed. IPv4 networks with an unstable address plan should obviously not be mapped to IPv6 networks because the instability will be inherited by the IPv6 address plan that is to be designed. However, identifying an address plan as being stable or not is up to the network administrator. Addressing this issue is out of scope for this document though it is important to give it careful thought. There are restrictions to the methods that are described in this guideline. One of these restrictions is the number of IPv4 subnets within IPv4 prefixes that can be mapped with the techniques described in this document. The limits for each of these methods are described in their respective paragraphs. It is important that network administrators carefully evaluate if it is indeed necessary to map IPv4 subnets. A native IPv6 address plan that is not restricted by limits that apply to IPv4 address plans (which consequently also apply to the IPv6 address plans that include mapped IPv4 subnets) are always to be favoured. However, if direct mapping of IPv4 subnets is indeed necessary and feasible, the methods presented in this guide are flexible enough to apply to as many scenarios as possible. Schild & Strauf Expires May 31, 2004 [Page 3] Internet-Draft Guide to Mapping IPv4 to IPv6 Subnets December 2003 2. Prerequisites It is assumed that the global IPv6 prefix assigned to the site that an addressing scheme is to be designed for is a /48 prefix. All assumptions in this document also hold for shorter prefixes (e.g. / 32) and should work equally well. For shorter prefixes, this method is even more flexible and deployment is facilitated even more because the number of bits available for mapping increases. Due to the restriction of the IPv6 prefix to a /48 length, the length of IPv4 prefixes with subnets to be mapped must not be shorter than / 16 and they cannot be longer than /30. (Later in this document, some more restrictions will be identified. /16 and /30 are to be read as hard boundaries.) This scheme can be adapted to apply to other prefix lengths as well. For every bit that the IPv6 prefix length is shorter than /48, the IPv4 prefix length may be one bit shorter than /16. For readability purposes, the prefix length assumed in this document is always /48 for IPv6 and longer or equally long as /16 for IPv4 prefixes. Additionally, please refer to [RFC3513] for more information on the IPv6 addressing architecture and on notations that are employed in this document. Schild & Strauf Expires May 31, 2004 [Page 4] Internet-Draft Guide to Mapping IPv4 to IPv6 Subnets December 2003 3. Subnet Type Identifier An identifier bit is needed to denote if an IPv6 subnet reflects a mapped IPv4 subnet or not. This identifier shall be called "Subnet Type Identifier" (STI). If the IPv6 prefix length is /pl, then the identifier bit is the (pl+1)-th bit of the prefix. For a /48 IPv6 prefix, the STI is located at bit 49 (see Figure 1). |prefix|STI|type specific prefix|interface ID| | 48 | 1 | 15 | 64 |bits +------+---+--------------------+------------+ |xxxxxx| 0 |yyyyyyyyyyyyyyyyyyyy|zzzzzzzzzzzz|mapped IPv4 | | | | |subnet +------+---+--------------------+------------+ |xxxxxx| 1 |yyyyyyyyyyyyyyyyyyyy|zzzzzzzzzzzz|regular | | | | |IPv6 subnet +------+---+--------------------+------------+ Figure 1: Location of STI This document will only address the format of the "type specific prefix" for the case that the STI bit has the value "0". It will discuss the options for STI="1" but the detailed discussion of addressing schemes for non-mapped IPv6 prefixes is not within the scope of this document. The "type specific prefix" field for STI="0" will be referred to in this document as "Mapped IPv4 Subnet" field. Note: next to the actual mapping of bits of an IPv4 subnet, the "Mapped IPv4 Subnet" field contains additional information that are necessary to identify mapped IPv4 subnets if they come from more than one IPv4 prefix. It solely contains the bits of an IPv4 subnet if only one IPv4 prefix is involved. Schild & Strauf Expires May 31, 2004 [Page 5] Internet-Draft Guide to Mapping IPv4 to IPv6 Subnets December 2003 4. Dividing the Mapped IPv4 Subnet field: Preparations To hold all necessary information about mapped IPv4 subnets, the Mapped IPv4 Subnet field needs to be divided into two parts: ID field: Identifies the IPv4 prefix that a subnet belongs to. This field is needed to avoid using the complete IPv4 prefix when a subnet needs to be identified. (E.g.: a site has two IPv4 prefix assigned: 212.100.0.0/16 and 210.100.0.0/16. One would need 16 bits to store the prefix that a subnet belongs to. Obviously, this is a waste of bits since a single bit is sufficient for ID-ing the two prefixes ("0" denotes the first prefix, "1" the second).) The ID field has a zero length if only a single IPv4 prefix is involved in the mapping process. IPv4 subnet field: Contains the bits needed to identify a certain subnet. There are two methods for dividing the Mapped IPv4 Subnet field. The choice of method depends on which of the following conditions is met: 1. The number of IPv4 prefixes that contain subnets is fixed and very likely won't change in the near future. (See Section 5.1.) 2. There is a variable number of such IPv4 prefixes. (See Section 6.1.) The decision which method is is to be employed for a certain scenario must not be taken lightly because the choices of division based on these cases have a strong impact on the design of the IPv6 addressing scheme. Schild & Strauf Expires May 31, 2004 [Page 6] Internet-Draft Guide to Mapping IPv4 to IPv6 Subnets December 2003 5. Fixed Number of IPv4 Prefixes 5.1 Division of Mapped IPv4 Subnet Field This type of division is chosen in cases where the number of IPv4 prefixes with subnets that need to be mapped is fixed for a long foreseeable period of time and is not likely to change. In some cases, an additional prefix may be added, depending on the number of spare IDs that are available (see Section 5.2). The division described here has a number of advantages. One is the better ability to create more IPv6 subnets from mapped IPv4 subnets. This provides the network administrator with the freedom to further structure the IPv6 network based on this address assignment scheme if the actual mapping of IPv4 subnets is not needed anymore at some point in the future. To determine the right division of the Mapped IPv4 Subnet field, the following steps have to be taken: 1. M: length of Mapped IPv4 Subnets field in bits. M is calculated as follows: 'M = 64 - (pl + 1)' where pl is the length of the IPv6 prefix available. (E.g.: if a /48 IPv6 prefix is available, M is calculated as 'M = 64 - (48 + 1) = 15'.) 2. Identify the number "p" of all IPv4 prefixes with subnets to be mapped. (E.g.: four Class C IPv4 prefixes contain subnets to be mapped => p=4.) 3. Identify the minimum length "m" of all IPv4 prefixes with subnets to be mapped. (E.g.: IPv4 prefixes with subnets to be mapped have the lengths /20, /16, /24 => m=16.) 4. Calculate the following values: * n: maximum number of bits that can be used to define subnets within an IPv4 prefix. n is calculated as 'n = 30 - m'. (E.g.: of a /16 prefix, 14 bits can be used for subnetting.) * i: number of bits to hold an identifier for each of the IPv4 prefixes. i is calculated as 'i = round_up(log_2(p))'. 5. Verify that "n + i <= M" holds. If this condition is not fulfilled, either the number of IPv4 prefixes with subnets to be mapped must be reduced or the an IPv4 prefix must be excluded (ideally the shortest one). Repeat the above steps until the condition "n + i <= M" is met. Schild & Strauf Expires May 31, 2004 [Page 7] Internet-Draft Guide to Mapping IPv4 to IPv6 Subnets December 2003 All subnets within IPv4 prefixes that are excluded in this process cannot be mapped using the method depicted here. Other means need to be found to map these subnets. Alternatively, a shorter IPv6 prefix may be used if available to still include these IPv4 prefixes. After the completion of the above steps, the Mapped IPv4 Subnet field is divided as follows (an IPv6 prefix length of /48 is assumed again): | Mapped IPv4 Subnet | | 15 |bits +----------------------------+ |yyyyyyyyyyyyyyyyyyyyyyyyyyyy| +----------------------------+ Figure 2: Field before division | Mapped IPv4 Subnet | |ID field| IPv4 subnet | | i | 15-i |bits +--------+-------------------+ |YYYYYYYY|yyyyyyyyyyyyyyyyyyy| +--------+-------------------+ Figure 3: Field after division Note: for a /48 prefix the following condition holds if the above steps have been followed closely: o 15 - i >= n These calculations are important for an efficient design. They also show if the method described in this section is applicable to a given scenario or if other methods of addressing should be used. 5.2 Enumerating IPv4 Prefixes As hinted in Section 4, IPv4 Prefix with Subnets that need to be mapped are identified by ID bits which are stored within the ID field of the Mapped IPv4 Subnets field (see Figure 3). The length of the ID field as calculated in Section 5.1 determines how many different IDs are available for enumerating IPv4 prefixes: 2^i. These IDs are randomly assigned to the IPv4 prefixes in question. Example: four different IPv4 prefixes are given which contain subnets that need to be mapped: o 140.50.0.0/20 Schild & Strauf Expires May 31, 2004 [Page 8] Internet-Draft Guide to Mapping IPv4 to IPv6 Subnets December 2003 o 155.101.0.0/22 o 124.100.0.0/20 o 107.33.0.0/20 The 2^2 IDs can be assigned to these prefixes as follows: | ID | IPv4 prefix | +----+----------------+ | 00 | 140.50.0.0/20 | | 01 | 155.101.0.0/22 | | 10 | 124.100.0.0/20 | | 11 | 107.33.0.0/20 | +----+----------------+ Figure 4: ID/IPv4 Prefix Mapping Table Surplus IDs stay unassigned. They may be used at a later point of time if it is necessary to add another prefix that still fits into the previously divided Mapped IPv4 Subnet field. The Mapping Table must be stored in a save place to be able to identify the IPv4 prefix that a mapped IPv4 subnet belongs to. Obviously, without a mapping table like the one presented in Figure 4 it is not possible to reconstruct the relation IPv4 Prefix / IPv4 Subnet. 5.3 Final Mapping of IPv4 Subnet Bits For each IPv4 prefix that got assigned an ID in Section 5.2, the following steps need to be taken: 1. Depending on the length of the IPv4 prefix, determine the number N of bits that can be used for subnetting (N = 30 - length of prefix). (E.g.: for a /20 IPv4 prefix, that number is N=10.) 2. For this prefix, always use N bits of the IPv4 subnet field in Figure 3, starting from the left. 3. For each subnet do: 1. Extract the N bits from the IPv4 address that define the subnet. 2. Fill these N bits into the IPv4 subnet field (see Figure 3). To better illustrate this method, it is demonstrated by using the Schild & Strauf Expires May 31, 2004 [Page 9] Internet-Draft Guide to Mapping IPv4 to IPv6 Subnets December 2003 following example with these prerequisites: o Four different IPv4 prefixes that contain IPv4 subnets that need to be mapped are given. The IDs of these prefixes are 00, 10, 01, and 11. o The prefix 212.104.176.0/20 is one of the above four prefixes and it contains two defined subnets that need to be mapped: * 212.104.180.0/24 * 212.104.188.0/24 o The prefix 212.104.176.0/20 has the ID 10 assigned. The number N is calculated as 'N = 30 - 20 = 10'. This means that the Mapped IPv4 Subnet field is divided as follows: | Mapped IPv4 Subnet | | ID | IPv4 subnet | | 2 | N | 13-N |bits +----+----------+-----------+ | YY |yyyyyyyyyy|0 ... 0| +----+----------+-----------+ The ID YY is set to the assigned 10. The N bits of the above two subnet IP addresses that need to be taken care of are bits 21-30: | IPv4 subnet | bits 21-30 | | |(N=10 bits total)| +----------------+-----------------+ |212.104.180.0/24| 0100 0000 00 | |212.104.188.0/24| 1100 0000 00 | +----------------+-----------------+ The final mapping of these two subnets to an IPv6 prefix would look like this: | Mapped IPv4 Subnet | | ID | IPv4 subnet | | 2 | N=10 | 13-N=3 |bits +----+----------+--------+ | 10 |0100000000| 000 | | 10 |1100000000| 000 | +----+----------+--------+ This leaves 3 bits in every final IPv6 prefix for creating additional subnets if necessary at some point of time in the future. The last Schild & Strauf Expires May 31, 2004 [Page 10] Internet-Draft Guide to Mapping IPv4 to IPv6 Subnets December 2003 step to complete the mapping is prepending the /48 IPv6 prefix (e.g. 2001:638:500::/49) that is assigned to the site: |IPv6 prefix (hex)|STI| Mapped IPv4 Subnet | | | | ID | IPv4 subnet | | 48 | 1 | 2 | N=10 | 13-N=3 |bits +-----------------+---+----+----------+--------+ | 2001:638:500: | 0 | 10 |0100000000| 000 | | 2001:638:500: | 0 | 10 |1100000000| 000 | +-----------------+---+----+----------+--------+ | V 212.104.180.0/24 --mapped-to--> 2001:638:500:4800::/55 212.104.188.0/24 --mapped-to--> 2001:638:500:5800::/55 Schild & Strauf Expires May 31, 2004 [Page 11] Internet-Draft Guide to Mapping IPv4 to IPv6 Subnets December 2003 6. Variable Number of IPv4 Prefixes 6.1 Division of Mapped IPv4 Subnet Field This method of division should be chosen whenever the number of IPv4 prefixes that contain subnets that need to be mapped cannot be determined a priori and will most likely change in due course. Therefore, a method very similar to [RFC3531] is chosen to map subnets in certain IPv4 prefixes to an IPv6 subnet. The advantage of this method is a gain of flexibility concerning the number of ID'ed IPv4 prefixes but one disadvantage is the fact that a later splitting of IPv6 subnets into more subnets is not possible which may be a drawback in the long term. The division of the Mapped IPv4 Subnet field is done dynamically and in contrast to the method described in Section 5.1, the sizes of the ID field and IPv4 subnet field are not fixed. The only constants for these fields are the position of the leftmost bit of the ID field and the rightmost bit of the IPv4 subnet field. They are already given by the length of the IPv6 prefix that is being used. 6.2 Enumerating IPv4 Prefixes The IDs for prefixes that contain subnets to be mapped are assigned in the following manner (note: the example below shows the assignment for a /48 IPv6 prefix where the Mapped IPv4 Subnet field has a size of 15 bits): | Mapped IPv4 Subnet | | 15 | ++-------------------+ + |0\ ... | | |1| ... | | |01\ ... | | ID bits --->|11| ... | p = # of IPv4 |001\ ... | | prefixes |101| ... | | |011| ... | | |111| ... | | | : | | | : | | +--------------------+ + The above IDs are assigned to each IPv4 prefix top-down. The order in which IPv4 prefixes are assigned an ID may be chosen randomly. If the Mapped IPv4 Subnet field's length is 15, then the number n (maximum number of bits available for mapping an IPv4 subnet) is Schild & Strauf Expires May 31, 2004 [Page 12] Internet-Draft Guide to Mapping IPv4 to IPv6 Subnets December 2003 depending on the number p of IPv4 prefixes that contain IPv4 subnets to be mapped. n is calculated as 'n(p) = 15 - round_up(log_2(p))'. Furthermore, if n bits are needed for storing IPv4 subnet information, the condition 'n + round_up(log(p)) <= 15' must always be fulfilled. Obviously, different IPv4 subnets within the same IPv4 prefix have the same ID. 6.3 Final Mapping of IPv4 Subnet Bits The mapping of the IPv4 subnet bits for a variable number of IPv4 prefixes is almost analogue to the mapping described in Section 5.3. The only major difference is step 2.: the N bits of the IPv4 subnet field are not used starting from the left but instead starting from the right! The rest is analogue. The same example illustrated in Section 5.3 looks like follows for this particular method. The IPv4 prefix described in the example shall be the fourth prefix to be ID'ed. It has the ID 11. |IPv6 prefix (hex)|STI| Mapped IPv4 Subnet | | | | ID | IPv4 subnet | | 48 | 1 | 2 | 13-N=3 | N=10 |bits +-----------------+---+----+--------+----------+ | 2001:638:500: | 0 | 11 | 000 |0100000000| | 2001:638:500: | 0 | 11 | 000 |1100000000| +-----------------+---+----+--------+----------+ | V 212.104.180.0/24 --mapped-to--> 2001:638:500:6100::/58 212.104.188.0/24 --mapped-to--> 2001:638:500:6300::/58 6.4 Maximal Number of IPv4 Prefixes The condition 'n + round_up(log_2(p)) <= 15' in Section 6.2 must hold at all times. If it is violated, the maximal number of IPv4 prefixes with subnets that can be ID'ed and mapped is reached. No more IPv4 prefixes can be included in the addressing scheme. Schild & Strauf Expires May 31, 2004 [Page 13] Internet-Draft Guide to Mapping IPv4 to IPv6 Subnets December 2003 7. IPv6 Prefixes without Mapped IPv4 Subnet It would be unwise -- for obvious reasons -- to address a whole enterprise sized site based only on mapped IPv4 subnets. Doing so would take away the flexibility that is offered by IPv6 addressing and there would be no address space left e.g. for addressing IPv6-only nodes. For this reason, mapped IPv4 subnets are marked with an STI of 0. If the STI is set to 1, the usual IPv6 addressing schemes should be used. There are no restrictions to what kinds of addressing schemes are employed. The only (minor) drawback is the fact that the number of available bits for defining IPv6 subnets are reduced by one (the STI bit). However, this leaves a sufficient number of bits for IPv6 subnets while still providing a satisfying way to map IPv4 structures to the new addressing scheme. For the example prefix 2001:638:500::/48 this would mean that the actual IPv6 prefix that may be used for creating subnets is only reduced to 2001:638:500:8::/49. Schild & Strauf Expires May 31, 2004 [Page 14] Internet-Draft Guide to Mapping IPv4 to IPv6 Subnets December 2003 8. Drawbacks and Pitfalls The mapping of IPv4 subnets has some drawbacks that need to be mentioned. A brief list of issues shall be given here: o For an IPv6 prefix of length /48 (default prefix length for sites), the Mapped IPv4 Subnet field is relatively small with 15 bits. To give the reader and idea of the restrictions that exists, here a short example: * subnets located in a maximum of 2 /16 IPv4 prefixes can only be mapped: 1 bit is consumed by the ID field, 14 bits are needed for mapping subnets within the prefixes * subnets located in a maximum of 32 /20 IPv4 prefixes can be mapped: 5 bits are used for the ID field, 10 bits are needed for mapping subnets * subnets within IPv4 prefixes with a length of /14 or shorter cannot be mapped However, the number of IPv4 prefixes with subnets that can be mapped rises drastically with the lengths of the prefixes. o When using the method for a variable number of IPv6 prefixes described in Section 6, the restriction 'n + round_up(log_2(p)) <= 15' (for a /48 IPv6 prefix and analogue for prefixes of other lengths) mentioned in Section 6.4 must not be violated. Observing this restriction is essential and network administrators must be aware of it at all times. o The mapping information like in Figure 4 needs to be stored so that a reverse mapping is possible. It is difficult, if not impossible to restore this information if it is lost. Schild & Strauf Expires May 31, 2004 [Page 15] Internet-Draft Guide to Mapping IPv4 to IPv6 Subnets December 2003 9. Conclusion While IPv6 offers a very flexible and versatile way of addressing an enterprise site, especially for transition scenarios a desire to include existing IPv4 structures of a site in the IPv6 addressing scheme can often be observed. The methods described in this document pay tribute to this desire as systematically as possible while leaving enough room for the new addressing methods that IPv6 offers. The methods have a few drawbacks and pitfalls that need to be taken into account. However, the gain through using these methods is considerable so that drawbacks and pitfalls are outweighed by the advantages. Schild & Strauf Expires May 31, 2004 [Page 16] Internet-Draft Guide to Mapping IPv4 to IPv6 Subnets December 2003 10. Security Considerations The mapping of IPv4 subnets to IPv6 subnets does not yield security considerations. Schild & Strauf Expires May 31, 2004 [Page 17] Internet-Draft Guide to Mapping IPv4 to IPv6 Subnets December 2003 References [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003. [RFC3531] Blanchet, M., "A Flexible Method for Managing the Assignment of Bits of an IPv6 Address Block", RFC 3531, April 2003. Authors' Addresses Christian Schild JOIN (University of Muenster) Roentgenstr. 9-13 Muenster D-48149 DE EMail: schild@uni-muenster.de URI: http://www.join.uni-muenster.de Christian Strauf JOIN (University of Muenster) Roentgenstr. 9-13 Muenster D-48149 DE EMail: strauf@uni-muenster.de URI: http://www.join.uni-muenster.de Schild & Strauf Expires May 31, 2004 [Page 18] Internet-Draft Guide to Mapping IPv4 to IPv6 Subnets December 2003 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Schild & Strauf Expires May 31, 2004 [Page 19] Internet-Draft Guide to Mapping IPv4 to IPv6 Subnets December 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Schild & Strauf Expires May 31, 2004 [Page 20]