Subject: a trivial answer

From: Quality Quorum <[email-masked]>
Date: Thu, 24 Apr 2003 12:58:48 -0400

Hi,

I am putting together a draft summarizing address translation for IPv6.
The draft of the draft is appended to this mail, it is tiny.

Main features

1. Each node has only one address and this address is a site-local one.
   This local address is trnaslated to global and vice versa when packet
   crosses borders of its site.

2. Port information is preserved, so IPSEC and similar protocols will work
   without problems. It is possible to keep servers behind address
   translating firewalls.

3. It is possible to do tunneling without affecting MTU this way.

4. There are trivial node requirements changes.

5. It is so trivial, that there is practically no doubt that people will
   use no  matter what IETF thinks and whether or not proposed node
   requirement changes will be adopted.

Thanks,

Aleksey

=====================================================================

Network Working Group                                         A. Romanov
Internet-Draft                                                       QQI
Expires: September 3, 2003                                 March 5, 2003

              Trivial Address Aliasing Framework for IPv6
                         draft-aromanov-taaf-00

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 September 3, 2003.

Copyright Notice

   Copyright (C) The Internet Society (2003). All Rights Reserved.

Abstract

   There are a number of issues that may make address aliasing for IPv6
   desirable. This memo proposes a trivial address aliasing framework,
   which is simple to implement, provides a low load on network
   elements, and (almost) stateless operations and could be used for
   many purposes, including low impact tunnels.

1. Overview

   There are number of compelling issues that may make the address
   aliasing a desirable option for IPv6 deployment.

   o  A stable private address space, for example allowing a site to go
      from single-homing into multi-homing and then back without any
      changes on the inside.

   o  A complete hiding/decoupling of the local address space and
      topology from the outside world both to increase security and to
      prevent any spillage of information about local topology changes
      into global space.

   o  Light-weight tunnels for multi-homing, VPNs and other applications
      requiring tunnels with no MTU overhead and working ICMP from
      intermediate routers.

   o  Effective use of 128-bit addresses without unnecesary growth of
      routing tables and without excessive prefix matching load on hosts
      and routers.

2. Local Address

   For the purpose of this memo it is a class of IPv6 addresses reserved
   for local use, for example a site-local address defined in [1]. While
   it is not required for this address to be globally unique, however,
   it is desirable in order to improve the error detection and to
   simplify debugging. At least, it seems reasonable for an organization
   to select a random fixed prefix common for all its local addresses.

   Local address does not have any geographical meaning, any datagram
   using local address as a source, destination or next hop option
   should be silently dropped by every IPv6 entity located outside the
   specific site. For example IPv6 routers can have a route redirecting
   all local addresses to a black hole, and more specific route(s)
   dealing with local addresses which are truly local.

3. Global Address and Local-to-Global Mapping

   For the purpose of this memo a global address is a global IPv6
   addresses defined in [1].  We can conceptually split a global address
   into three parts, upper 64 bits (U), next 48 bits (M), and bottom 16
   bits (L).

   When a firewall has to construct a global alias (G) for a local
   address (A) using a global /64 prefix (P), first it finds/allocates a
   unique 48-bit id (I) for the A and, then it constructs G as follows
   G-U = P, G-M = I, G-L = A-L.

   Local Address

   |        64 bits     |            64  bits                   |
   +--------------------+-------------+-------------------------+
   |   Local Prefix     |          Interface-id                 |
   +--------------------+-------------+-------------------------+

   Global Address

   |        64 bits     |   48 bits   |         16 bits         |
   +--------------------+-------------+-------------------------+
   |   Global Prefix    |  Unique-Id  | 16 bits of interface-id |
   +--------------------+-------------+-------------------------+

   When a firewall has to find local address (A) matching for a global
   alias (G), it uses  G-M to find an address (A) in its database, it
   verifies that G-L equals to A-L and then it replaces G with A.

   The flat 48-bit id space  allows to map a huge local network and/or
   have several nested levels of address aliasing. The mapping could be
   either dynamic or permanent. Permanent mapping allows for completely
   stateless operation with redundant address translating firewalls.

4. Other Cases of Address Aliasing

   We can expect that aliasing will be used for other types of
   addresses. For example the same method could be used to map a global
   address to MHAP [2] address and vice versa.

5. Upper Layer Checksums

   Upper layer checksum calculation established by [3] should be limited
   to 2 LSB of both source and destination addresses. It seems that this
   method of checksum calculation would still provide for data integrity
   with minimum required changes in the endpoint protocol stack. If this
   is unacceptable, then the firewalls will be loaded with payload
   parsing and checksum calculations.

6. Node Requirements

   Node has to be prepared to deal with address translation issues.
   Particularly, lower layers of the stack have to patch the payload if
   it is required by upper layers. It is expected that applications will
   rely on peer transport address instead of addresses supplied in the
   protocol streams (e.g. FTP PORT command), so this patching will be a
   very limited.

   If local addresses are relatively unique then it would be easy to
   catch all cases where behind-the-firewall-peer supplied local address
   in a HTTP protocol body.

7. Ingress Operations

   Address translating firewall should use M-part of a destination
   address to find matching local address, it should replace the
   destination address with the found local address and then forward it
   through the local network, see Section 3.

8. Egress Operations

   If the packet is an ICMP error message originated on
   non-globally-visible router, a firewall has to use its own address as
   a source. Otherwise, the firewall should find a 48-bit unique
   identifier matching a source address, it has to replace the source
   address with a global address constructed as follows: a 64-bit global
   prefix, a 48-bit unique identifier, 16 bits of original interface-id,
   see Section 3.

   The firewall has to patch payload of all ICMP messages containing a
   copy of an invoking packet, by replacing the destination address in
   this copy with its global alias and by changing ICMP checksum
   accordingly.

9. Tunnel Operations

   It is possible to use the same method to alias both source and
   destination address, thus providing tunnels with no MTU impact and
   transparent ICMP support. The tunnel operations are very similar to
   the ones described above.

   The only difference is that an ingress firewall has to process ICMP
   error messages originated by the routers in the tunnel: it has to
   replace a source address with its own local address and then patch
   the payload replacing both the destination address and the source
   address in the copy of an invoking packet .

10. Example

   We will use following format to represent address/port of the packet:
   d-addr/d-port:s-addr/s-port. We will designate a local address of
   host X as LX, global address of the same host will be GX, a port on
   this host will designated as PX

   Simple transaction: Host A sends UDP/TCP frame to host B and receives
   reply. It is a responsibility of a firewall to patch the payload of
   ICMP reply messages; if this transaction contains FTP 'PORT' command
   the stack on the host B has to use GA instead of address provided in
   the protocol body.

   [A] --GB/PB:LA/PA-> [fw] --GB/PB:GA/PA-> [fw] --LB/PB:GA/PA-> [B]

   [A] <-LA/PA:GB/PB-- [fw] <-GA/PA:GB/PB-- [fw] <-GA/PA:LB/PB-- [B]

References

   [1]  Hinden, R. and S. Deering, "IP Version 6 Addressing
        Architecture", RFC 2373, July 1998.

   [2]  Py, M., "Multi Homing Translation Protocol (MHTP)",
        draft-py-multi6-mhtp-01 (work in progress), November 2001.

   [3]  Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
        Specification", RFC 2460, December 1998.

Author's Address

   Aleksey Romanov
   Quality Quorum, Inc.

   EMail: [email-masked]

Appendix A. Acknowledgments

   The author would like to thank Flavio Fernandes and Frank Katenholz
   for very constructive reviews. Also, the author is deeply thankful to
   M.Rose for XML specifications and tools used to write this memo.

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
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------