draft-ietf-behave-address-format-06.txt   draft-ietf-behave-address-format-07.txt 
Network Working Group C. Bao Network Working Group C. Bao
Internet-Draft CERNET Center/Tsinghua University Internet-Draft CERNET Center/Tsinghua University
Obsoletes: 2765 (if approved) C. Huitema Obsoletes: 2765 (if approved) C. Huitema
Updates: 4291 (if approved) Microsoft Corporation Updates: 4291 (if approved) Microsoft Corporation
Intended status: Standards Track M. Bagnulo Intended status: Standards Track M. Bagnulo
Expires: September 28, 2010 UC3M Expires: October 11, 2010 UC3M
M. Boucadair M. Boucadair
France Telecom France Telecom
X. Li X. Li
CERNET Center/Tsinghua University CERNET Center/Tsinghua University
March 27, 2010 April 9, 2010
IPv6 Addressing of IPv4/IPv6 Translators IPv6 Addressing of IPv4/IPv6 Translators
draft-ietf-behave-address-format-06.txt draft-ietf-behave-address-format-07.txt
Abstract Abstract
This document discusses the algorithmic translation of an IPv6 This document discusses the algorithmic translation of an IPv6
address to a corresponding IPv4 address, and vice versa, using only address to a corresponding IPv4 address, and vice versa, using only
statically configured information. It defines a well-known prefix statically configured information. It defines a well-known prefix
for use in algorithmic translations, while allowing organizations to for use in algorithmic translations, while allowing organizations to
also use network-specific prefixes when appropriate. Algorithmic also use network-specific prefixes when appropriate. Algorithmic
translation is used in IPv4/IPv6 translators, as well as other types translation is used in IPv4/IPv6 translators, as well as other types
of proxies and gateways (e.g., for DNS) used in IPv4/IPv6 scenarios. of proxies and gateways (e.g., for DNS) used in IPv4/IPv6 scenarios.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on October 11, 2010.
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 September 28, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Applicability Scope . . . . . . . . . . . . . . . . . . . 3 1.1. Applicability Scope . . . . . . . . . . . . . . . . . . . 3
1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. IPv4-Embedded IPv6 Address Prefix and Format . . . . . . . . . 4 2. IPv4-Embedded IPv6 Address Prefix and Format . . . . . . . . . 4
2.1. Well Known Prefix . . . . . . . . . . . . . . . . . . . . 4 2.1. Well Known Prefix . . . . . . . . . . . . . . . . . . . . 4
2.2. IPv4-Embedded IPv6 Address Format . . . . . . . . . . . . 4 2.2. IPv4-Embedded IPv6 Address Format . . . . . . . . . . . . 4
skipping to change at page 14, line 9 skipping to change at page 14, line 9
appear as IPv4 packets from the specified source, and the attacker appear as IPv4 packets from the specified source, and the attacker
may be hard to track. If left without mitigation, the attack would may be hard to track. If left without mitigation, the attack would
allow malicious IPv6 nodes to spoof arbitrary IPv4 addresses. allow malicious IPv6 nodes to spoof arbitrary IPv4 addresses.
The mitigation is to implement reverse path checks, and to verify The mitigation is to implement reverse path checks, and to verify
throughout the network that packets are coming from an authorized throughout the network that packets are coming from an authorized
location. location.
4.2. Secure Configuration 4.2. Secure Configuration
The prefixes and formats need to be the configured consistently among The prefixes used for address translation are used by IPv6 nodes to
multiple devices in the same network (e.g., nodes that need to prefer send packets to IPv6/IPv4 translators. Attackers could attempt to
native over translated addresses, DNS gateways, and IPv4/IPv6 fool nodes, DNS gateways, and IPv4/IPv6 translators into using wrong
translators). As such, the means by which they are learned/ values for these parameters, resulting in network disruption, denial
configured MUST be secure. Specifying a default prefix and/or format of service, and possible information disclosure. To mitigate such
in implementations provides one way to configure them securely. Any attacks, network administrators need to ensure that prefixes are
alternative means of configuration is responsible for specifying how configured in a secure way.
to do so securely.
The mechanisms for achieving secure configuration of prefixes are
beyond the scope of this document.
5. IANA Considerations 5. IANA Considerations
The IANA is requested to add a note to the documentation of the The IANA is requested to add a note to the documentation of the
0000::/8 address block in 0000::/8 address block in
http://www.iana.org/assignments/ipv6-address-space to document the http://www.iana.org/assignments/ipv6-address-space to document the
assignment by the IETF of the Well Known Prefix. For example: assignment by the IETF of the Well Known Prefix. For example:
The "Well Known Prefix" 64:FF9B::/96 used in an algorithmic The "Well Known Prefix" 64:FF9B::/96 used in an algorithmic
mapping between IPv4 to IPv6 addresses is defined out of the mapping between IPv4 to IPv6 addresses is defined out of the
 End of changes. 8 change blocks. 
23 lines changed or deleted 19 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/