Network Working Group                                       B. Carpenter
Internet-Draft                                         Univ. of Auckland
Intended status: Experimental                           October 28, 2007
Expires: April 30, 2008


    Shimmed IPv4/IPv6 Address Network Translation Interface (SHANTI)
                       draft-carpenter-shanti-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 30, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   There is a pragmatic need for a packet-level translation mechanism
   between IPv4 and IPv6, for scenarios where no other mode of IPv4 to
   IPv6 interworking is possible.  The mechanism defined here uses a
   shim in both the translator and the IPv6 host to mitigate the
   problems introduced by stateless translation.






Carpenter                Expires April 30, 2008                 [Page 1]


Internet-Draft        Shimmed IPv4/IPv6 Translation         October 2007


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Requirements notation  . . . . . . . . . . . . . . . . . .  4
   2.  Summary of scenario  . . . . . . . . . . . . . . . . . . . . .  4
   3.  General walkthroughs . . . . . . . . . . . . . . . . . . . . .  6
   4.  Placement of the shim  . . . . . . . . . . . . . . . . . . . .  8
   5.  DNS  . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
   6.  ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  9
   7.  Unresolved issues  . . . . . . . . . . . . . . . . . . . . . .  9
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 10
     11.2. Informative References . . . . . . . . . . . . . . . . . . 10
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10
   Intellectual Property and Copyright Statements . . . . . . . . . . 12

































Carpenter                Expires April 30, 2008                 [Page 2]


Internet-Draft        Shimmed IPv4/IPv6 Translation         October 2007


1.  Introduction

   There has long been a defined mechanism for stateless translation
   betweeen IPv4 and IPv6 packet formats [RFC2765].  Its intended use is
   any scenario whether dual stack coexistence between IPv4 and IPv6,
   possibly accompanied by dual stack application level proxies, is
   insufficient.  In the most stringent case, this will occur when
   communication is needed between unmodified ("legacy") IPv4 hosts and
   IPv6-only hosts that have no IPv4 code, and no dual stack proxy is
   available for the application protocol of interest.

   The previously proposed solution for this scenario, NAT-PT [RFC2766]
   has known issues and has been deprecated [RFC4966].  The present
   proposal does not resolve all of those issues; a later section will
   identify the issues believed to remain open.  This proposal aims to
   resolve those issues that can be handled if the IPv6 protocol stack
   communicating with a translator can exchange information with the
   translator that is specific to the translation process.  The
   objectives are to ensure that
   a.  from the IPv4 host's point of view, nothing is worse than in the
       case of an IPv4-to-IPv4 translation
   b.  from the IPv6 host's point of view, no special code is generally
       required in the transport layer or above.  However, information
       about the translation is available in the IPv6 host's network
       stack, if needed.  This is the crucial difference from NAT-PT.

   To achieve these goals, a shim is inserted in the protocol stack at
   both the IPv6 host and at the translator.  Its objective is to allow
   the IPv6 stack at the host to be aware of the presence of the
   translator, of the addresses involved in the translation, and of any
   other information known by the translator that may be of value to the
   IPv6 host.  A shim model is chosen, as in SHIM6
   [I-D.ietf-shim6-proto], so that upper layer protocols (ULPs) have no
   need to be aware of anything unusual.  The mechanism is known as
   SHimmed Address Network Translation Interface (SHANTI).

   As in SHIM6, ULPs are presented with an upper layer identifier (ULID)
   in the form of an IPv6 address which is independent of any
   manipulation of addresses in the shim or translator.

   The reader is assumed to have a general understanding of SHIM6.
   Although this early draft does not assume that the SHIM6 mechanisms
   defined in [I-D.ietf-shim6-proto] would be used unchanged, they form
   a proof of concept for the type of communication required between two
   network-layer shims.

   It should be noted that this mechanism adds complexity to an IPv6-
   only host.  This has to be balanced against the complexity of a dual-



Carpenter                Expires April 30, 2008                 [Page 3]


Internet-Draft        Shimmed IPv4/IPv6 Translation         October 2007


   stack host.  In this model, no residual IPv4 code is needed in the
   IPv6 host.  The shim has to handle the rewriting of addresses and
   port numbers, but nothing else.

   It should also be noted that this mechanism strenuously avoids any
   impact whatever on IPv6 addressing and routing "on the wire".

   DISCLAIMER: This draft is incomplete.  It is posted to seek comments
   on plausibility; much more work is needed to make it implementable.

1.1.  Requirements notation

   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].


2.  Summary of scenario

   Consider an IPv6-only host X and and IPv4-only host Y.

   Let A(x) be an IPv6 address for X, and let a(y) be an IPv4 address
   for Y. Let the port in use at X be P(x) and at Y be P(y).

   We will observe later that it is irrelevant whether a(y) is
   translated by an IPv4 NAT, and whether P(y) is translated by an IPv4
   NAPT.

   Additionally, consider a translator T between X and Y. On the IPv6
   side it has address A(t) and on the IPv4 side it has address a(t).
   If port translation is in effect, P(x) will become P(tx) on the IPv4
   side.  We will observe later that the A(t) address can be chosen from
   an address pool.  We cannot assume that a(t) can be chosen from a
   pool, which is why port translation will be needed.

   Thus A() is always an IPv6 address and a() is always an IPv4 address.

   A diagram of the solution follows:













Carpenter                Expires April 30, 2008                 [Page 4]


Internet-Draft        Shimmed IPv4/IPv6 Translation         October 2007


         X                           T                        Y

     ___________ A(x)    A(t) _______________ a(t)   a(y) _______
    |   |   | V6|P(x)    P(y)| V6|   |   | V4|P(tx)  P(y)| V4|   |
    |   | S |   |            |   | S | S |   |           |   |   |
    | U | H | S |            | S | H | I | S |           | S | U |
    | L | I | T |------------| T | I | I | T |-----------| T | L |
    | P | M | A |            | A | M | T | A |           | A | P |
    |   |   | C |            | C |   |   | C |           | C |   |
    |   |   | K |            | K |   |   | K |           | K |   |
    |___|___|___|            |___|___|___|___|           |___|___|

   The address set used by the shim for X is conceptually {a(t),A(x)},
   and for Y it is conceptually {a(y),A(t)}.  In other words the ULP at
   X sees its own ULID as a(t) and Y's ULID as a(y), both filled out
   with /96 prefixes.  On the wire, the IPv6 packets between X and T use
   A(x) and A(t) as the actual address pair.  The IPv4 packets between T
   and Y use a(t) and a(y).  P(y) can be used everywhere, but we must
   assume that P(x) will be used on the IPv6 side and P(tx) on the IPv4
   side.

   If there's a NAT with routable address a(n) on the IPv4 path, it
   won't know anything is special, and a(y) will be replaced by a(n).
   X, Y and T won't know the NAT is there.  X and T will not know if Y
   has a private [RFC1918] address or if additional port translation
   takes place.

   T should have a pool of A(t) addresses, and should probably have a
   complete /64 to itself for maximum flexibility.

   When the ULP in X sends a first packet to ::FF:0:0:a(y)/128, we need
   to start a SHIM6-like process.  The shim in X is configured to catch
   such packets, and carry out a message exchange with the shim in T to
   discover the relevant a(t), A(t) and P(tx) values.  It can then
   rewrite the packet header and recompute a checksum as needed, and
   send the packet on to A(t).

   T needs to select a specific A(t) and P(tx) for each new flow, and do
   SHIM6-like things to tell X what the addresses are.  This should
   create enough state in the shims to know what to do with outbound and
   return packets.  Since T has a full /64 to work with, it can create a
   new A(t) for each new X or even for each new flow if that turns out
   to be needed.

   Note that unlike SHIM6, SHANTI must perform the shim exchange before
   sending the first packet of a traffic flow.  This is because the
   source ULID to be used must be expanded from a(t) and is not
   initially known by the source host.  Also, if P(tx) is unequal to



Carpenter                Expires April 30, 2008                 [Page 5]


Internet-Draft        Shimmed IPv4/IPv6 Translation         October 2007


   P(x), this must be learned by the shim in X. A consequence of this is
   that the shim in X must buffer packets until it has completed its
   shim exchange with T. For this solution to scale, it is important
   that the SHANTI translator has adequate capacity for the number of
   IPv6 hosts it serves, and adequate network connectivity to them.

   OPEN QUESTION: Would it be preferable to configure X with knowledge
   of a(t)?  Even so, when port translation is needed, the value of
   P(tx) can only be discovered dynamically.

   When a data packet reaches T from X, there will already be shim state
   established.  The shim will pass the packet on to SIIT for
   translation and IPv4 transmission.

   Once the shim state is established, the ULPs in both X and Y will
   work as normal.  Since T uses a specific A(t) for each X, and the
   shim at X is aware of that A(t), all port numbers are available in
   each direction on the IPv6 side.  Port mapping, if required, will
   only affect the IPv4 side of T. Also, the shim in X is aware that the
   ULP in Y believes it is using the address pair {a(t), a(y)} and the
   ports {P(tx), P(y)}.  Thus, address and port dependent fix-ups can be
   performed by the shim in X. In addition to using ::FF:0:0:a(y)/128 as
   the ULID for y, the IPv6 stack can use ::FF:0:0:a(t)/128 as the ULID
   for X, although the IPv6 packets will be sent between A(x) and A(t).
   This plus the shim's knowledge of P(tx) means that TCP and UDP
   checksums do not need to be fixed up by T. This has scaling
   advantages compared to NAT-PT.

   Additionally, with this knowledge being available in the host rather
   than being hidden in the translator as in NAT-PT, it is in principle
   possible for any address and port dependencies in the ULP to be fixed
   up in the host itself, precluding the need for Application Level
   Gateways (ALGs).  Although this would introduce a layer violation, it
   is in principle a more robust design than associating ALGs with a
   "stateless" translator.

   OPEN QUESTION: In SIIT, an "IPv4-translated" address format is
   introduced to represent a synthetic IPv4 address for the IPv6 host,
   with the ::FF:0:0:0/96 prefix.  This format, which is not in the IPv6
   address architecture [RFC4291], could be used as the ULID for X. But
   since the shim has explicit knowledge of the addresses in use, is
   there any reason to use this format in preference to the simpler
   ::FF:0:0/96 IPv4-mapped format?  The latter is assumed here.


3.  General walkthroughs

   Consider first an IPv6 client attempting to contact an IPv4 server



Carpenter                Expires April 30, 2008                 [Page 6]


Internet-Draft        Shimmed IPv4/IPv6 Translation         October 2007


   via this mechanism.  The main steps that must occur are:
   1.   ULP in X obtains Y's IPv4-mapped address ::FF:0:0:a(y)/128.  See
        DNS discussion below.
   2.   ULP sends unsolicited packet to that address.
   3.   The shim in X recognises the packet as needing attention.
   4.   The shim creates local state for a(y), P(x), and buffers the
        packet.  Also, it creates a packet to send to T. This is a
        packet containing nothing but a shim header indicating that a
        first packet is ready from A(x):P(x) to a(y):P(y).
   5.   The shim at T receives this shim header and checks for existing
        state for {A(x):P(x),a(y):P(y)}.
   6.   If no such state exists, assign an A(t) value from the pool, and
        create state.  Includes the ports.  If P(x) is already in use by
        T, assign a P(tx).  Otherwise, P(tx)=P(x).
   7.   The shim in T creates a packet to return to X. This is a packet
        containing nothing but a shim header indicating the assigned
        A(t), a(t) and P(tx).
   8.   The shim in X records this additional state, in particular
        recording ::FF:0:0:a(t)/128 as the source ULID and P(tx) as the
        translated port.
   9.   The shim in X now applies the following process to buffered and
        future packets sent from A(x), port P(x) to ::FF:0:0:a(y), port
        P(y).
        1.  Compute checksums as for addresses DA=::FF:0:0:a(y), SA=::
            FF:0:0:a(t) and ports DP=P(y), SP=P(tx).
        2.  Rewrite destination address as A(t).
        3.  Send packet to A(t).  At this point its source address is
            still A(x).
   10.  The shim in T rewrites the addresses as DA=::FF:0:0:a(y), SA=::
        FF:0:0:a(t), and the source port as P(tx), and hands the packet
        off to SIIT.
   11.  SIIT translates the packet and sends it on (destination = a(y),
        source = a(t)).
   12.  When an IPv4 return packet comes into SIIT, SIIT translates the
        packet to IPv6 and hands it to the shim in T.
   13.  The shim performs port demultiplexing on the destination port
        (which will be P(tx)) to identify the A(x) involved.
   14.  The shim sends the packet on to A(x).
   15.  The shim at X receives the packet, rewrites the addresses to
        restore the original ULIDs and P(x), and sends the packet on up
        the stack.

   Now consider an IPv4 client attempting to contact an IPv6 server via
   T. The main steps that must occur are:
   1.  T must be pre-configured to admit traffic for P(x) and forward it
       to A(x).  This is a normal port-forwarding issue, to be solved as
       for NATs or perhaps as proposed in [I-D.woodyatt-ald].  It cannot
       be performed without pre-existing state.  Assuming T has only one



Carpenter                Expires April 30, 2008                 [Page 7]


Internet-Draft        Shimmed IPv4/IPv6 Translation         October 2007


       a(t), a given P(x) can only have one IPv6 listener.
   2.  ULP in Y obtains an IPv4 address for T (believing it to be the
       actual server X).
   3.  Y sends an unsolicited packet from a(y) to a(t), port P(x).
   4.  T performs port demultiplexing and determines that the packet is
       destined for A(x).  It is therefore passed to SIIT in T,
       translated to IPv6 format, and passed on to the shim in T.
   5.  The shim inserts a shim header that will tell X the translation
       in effect, translates the addresses, and sends the packet from
       A(t) to A(x).
   6.  The shim at X receives the packet, and translates the addresses
       to ::FF:0:0:a(t)/128 and ::FF:0:0:a(y)/128.  This should checksum
       OK.
   7.  The packet is delivered to the ULP, minus the shim header.

   State will be created and subsequent packets will flow as in the
   previous case.


4.  Placement of the shim

   In SHIM6 the shim is logically placed below both the transport and
   IPsec layers, so that their checksums do not need recalculation.  In
   SHANTI, the transport layer checksum does need to be recalculated by
   the shim, rather in the manner that a NAT behaves.  However, this
   cannot be done for cryptographic checksums for obvious reasons.  The
   shim should perhaps be regarded as logically below transport, but a
   better implementation would be for each transport layer to invoke the
   shim in-line prior to executing its checksum calculation.


5.  DNS

   It is required that the IPv6 hosts "behind" a SHANTI translator
   either have a resolver that maps A records into AAAA records expanded
   with ::FF:0:0/96, or a DNS server that actually stores such records,
   or a DNS ALG that performs this transformation on the fly.  On the
   assumption that hosts behind a translator will need to be configured
   in any case, in order to activate the shim, a mapping resolver seems
   likely to be the most robust choice, applying the fate-sharing
   principle.  It would also work in a network with a mixture of SHANTI
   and dual-stack hosts.  The former would see A records mapped as AAAA,
   and the latter would see native A records.

   This illustrates that SHANTI is an all-or-nothing approach.  It
   doesn't seem plausible to activate SHANTI on a dual stack host since
   DNS entries are either mapped, or they aren't.  But why would it be
   needed?



Carpenter                Expires April 30, 2008                 [Page 8]


Internet-Draft        Shimmed IPv4/IPv6 Translation         October 2007


   "Outside" the translator, SHANTI hosts must be represented by an A
   record with the address of their translator.  Specifically, the
   host's FQDN will have one or more AAAA records with its IPv6
   address(es) and an A record with its translator's address.


6.  ICMP

   TBD


7.  Unresolved issues

   This section will be expanded to identify issues raised in [RFC4966]
   that are not resolved by the present specification.


8.  Security Considerations

   As for NAT-PT, there is no obvious way to carry network layer IPsec
   across a SHANTI translator.  There seems to be no reason IKE
   [RFC4306] cannot run in a SHANTI scenario, using its port agility
   intended for NAT tolerance.  But that in itself isn't very useful

   The use of a shim layer in SHANTI will raise some of the security
   issues considered for SHIM6 .  More analysis of the potential threats
   is needed to determine whether a cryptographic solution is needed, or
   if there is a straightforward way to prevent attackers taking over a
   session by impersonating the shim.  It may be possible to find a
   simple method of arranging a shared secret between X and T, such that
   an elementary hash can be used to authenticate the shim headers.


9.  IANA Considerations

   This document has not yet been exhaustively checked for possible
   action by the IANA.


10.  Acknowledgements

   Vital comments on a very primitive version of this proposal were made
   by Marcelo Bagnulo Braun and Iljitsch van Beijnum.  Contributions and
   comments by TBD are gratefully acknowledged.

   This document was produced using the xml2rfc tool [RFC2629].





Carpenter                Expires April 30, 2008                 [Page 9]


Internet-Draft        Shimmed IPv4/IPv6 Translation         October 2007


11.  References

11.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2765]  Nordmark, E., "Stateless IP/ICMP Translation Algorithm
              (SIIT)", RFC 2765, February 2000.

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, February 2006.

11.2.  Informative References

   [I-D.ietf-shim6-proto]
              Bagnulo, M. and E. Nordmark, "Shim6: Level 3 Multihoming
              Shim Protocol for IPv6", draft-ietf-shim6-proto-08 (work
              in progress), April 2007.

   [I-D.woodyatt-ald]
              Woodyatt, J., "Application Listener Discovery (ALD) for
              IPv6", draft-woodyatt-ald-01 (work in progress),
              June 2007.

   [RFC1918]  Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
              E. Lear, "Address Allocation for Private Internets",
              BCP 5, RFC 1918, February 1996.

   [RFC2629]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
              June 1999.

   [RFC2766]  Tsirtsis, G. and P. Srisuresh, "Network Address
              Translation - Protocol Translation (NAT-PT)", RFC 2766,
              February 2000.

   [RFC4306]  Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
              RFC 4306, December 2005.

   [RFC4966]  Aoun, C. and E. Davies, "Reasons to Move the Network
              Address Translator - Protocol Translator (NAT-PT) to
              Historic Status", RFC 4966, July 2007.









Carpenter                Expires April 30, 2008                [Page 10]


Internet-Draft        Shimmed IPv4/IPv6 Translation         October 2007


Author's Address

   Brian Carpenter
   Department of Computer Science
   University of Auckland
   PB 92019
   Auckland,   1142
   New Zealand

   Email: brian.e.carpenter@gmail.com









































Carpenter                Expires April 30, 2008                [Page 11]


Internet-Draft        Shimmed IPv4/IPv6 Translation         October 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   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.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Carpenter                Expires April 30, 2008                [Page 12]