Behavior Engineering for Hindrance R. Denis-Courmont
Avoidance Nokia
Internet-Draft October 17, 2008
Intended status: Experimental
Expires: April 20, 2009
IPv6 destination header option for IPv4 translator mapping notification
draft-denis-behave-v4v6exthdr-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 April 20, 2009.
Denis-Courmont Expires April 20, 2009 [Page 1]
Internet-Draft IPv6v4 mapping option October 2008
Abstract
This memo defines a new IPv6 Destination header option to convey the
transport mapping information from an IPv4-IPv4 protocol translator
to the IPv6 end of a protocol-translated packet flow.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. IPv4-IPv6 Translation . . . . . . . . . . . . . . . . . . . . 5
3.1. Inserting the flow mapping option . . . . . . . . . . . . 5
3.1.1. Usage with connection-oriented protocols . . . . . . . 5
3.2. Receiving the flow mapping option . . . . . . . . . . . . 6
4. Option format . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
Appendix A. API Considerations . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. Normative References . . . . . . . . . . . . . . . . . . . 11
7.2. Informative References . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . . . 13
Denis-Courmont Expires April 20, 2009 [Page 2]
Internet-Draft IPv6v4 mapping option October 2008
1. Introduction
To overcome the shortage of IPv4 addresses within the Internet,
Network Address and Port Translators (NATs) have been widely
deployed, such that multiple IPv4 nodes can share a single IPv4
address. However, that method is known to break certain application
protocols, which need to know their own assigned external IP address
and/or port number (i.e. the transport address). New solutions are
now under consideration which would extend NAT mechanisms such that
IPv6 nodes could access the IPv4 Internet.
This memo proposes an in-band method for such a IPv6-IPv4 NAT to
notify affected IPv6 applications of the IPv4 transport address
associated with any of their active communication flows. A new
option for the IPv6 Destination extension header, the Translated Flow
Mapping option is hereby defined to carry this information.
Denis-Courmont Expires April 20, 2009 [Page 3]
Internet-Draft IPv6v4 mapping option October 2008
2. Definitions
TBD.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Denis-Courmont Expires April 20, 2009 [Page 4]
Internet-Draft IPv6v4 mapping option October 2008
3. IPv4-IPv6 Translation
An IPv4-IPv6 NAT performs two separate functions:
o It receives IPv4 packets on its IPv4 interface, translates them to
IPv6. To that end, for each IPv4 packet, it crafts a new IPv6
header to replace the IPv4 header, may modify the inner transport
protocol header. Then, it sends the resulting translated IPv6
packets through its IPv6 interface.
o Reciprocally, it translates IPv6 packets into IPv4 packets.
The details of IPv4-IPv6 translation are beyond the scope of this
document, please refer to [whatever IETF ends up specifying for this]
instead.
3.1. Inserting the flow mapping option
When a translator receives an IPv4 packet, following certain
conditions, it inserts an IPv6 Destination extension header
containing a Translated Flow Mapping option (as defined in the next
section).
As a general rule, this option MUST NOT be inserted, if the resulting
packet would exceed the known MTU to the IPv6 destination, or 1280
bytes if there is no known MTU.
3.1.1. Usage with connection-oriented protocols
For connection-oriented transport protocols, this option SHOULD be
inserted is part of the protocol handshake, and SHOULD NOT be
inserted otherwise.
3.1.1.1. Datagram Congestion Control Protocol (DCCP)
This option SHOULD be inserted within DCCP Sync, DCCP Sync/Ack and
DCCP Listen packets. See [RFC4340] and [I-D.ietf-dccp-simul-open].
3.1.1.2. Stream Control Transmission Protocol (SCTP)
TBD.
3.1.1.3. Transmission Control Protocol (TCP)
This option SHOULD be inserted within TCP SYN and TCP SYN/ACK
packets. See [RFC0793].
Denis-Courmont Expires April 20, 2009 [Page 5]
Internet-Draft IPv6v4 mapping option October 2008
3.2. Receiving the flow mapping option
Processing of the flow mapping option is optional. In fact, an IPv6
implementation that does not support the flow mapping option MUST
ignore it, according to [RFC2460] (this is not a new requirement for
IPv6 implementation).
The content of the flow mapping option is merely informational.
Hence, there are no particular requirements as regards its
processing. An IPv6 stack that implements the flow mapping option
MAY store and or forward the flow mapping informations, as it sees
fit. For instance, it might forward the informations to the
application (see below for an example API) if it requests them.
Denis-Courmont Expires April 20, 2009 [Page 6]
Internet-Draft IPv6v4 mapping option October 2008
4. Option format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length | Mapped Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mapped IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Translated Flow Mapping option
The Translated Flow Mapping option format is defined as follow:
Option Type: XXX (TBD: IANA)
Option Length: 12 (12 bytes)
Mapped Port: If the type of the first header that is not an IPv6
extension header is DCCP, SCTP, TCP, UDP or UDP-Lite, the
transport protocol mapped port number. This is the destination
port number found in the original IPv4 packet that was translated
into the IPv6 packet containing this option. Otherwise, this must
be set to zero by sender, and ignored by receivers.
Mapped IPv4 Address: Destination IPv4 address, as found in the
origin IPv4 packet before translation.
Remote IPv4 Address: Source IPv4 address, as found in the origin
IPv4 packet before translation.
The Translated Flow Mapping option requires a 4n alignment (as
defined per [RFC2460] section 4.2).
Denis-Courmont Expires April 20, 2009 [Page 7]
Internet-Draft IPv6v4 mapping option October 2008
5. Security Considerations
TBD.
Denis-Courmont Expires April 20, 2009 [Page 8]
Internet-Draft IPv6v4 mapping option October 2008
6. IANA Considerations
The Translated Flow Mapping option requires an IPv6 Option number.
IPv6 Option Number [RFC2460]:
HEX act chg rest
--- --- --- -----
XX 00 0 XXXXX Translated Flow Mapping
The first two bits indicate that the IPv6 node may skip over this
option and continue processing the header if it doesn't recognize the
option type, and the third bit indicates that the Option Data may not
change en-route.
This document should be listed as the reference document.
Denis-Courmont Expires April 20, 2009 [Page 9]
Internet-Draft IPv6v4 mapping option October 2008
Appendix A. API Considerations
This section is non-normative. It defines a potential API to
retrieve the flow mapping information as an extension to the Advanced
IPv6 socket API [RFC3542].
The flow mapping informations shall be passed to applications using a
structure defined in <netinet/in.h>, and containing at least the
following fields:
struct in6_ipv4flowmapping {
struct uint16_t i4fm6_mapped_port;
struct in_addr i4fm6_mapped_addr;
struct in_addr i4fm6_remote_addr;
};
Flow mapping structure
For datagram (type SOCK_DGRAM) and raw (type SOCK_RAW) sockets, a
socket option can configure receiving the flow information as
ancilliary data on a per-packet basis, using recvmsg. This socket
option shall be set to 0 (off) by default. Setting it to 1 (on)
shall enabled flow mapping infos reception. Setting it to -1
(default) shall disable it. When enabled, an ancilliary data with
level IPPROTO_IPV6, type IPV6_IPV4FLOWMAPPING shall be returned to
the application, if a Flow Mapping option was found in the received
packet.
int on = 1;
setsockopt(fd, IPPROTO_IPV6, IPV6_RECVIPV4FLOWMAPPING,
&yes, sizeof(yes));
Per-packet socket option
For a connected socket, a read-only socket option may be used to
fetch the flow mapping information if known (i.e. if at least one
packet with a Flow Mapping Option was received). If unknown, the
returned structure shall contain all zeroes.
struct in6_ipv4flowmapping val;
getsockopt(fd, IPPROTO_IPV6, IPV6_IPV4FLOWMAPPING,
&val, sizeof(val));
Connected socket option
Denis-Courmont Expires April 20, 2009 [Page 10]
Internet-Draft IPv6v4 mapping option October 2008
7. References
7.1. Normative References
[I-D.ietf-dccp-simul-open]
Fairhurst, G., "DCCP Simultaneous-Open Technique to
Facilitate NAT/Middlebox Traversal",
draft-ietf-dccp-simul-open-05 (work in progress),
October 2008.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
7.2. Informative References
[RFC3542] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei,
"Advanced Sockets Application Program Interface (API) for
IPv6", RFC 3542, May 2003.
Denis-Courmont Expires April 20, 2009 [Page 11]
Internet-Draft IPv6v4 mapping option October 2008
Author's Address
Remi Denis-Courmont
Nokia Corporation
P.O. Box 407
NOKIA GROUP 00045
FI
Phone: +358 50 487 6315
Email: remi.denis-courmont@nokia.com
Denis-Courmont Expires April 20, 2009 [Page 12]
Internet-Draft IPv6v4 mapping option October 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights 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; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Denis-Courmont Expires April 20, 2009 [Page 13]