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]