idnits 2.17.1 draft-schild-v6ops-guide-v4mapping-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 17 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 4 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 2003) is 7431 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3513 (Obsoleted by RFC 4291) ** Downref: Normative reference to an Informational RFC: RFC 3531 Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group C. Schild 2 Internet-Draft C. Strauf 3 Expires: May 31, 2004 JOIN (WWU) 4 December 2003 6 Guide to Mapping IPv4 to IPv6 Subnets 7 draft-schild-v6ops-guide-v4mapping-00.txt 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at http:// 24 www.ietf.org/ietf/1id-abstracts.txt. 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 This Internet-Draft will expire on May 31, 2004. 31 Copyright Notice 33 Copyright (C) The Internet Society (2003). All Rights Reserved. 35 Abstract 37 This document is intended to be a guide for network administrators of 38 enterprise sized sites that employ the Internet Protocol Version 4 39 (IPv4) and who would like to introduce the Internet Protocol Version 40 6 (IPv6) dual-stack. It applies to scenarios where IPv4 subnets must 41 be mapped to IPv6 subnets for management purposes while keeping the 42 option to create IPv6 subnets in parallel and independently in the 43 future with almost no restrictions; it is not meant to be applied to 44 scenarios where a native IPv6 address plan can be created easily and 45 without the need to map IPv4 subnets. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . 4 51 3. Subnet Type Identifier . . . . . . . . . . . . . . . . . . . . 5 52 4. Dividing the Mapped IPv4 Subnet field: Preparations . . . . . 6 53 5. Fixed Number of IPv4 Prefixes . . . . . . . . . . . . . . . . 7 54 5.1 Division of Mapped IPv4 Subnet Field . . . . . . . . . . . . . 7 55 5.2 Enumerating IPv4 Prefixes . . . . . . . . . . . . . . . . . . 8 56 5.3 Final Mapping of IPv4 Subnet Bits . . . . . . . . . . . . . . 9 57 6. Variable Number of IPv4 Prefixes . . . . . . . . . . . . . . . 12 58 6.1 Division of Mapped IPv4 Subnet Field . . . . . . . . . . . . . 12 59 6.2 Enumerating IPv4 Prefixes . . . . . . . . . . . . . . . . . . 12 60 6.3 Final Mapping of IPv4 Subnet Bits . . . . . . . . . . . . . . 13 61 6.4 Maximal Number of IPv4 Prefixes . . . . . . . . . . . . . . . 13 62 7. IPv6 Prefixes without Mapped IPv4 Subnet . . . . . . . . . . . 14 63 8. Drawbacks and Pitfalls . . . . . . . . . . . . . . . . . . . . 15 64 9. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 16 65 10. Security Considerations . . . . . . . . . . . . . . . . . . . 17 66 References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18 68 Intellectual Property and Copyright Statements . . . . . . . . 19 70 1. Introduction 72 Planning the migration of an existing Internet Protocol Version 4 73 (IPv4) enterprise sized site to a site that employs Internet Protocol 74 Version 6 (IPv6) [RFC2460] dual-stack very often includes designing 75 an addressing scheme for IPv6 to reflect the current network's 76 structure under IPv4 as closely as possible. In a number of scenarios 77 this can only be achieved by directly mapping IPv4 subnets to IPv6 78 subnets. The demands for each site are very different. Therefore, the 79 schemes presented in this document try to match as many scenarios as 80 possible while staying flexible and adaptable enough to fit 81 individual demands. 83 The intention of this document is to act as a guideline for network 84 administrators who need to map existing IPv4 subnets to IPv6 subnets 85 as described above. There are scenarios where this kind of mapping is 86 necessary e.g. for technical or legal reasons (contracts that exist 87 for IPv4 subnets need to be extended to also apply to IPv6 subnets, 88 etc.). However, such a mapping is only recommended if the existing 89 IPv4 address plan is stable enough and well designed. IPv4 networks 90 with an unstable address plan should obviously not be mapped to IPv6 91 networks because the instability will be inherited by the IPv6 92 address plan that is to be designed. However, identifying an address 93 plan as being stable or not is up to the network administrator. 94 Addressing this issue is out of scope for this document though it is 95 important to give it careful thought. 97 There are restrictions to the methods that are described in this 98 guideline. One of these restrictions is the number of IPv4 subnets 99 within IPv4 prefixes that can be mapped with the techniques described 100 in this document. The limits for each of these methods are described 101 in their respective paragraphs. 103 It is important that network administrators carefully evaluate if it 104 is indeed necessary to map IPv4 subnets. A native IPv6 address plan 105 that is not restricted by limits that apply to IPv4 address plans 106 (which consequently also apply to the IPv6 address plans that include 107 mapped IPv4 subnets) are always to be favoured. However, if direct 108 mapping of IPv4 subnets is indeed necessary and feasible, the methods 109 presented in this guide are flexible enough to apply to as many 110 scenarios as possible. 112 2. Prerequisites 114 It is assumed that the global IPv6 prefix assigned to the site that 115 an addressing scheme is to be designed for is a /48 prefix. All 116 assumptions in this document also hold for shorter prefixes (e.g. / 117 32) and should work equally well. For shorter prefixes, this method 118 is even more flexible and deployment is facilitated even more because 119 the number of bits available for mapping increases. 121 Due to the restriction of the IPv6 prefix to a /48 length, the length 122 of IPv4 prefixes with subnets to be mapped must not be shorter than / 123 16 and they cannot be longer than /30. (Later in this document, some 124 more restrictions will be identified. /16 and /30 are to be read as 125 hard boundaries.) This scheme can be adapted to apply to other prefix 126 lengths as well. For every bit that the IPv6 prefix length is shorter 127 than /48, the IPv4 prefix length may be one bit shorter than /16. For 128 readability purposes, the prefix length assumed in this document is 129 always /48 for IPv6 and longer or equally long as /16 for IPv4 130 prefixes. Additionally, please refer to [RFC3513] for more 131 information on the IPv6 addressing architecture and on notations that 132 are employed in this document. 134 3. Subnet Type Identifier 136 An identifier bit is needed to denote if an IPv6 subnet reflects a 137 mapped IPv4 subnet or not. This identifier shall be called "Subnet 138 Type Identifier" (STI). If the IPv6 prefix length is /pl, then the 139 identifier bit is the (pl+1)-th bit of the prefix. For a /48 IPv6 140 prefix, the STI is located at bit 49 (see Figure 1). 142 |prefix|STI|type specific prefix|interface ID| 143 | 48 | 1 | 15 | 64 |bits 144 +------+---+--------------------+------------+ 145 |xxxxxx| 0 |yyyyyyyyyyyyyyyyyyyy|zzzzzzzzzzzz|mapped IPv4 146 | | | | |subnet 147 +------+---+--------------------+------------+ 148 |xxxxxx| 1 |yyyyyyyyyyyyyyyyyyyy|zzzzzzzzzzzz|regular 149 | | | | |IPv6 subnet 150 +------+---+--------------------+------------+ 152 Figure 1: Location of STI 154 This document will only address the format of the "type specific 155 prefix" for the case that the STI bit has the value "0". It will 156 discuss the options for STI="1" but the detailed discussion of 157 addressing schemes for non-mapped IPv6 prefixes is not within the 158 scope of this document. 160 The "type specific prefix" field for STI="0" will be referred to in 161 this document as "Mapped IPv4 Subnet" field. Note: next to the actual 162 mapping of bits of an IPv4 subnet, the "Mapped IPv4 Subnet" field 163 contains additional information that are necessary to identify mapped 164 IPv4 subnets if they come from more than one IPv4 prefix. It solely 165 contains the bits of an IPv4 subnet if only one IPv4 prefix is 166 involved. 168 4. Dividing the Mapped IPv4 Subnet field: Preparations 170 To hold all necessary information about mapped IPv4 subnets, the 171 Mapped IPv4 Subnet field needs to be divided into two parts: 173 ID field: Identifies the IPv4 prefix that a subnet belongs to. This 174 field is needed to avoid using the complete IPv4 prefix when a 175 subnet needs to be identified. (E.g.: a site has two IPv4 prefix 176 assigned: 212.100.0.0/16 and 210.100.0.0/16. One would need 16 177 bits to store the prefix that a subnet belongs to. Obviously, this 178 is a waste of bits since a single bit is sufficient for ID-ing the 179 two prefixes ("0" denotes the first prefix, "1" the second).) The 180 ID field has a zero length if only a single IPv4 prefix is 181 involved in the mapping process. 183 IPv4 subnet field: Contains the bits needed to identify a certain 184 subnet. 186 There are two methods for dividing the Mapped IPv4 Subnet field. The 187 choice of method depends on which of the following conditions is met: 189 1. The number of IPv4 prefixes that contain subnets is fixed and 190 very likely won't change in the near future. (See Section 5.1.) 192 2. There is a variable number of such IPv4 prefixes. (See Section 193 6.1.) 195 The decision which method is is to be employed for a certain scenario 196 must not be taken lightly because the choices of division based on 197 these cases have a strong impact on the design of the IPv6 addressing 198 scheme. 200 5. Fixed Number of IPv4 Prefixes 202 5.1 Division of Mapped IPv4 Subnet Field 204 This type of division is chosen in cases where the number of IPv4 205 prefixes with subnets that need to be mapped is fixed for a long 206 foreseeable period of time and is not likely to change. In some 207 cases, an additional prefix may be added, depending on the number of 208 spare IDs that are available (see Section 5.2). 210 The division described here has a number of advantages. One is the 211 better ability to create more IPv6 subnets from mapped IPv4 subnets. 212 This provides the network administrator with the freedom to further 213 structure the IPv6 network based on this address assignment scheme if 214 the actual mapping of IPv4 subnets is not needed anymore at some 215 point in the future. 217 To determine the right division of the Mapped IPv4 Subnet field, the 218 following steps have to be taken: 220 1. M: length of Mapped IPv4 Subnets field in bits. M is calculated 221 as follows: 'M = 64 - (pl + 1)' where pl is the length of the 222 IPv6 prefix available. (E.g.: if a /48 IPv6 prefix is available, 223 M is calculated as 'M = 64 - (48 + 1) = 15'.) 225 2. Identify the number "p" of all IPv4 prefixes with subnets to be 226 mapped. (E.g.: four Class C IPv4 prefixes contain subnets to be 227 mapped => p=4.) 229 3. Identify the minimum length "m" of all IPv4 prefixes with subnets 230 to be mapped. (E.g.: IPv4 prefixes with subnets to be mapped have 231 the lengths /20, /16, /24 => m=16.) 233 4. Calculate the following values: 235 * n: maximum number of bits that can be used to define subnets 236 within an IPv4 prefix. n is calculated as 'n = 30 - m'. (E.g.: 237 of a /16 prefix, 14 bits can be used for subnetting.) 239 * i: number of bits to hold an identifier for each of the IPv4 240 prefixes. i is calculated as 'i = round_up(log_2(p))'. 242 5. Verify that "n + i <= M" holds. If this condition is not 243 fulfilled, either the number of IPv4 prefixes with subnets to be 244 mapped must be reduced or the an IPv4 prefix must be excluded 245 (ideally the shortest one). Repeat the above steps until the 246 condition "n + i <= M" is met. 248 All subnets within IPv4 prefixes that are excluded in this process 249 cannot be mapped using the method depicted here. Other means need to 250 be found to map these subnets. Alternatively, a shorter IPv6 prefix 251 may be used if available to still include these IPv4 prefixes. 253 After the completion of the above steps, the Mapped IPv4 Subnet field 254 is divided as follows (an IPv6 prefix length of /48 is assumed 255 again): 257 | Mapped IPv4 Subnet | 258 | 15 |bits 259 +----------------------------+ 260 |yyyyyyyyyyyyyyyyyyyyyyyyyyyy| 261 +----------------------------+ 263 Figure 2: Field before division 265 | Mapped IPv4 Subnet | 266 |ID field| IPv4 subnet | 267 | i | 15-i |bits 268 +--------+-------------------+ 269 |YYYYYYYY|yyyyyyyyyyyyyyyyyyy| 270 +--------+-------------------+ 272 Figure 3: Field after division 274 Note: for a /48 prefix the following condition holds if the above 275 steps have been followed closely: 277 o 15 - i >= n 279 These calculations are important for an efficient design. They also 280 show if the method described in this section is applicable to a given 281 scenario or if other methods of addressing should be used. 283 5.2 Enumerating IPv4 Prefixes 285 As hinted in Section 4, IPv4 Prefix with Subnets that need to be 286 mapped are identified by ID bits which are stored within the ID field 287 of the Mapped IPv4 Subnets field (see Figure 3). The length of the ID 288 field as calculated in Section 5.1 determines how many different IDs 289 are available for enumerating IPv4 prefixes: 2^i. These IDs are 290 randomly assigned to the IPv4 prefixes in question. Example: four 291 different IPv4 prefixes are given which contain subnets that need to 292 be mapped: 294 o 140.50.0.0/20 295 o 155.101.0.0/22 297 o 124.100.0.0/20 299 o 107.33.0.0/20 301 The 2^2 IDs can be assigned to these prefixes as follows: 303 | ID | IPv4 prefix | 304 +----+----------------+ 305 | 00 | 140.50.0.0/20 | 306 | 01 | 155.101.0.0/22 | 307 | 10 | 124.100.0.0/20 | 308 | 11 | 107.33.0.0/20 | 309 +----+----------------+ 311 Figure 4: ID/IPv4 Prefix Mapping Table 313 Surplus IDs stay unassigned. They may be used at a later point of 314 time if it is necessary to add another prefix that still fits into 315 the previously divided Mapped IPv4 Subnet field. 317 The Mapping Table must be stored in a save place to be able to 318 identify the IPv4 prefix that a mapped IPv4 subnet belongs to. 319 Obviously, without a mapping table like the one presented in Figure 4 320 it is not possible to reconstruct the relation IPv4 Prefix / IPv4 321 Subnet. 323 5.3 Final Mapping of IPv4 Subnet Bits 325 For each IPv4 prefix that got assigned an ID in Section 5.2, the 326 following steps need to be taken: 328 1. Depending on the length of the IPv4 prefix, determine the number 329 N of bits that can be used for subnetting (N = 30 - length of 330 prefix). (E.g.: for a /20 IPv4 prefix, that number is N=10.) 332 2. For this prefix, always use N bits of the IPv4 subnet field in 333 Figure 3, starting from the left. 335 3. For each subnet do: 337 1. Extract the N bits from the IPv4 address that define the 338 subnet. 340 2. Fill these N bits into the IPv4 subnet field (see Figure 3). 342 To better illustrate this method, it is demonstrated by using the 343 following example with these prerequisites: 345 o Four different IPv4 prefixes that contain IPv4 subnets that need 346 to be mapped are given. The IDs of these prefixes are 00, 10, 01, 347 and 11. 349 o The prefix 212.104.176.0/20 is one of the above four prefixes and 350 it contains two defined subnets that need to be mapped: 352 * 212.104.180.0/24 354 * 212.104.188.0/24 356 o The prefix 212.104.176.0/20 has the ID 10 assigned. 358 The number N is calculated as 'N = 30 - 20 = 10'. This means that the 359 Mapped IPv4 Subnet field is divided as follows: 361 | Mapped IPv4 Subnet | 362 | ID | IPv4 subnet | 363 | 2 | N | 13-N |bits 364 +----+----------+-----------+ 365 | YY |yyyyyyyyyy|0 ... 0| 366 +----+----------+-----------+ 368 The ID YY is set to the assigned 10. The N bits of the above two 369 subnet IP addresses that need to be taken care of are bits 21-30: 371 | IPv4 subnet | bits 21-30 | 372 | |(N=10 bits total)| 373 +----------------+-----------------+ 374 |212.104.180.0/24| 0100 0000 00 | 375 |212.104.188.0/24| 1100 0000 00 | 376 +----------------+-----------------+ 378 The final mapping of these two subnets to an IPv6 prefix would look 379 like this: 381 | Mapped IPv4 Subnet | 382 | ID | IPv4 subnet | 383 | 2 | N=10 | 13-N=3 |bits 384 +----+----------+--------+ 385 | 10 |0100000000| 000 | 386 | 10 |1100000000| 000 | 387 +----+----------+--------+ 389 This leaves 3 bits in every final IPv6 prefix for creating additional 390 subnets if necessary at some point of time in the future. The last 391 step to complete the mapping is prepending the /48 IPv6 prefix (e.g. 392 2001:638:500::/49) that is assigned to the site: 394 |IPv6 prefix (hex)|STI| Mapped IPv4 Subnet | 395 | | | ID | IPv4 subnet | 396 | 48 | 1 | 2 | N=10 | 13-N=3 |bits 397 +-----------------+---+----+----------+--------+ 398 | 2001:638:500: | 0 | 10 |0100000000| 000 | 399 | 2001:638:500: | 0 | 10 |1100000000| 000 | 400 +-----------------+---+----+----------+--------+ 402 | 403 V 405 212.104.180.0/24 --mapped-to--> 2001:638:500:4800::/55 406 212.104.188.0/24 --mapped-to--> 2001:638:500:5800::/55 408 6. Variable Number of IPv4 Prefixes 410 6.1 Division of Mapped IPv4 Subnet Field 412 This method of division should be chosen whenever the number of IPv4 413 prefixes that contain subnets that need to be mapped cannot be 414 determined a priori and will most likely change in due course. 415 Therefore, a method very similar to [RFC3531] is chosen to map 416 subnets in certain IPv4 prefixes to an IPv6 subnet. The advantage of 417 this method is a gain of flexibility concerning the number of ID'ed 418 IPv4 prefixes but one disadvantage is the fact that a later splitting 419 of IPv6 subnets into more subnets is not possible which may be a 420 drawback in the long term. 422 The division of the Mapped IPv4 Subnet field is done dynamically and 423 in contrast to the method described in Section 5.1, the sizes of the 424 ID field and IPv4 subnet field are not fixed. The only constants for 425 these fields are the position of the leftmost bit of the ID field and 426 the rightmost bit of the IPv4 subnet field. They are already given by 427 the length of the IPv6 prefix that is being used. 429 6.2 Enumerating IPv4 Prefixes 431 The IDs for prefixes that contain subnets to be mapped are assigned 432 in the following manner (note: the example below shows the assignment 433 for a /48 IPv6 prefix where the Mapped IPv4 Subnet field has a size 434 of 15 bits): 436 | Mapped IPv4 Subnet | 437 | 15 | 438 ++-------------------+ + 439 |0\ ... | | 440 |1| ... | | 441 |01\ ... | | 442 ID bits --->|11| ... | p = # of IPv4 443 |001\ ... | | prefixes 444 |101| ... | | 445 |011| ... | | 446 |111| ... | | 447 | : | | 448 | : | | 449 +--------------------+ + 451 The above IDs are assigned to each IPv4 prefix top-down. The order in 452 which IPv4 prefixes are assigned an ID may be chosen randomly. 454 If the Mapped IPv4 Subnet field's length is 15, then the number n 455 (maximum number of bits available for mapping an IPv4 subnet) is 456 depending on the number p of IPv4 prefixes that contain IPv4 subnets 457 to be mapped. n is calculated as 'n(p) = 15 - round_up(log_2(p))'. 458 Furthermore, if n bits are needed for storing IPv4 subnet 459 information, the condition 'n + round_up(log(p)) <= 15' must always 460 be fulfilled. 462 Obviously, different IPv4 subnets within the same IPv4 prefix have 463 the same ID. 465 6.3 Final Mapping of IPv4 Subnet Bits 467 The mapping of the IPv4 subnet bits for a variable number of IPv4 468 prefixes is almost analogue to the mapping described in Section 5.3. 469 The only major difference is step 2.: the N bits of the IPv4 subnet 470 field are not used starting from the left but instead starting from 471 the right! The rest is analogue. 473 The same example illustrated in Section 5.3 looks like follows for 474 this particular method. The IPv4 prefix described in the example 475 shall be the fourth prefix to be ID'ed. It has the ID 11. 477 |IPv6 prefix (hex)|STI| Mapped IPv4 Subnet | 478 | | | ID | IPv4 subnet | 479 | 48 | 1 | 2 | 13-N=3 | N=10 |bits 480 +-----------------+---+----+--------+----------+ 481 | 2001:638:500: | 0 | 11 | 000 |0100000000| 482 | 2001:638:500: | 0 | 11 | 000 |1100000000| 483 +-----------------+---+----+--------+----------+ 485 | 486 V 488 212.104.180.0/24 --mapped-to--> 2001:638:500:6100::/58 489 212.104.188.0/24 --mapped-to--> 2001:638:500:6300::/58 491 6.4 Maximal Number of IPv4 Prefixes 493 The condition 'n + round_up(log_2(p)) <= 15' in Section 6.2 must hold 494 at all times. If it is violated, the maximal number of IPv4 prefixes 495 with subnets that can be ID'ed and mapped is reached. No more IPv4 496 prefixes can be included in the addressing scheme. 498 7. IPv6 Prefixes without Mapped IPv4 Subnet 500 It would be unwise -- for obvious reasons -- to address a whole 501 enterprise sized site based only on mapped IPv4 subnets. Doing so 502 would take away the flexibility that is offered by IPv6 addressing 503 and there would be no address space left e.g. for addressing 504 IPv6-only nodes. For this reason, mapped IPv4 subnets are marked with 505 an STI of 0. If the STI is set to 1, the usual IPv6 addressing 506 schemes should be used. There are no restrictions to what kinds of 507 addressing schemes are employed. The only (minor) drawback is the 508 fact that the number of available bits for defining IPv6 subnets are 509 reduced by one (the STI bit). However, this leaves a sufficient 510 number of bits for IPv6 subnets while still providing a satisfying 511 way to map IPv4 structures to the new addressing scheme. 513 For the example prefix 2001:638:500::/48 this would mean that the 514 actual IPv6 prefix that may be used for creating subnets is only 515 reduced to 2001:638:500:8::/49. 517 8. Drawbacks and Pitfalls 519 The mapping of IPv4 subnets has some drawbacks that need to be 520 mentioned. A brief list of issues shall be given here: 522 o For an IPv6 prefix of length /48 (default prefix length for 523 sites), the Mapped IPv4 Subnet field is relatively small with 15 524 bits. To give the reader and idea of the restrictions that exists, 525 here a short example: 527 * subnets located in a maximum of 2 /16 IPv4 prefixes can only be 528 mapped: 1 bit is consumed by the ID field, 14 bits are needed 529 for mapping subnets within the prefixes 531 * subnets located in a maximum of 32 /20 IPv4 prefixes can be 532 mapped: 5 bits are used for the ID field, 10 bits are needed 533 for mapping subnets 535 * subnets within IPv4 prefixes with a length of /14 or shorter 536 cannot be mapped 538 However, the number of IPv4 prefixes with subnets that can be 539 mapped rises drastically with the lengths of the prefixes. 541 o When using the method for a variable number of IPv6 prefixes 542 described in Section 6, the restriction 'n + round_up(log_2(p)) <= 543 15' (for a /48 IPv6 prefix and analogue for prefixes of other 544 lengths) mentioned in Section 6.4 must not be violated. Observing 545 this restriction is essential and network administrators must be 546 aware of it at all times. 548 o The mapping information like in Figure 4 needs to be stored so 549 that a reverse mapping is possible. It is difficult, if not 550 impossible to restore this information if it is lost. 552 9. Conclusion 554 While IPv6 offers a very flexible and versatile way of addressing an 555 enterprise site, especially for transition scenarios a desire to 556 include existing IPv4 structures of a site in the IPv6 addressing 557 scheme can often be observed. The methods described in this document 558 pay tribute to this desire as systematically as possible while 559 leaving enough room for the new addressing methods that IPv6 offers. 561 The methods have a few drawbacks and pitfalls that need to be taken 562 into account. However, the gain through using these methods is 563 considerable so that drawbacks and pitfalls are outweighed by the 564 advantages. 566 10. Security Considerations 568 The mapping of IPv4 subnets to IPv6 subnets does not yield security 569 considerations. 571 References 573 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 574 (IPv6) Specification", RFC 2460, December 1998. 576 [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 577 (IPv6) Addressing Architecture", RFC 3513, April 2003. 579 [RFC3531] Blanchet, M., "A Flexible Method for Managing the 580 Assignment of Bits of an IPv6 Address Block", RFC 3531, 581 April 2003. 583 Authors' Addresses 585 Christian Schild 586 JOIN (University of Muenster) 587 Roentgenstr. 9-13 588 Muenster D-48149 589 DE 591 EMail: schild@uni-muenster.de 592 URI: http://www.join.uni-muenster.de 594 Christian Strauf 595 JOIN (University of Muenster) 596 Roentgenstr. 9-13 597 Muenster D-48149 598 DE 600 EMail: strauf@uni-muenster.de 601 URI: http://www.join.uni-muenster.de 603 Intellectual Property Statement 605 The IETF takes no position regarding the validity or scope of any 606 intellectual property or other rights that might be claimed to 607 pertain to the implementation or use of the technology described in 608 this document or the extent to which any license under such rights 609 might or might not be available; neither does it represent that it 610 has made any effort to identify any such rights. Information on the 611 IETF's procedures with respect to rights in standards-track and 612 standards-related documentation can be found in BCP-11. Copies of 613 claims of rights made available for publication and any assurances of 614 licenses to be made available, or the result of an attempt made to 615 obtain a general license or permission for the use of such 616 proprietary rights by implementors or users of this specification can 617 be obtained from the IETF Secretariat. 619 The IETF invites any interested party to bring to its attention any 620 copyrights, patents or patent applications, or other proprietary 621 rights which may cover technology that may be required to practice 622 this standard. Please address the information to the IETF Executive 623 Director. 625 Full Copyright Statement 627 Copyright (C) The Internet Society (2003). All Rights Reserved. 629 This document and translations of it may be copied and furnished to 630 others, and derivative works that comment on or otherwise explain it 631 or assist in its implementation may be prepared, copied, published 632 and distributed, in whole or in part, without restriction of any 633 kind, provided that the above copyright notice and this paragraph are 634 included on all such copies and derivative works. However, this 635 document itself may not be modified in any way, such as by removing 636 the copyright notice or references to the Internet Society or other 637 Internet organizations, except as needed for the purpose of 638 developing Internet standards in which case the procedures for 639 copyrights defined in the Internet Standards process must be 640 followed, or as required to translate it into languages other than 641 English. 643 The limited permissions granted above are perpetual and will not be 644 revoked by the Internet Society or its successors or assignees. 646 This document and the information contained herein is provided on an 647 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 648 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 649 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 650 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 651 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 653 Acknowledgment 655 Funding for the RFC Editor function is currently provided by the 656 Internet Society.