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]