Network Working Group                                             C. Bao
Internet-Draft                                                     X. Li
Intended status: Informational         CERNET Center/Tsinghua University
Expires: December 17, 2009                                 June 15, 2009


               How Host A learns the IP address of Host B
                   draft-bcx-behave-learn-address-00

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and 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 December 17, 2009.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

   This document describes how host A learns the IP address of host B in
   BEHAVE's "An IPv6 network to the IPv4 Internet" scenario.  In this
   scenario, an IPv6-only host A must know the IPv6 address



Bao & Li                Expires December 17, 2009               [Page 1]


Internet-Draft         How Host A learns addresses             June 2009


   representation of host B.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Host A learns IP address of host B in single address family  .  3
   3.  Convert address representation between two address families  .  3
   4.  Host A learns IP address of host B cross address families  . .  4
     4.1.  The user of host A gets the IP address manually  . . . . .  5
     4.2.  The DNS resolves the IP address from a domain name . . . .  5
     4.3.  The application performs referrals . . . . . . . . . . . .  5
   5.  Using different prefixes is considered harmful . . . . . . . .  5
     5.1.  Case 1: LIR is used to both represent IPv4 in IPv6 and
           IPv6 in IPv4 . . . . . . . . . . . . . . . . . . . . . . .  6
     5.2.  Case 4: WKP is used to represent IPv4 in IPv6 and LIR
           is used to represent IPv6 in IPv4  . . . . . . . . . . . .  7
       5.2.1.  Design a protocol to download the IPv4 address
               database to host A . . . . . . . . . . . . . . . . . .  7
       5.2.2.  Add the NAT66 function to the stateless translator
               based on the IPv4 address database . . . . . . . . . .  7
       5.2.3.  Configure the DNS64 based on the IPv4 address
               database . . . . . . . . . . . . . . . . . . . . . . .  8
   6.  Conclusions  . . . . . . . . . . . . . . . . . . . . . . . . .  8
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
   9.  Informative References . . . . . . . . . . . . . . . . . . . .  9
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10























Bao & Li                Expires December 17, 2009               [Page 2]


Internet-Draft         How Host A learns addresses             June 2009


1.  Introduction

   This document describes how host A learns the IP address of host B in
   BEHAVE's "An IPv6 network to the IPv4 Internet" scenario
   [I-D.baker-behave-v4v6-framework].  In this scenario, an IPv6-only
   host A must know the IPv6 address representation of host B, where
   host B could be an IPv4-only host or an IPv6-only host with IPv4
   address representation [I-D.xli-behave-v4v6-prefix].

   This document is intended to assist the IETF community to understand
   how host A learns the IP address of host B when an IPv4/IPv6
   translator is involved.  This document is not expected to be
   published as an RFC.  This document is part of the consideration for
   a prefix document.


2.  Host A learns IP address of host B in single address family

   The host A can use one of the following methods to learn the IP
   address of host B in single address family (AF).

   o  The user of host A gets the IP address manually.

   o  The DNS resolves the IP address from a domain name.

   o  The application performs referrals.

   Note that the "user of host A gets the IP address manually" cannot be
   avoided, e.g., someone typed http://202.38.102.2 into their browser,
   or was re-directed there, or HTML had a link at that URI
   [I-D.wing-behave-nat64-referrals].


3.  Convert address representation between two address families

   In order to performance the communication between two address
   families (IPv4 and IPv6), an IPv4 host must have an IPv6
   representation and an IPv6 host must have an IPv4 representation, as
   discussed in [I-D.xli-behave-v4v6-prefix].

   There are two translation schemes named stateless translation and
   stateful translation and the methods to represent IPv4 in IPv6 and to
   represent IPv6 in IPv4 are somehow different
   [I-D.xli-behave-v4v6-prefix].

   o  For the stateless translation, the address mapping algorithm is
      used both to represent IPv4 in IPv6 and IPv6 in IPv4.  Note that
      in this case, blocks of service provider's IPv4 addresses are



Bao & Li                Expires December 17, 2009               [Page 3]


Internet-Draft         How Host A learns addresses             June 2009


      mapped into IPv6 and used by physical IPv6 hosts.  The original
      IPv4 form of these blocks of service provider's IPv4 addresses are
      used to represent the physical IPv6 hosts in IPv4.  Note that the
      stateless translation supports both IPv6 initiated as well as IPv4
      initiated communications.

   o  For the stateful translation, the address mapping algorithm is
      used to represent IPv4 in IPv6, while a session initiated state
      table is used to represent IPv6 in IPv4.  Note that in this case,
      blocks of service provider's IPv4 addresses are maintained in the
      translator as the IPv4 address pools and dynamically bind to the
      specific IPv6 addresses.  The original IPv4 form of these blocks
      of service provider's IPv4 addresses are used to represent the
      physical IPv6 host in IPv4.  However, due to the dynamical
      binging, the stateful translation only supports the IPv6 initiated
      communication.

   The embedded address format is used as the address mapping algorithm
   [I-D.xli-behave-v4v6-prefix] as shown in Figure 1.

             0              n        63 n+31                127
             |              |        |  |                    |
             +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
             |  PREFIX      | IPv4 addr |  SUFFIX            |
             +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
             |                       |                       |
             |<--- network part ---->|<---   host part   --->|


                     Figure 1: Embedded Address Format

   In this algorithm, the IPv4 address is embedded in IPv6 address after
   the PREFIX.  The PREFIX can either be LIR prefix or WKP prefix, where
   the LIR is the prefix in the service provider's address block, while
   the WKP is the prefix allocated by IANA and independent to the
   service provider's address blocks.  The advantage of LIR is that it
   is part of the service provider's block and can be aggregated, while
   the advantage of WKP is that it can be hard coded in the network
   devices and in the end systems without manual configuration.


4.  Host A learns IP address of host B cross address families

   Assume host A is an IPv6 host and host B has an IPv4 address, then
   host A must know the IPv6 representation of host B derived from host
   B's IPv4 address.





Bao & Li                Expires December 17, 2009               [Page 4]


Internet-Draft         How Host A learns addresses             June 2009


4.1.  The user of host A gets the IP address manually

   Assume host A has IPv6 address 2001:db8::1 and host B has IPv4
   address 166.111.8.238, then the user of host A must convert this IPv4
   address into its IPv6 representation [PREFIX:166.111.8.238:SUFFIX]
   based on the address mapping algorithm [I-D.xli-behave-v4v6-prefix].
   Note that the host A or the user of host A must know the PREFIX in
   order to do the conversion.  When the IPv4 address of host B and
   PREFIX of the address mapping algorithm are known to host A, the IPv6
   representation of host B can be created.  In addition, if the PREFIX
   is a WKP prefix, it can be hard coded in host A, while if the PREFIX
   is a LIR prefix, it can be obtained by host A via the method
   described in [I-D.wing-behave-learn-prefix].  For example, the user
   of host A will type telnet [PREFIX:166.111.8.238:SUFFIX].

4.2.  The DNS resolves the IP address from a domain name

   Assume host A has IPv6 address 2001:db8::1 and host B has a domain
   name www.edu.cn (there is an A record 202.205.109.203, but no AAAA
   record), then the host A will ask the DNS64 for the AAAA record of
   www.edu.cn.  The DNS64 will get the A record 202.205.109.203 from the
   global domain name system and convert to the AAAA record [PREFIX:
   202.205.109.203:SUFFIX] based on the address mapping algorithm
   [I-D.xli-behave-v4v6-prefix] [I-D.bagnulo-behave-dns64].  Note that
   the DNS64 must know the PREFIX.

4.3.  The application performs referrals

   [I-D.wing-behave-nat64-referrals] discusses the referral for SIP and
   BitTorrent.

   In the case of SIP, "An IPv6 node SHOULD also be able to send and
   receive media using IPv4 addresses, but if it cannot, it SHOULD
   support STUN relay usage.  Such a relay allows the IPv6 node to
   indirectly send and receive media using IPv4
   [I-D.ietf-sipping-v6-transition].  Thus, all IPv6 nodes running SIP
   are expected to support ICE [I-D.ietf-mmusic-ice] which allows
   simultaneous referral of multiple IP addresses, even from different
   IP address families."

   The BitTorrent uses HTTP URIs and DNS names, the examples in Sections
   4.1 and 4.2 are also applied here.


5.  Using different prefixes is considered harmful

   The above examples are straightforward.  However, for the stateless
   translation in the "the user of host A gets the IP address manually"



Bao & Li                Expires December 17, 2009               [Page 5]


Internet-Draft         How Host A learns addresses             June 2009


   case and under the following condition, the situation gets very
   complicated.

   o  As discussed in Section 3, for the stateless translation, the
      address mapping algorithm is used both to represent IPv4 in IPv6
      and IPv6 in IPv4.  So when host A gets an arbitrary IPv4 address
      of host B, it could be used by physical IPv4 host or it could be
      mapped to IPv6 based on the address mapping algorithm and used by
      physical IPv6 host.  It is clear that host A does not have the
      information to tell which case is applied.

   o  As discussed in Section 3, for the stateless translation, the
      PREFIX can be either LIR or WKP.  So the possibilities are:

      1.  Use LIR to represent IPv4 in IPv6 and use LIR to represent
          IPv6 in IPv4.

      2.  Use WKP to represent IPv4 in IPv6 and use WKP to represent
          IPv6 in IPv4.

      3.  Use LIR to represent IPv4 in IPv6 and use WKP to represent
          IPv6 in IPv4.

      4.  Use WKP to represent IPv4 in IPv6 and use LIR to represent
          IPv6 in IPv4.

   [I-D.xli-behave-v4v6-prefix] discussed why WKP cannot be used to
   represent IPv6 in IPv4, which means that case (2) and case (3) should
   not be used.  This document shows that case (1) should be used and
   case (4) is considered harmful.

   For the stateful translator, this problem does not exist, since the
   PREFIX is only used to present IPv4 in IPv6.

5.1.  Case 1: LIR is used to both represent IPv4 in IPv6 and IPv6 in
      IPv4

   Assume host B has IPv4 address 202.38.108.2, if the LIR is used to
   both represent IPv4 in IPv6 and IPv6 in IPv4, the "more specific win"
   routing principle will forward the packets to the right destination
   [I-D.xli-behave-v4v6-prefix], no matter whether it is used by IPv4
   host or by IPv6 host.

   o  If 202.38.108.2 is used by physical IPv4 host, the routing entry
      covers the IPv4 address 202.38.108.2 will be [LIR::]/M, where M is
      the LIR prefix length, which is corresponding to the IPv4 default
      route.  The IPv6 packets containing [PREFIX:202.38.108.2:SUFFIX]
      as the destination address will be forwarded to the IPv4/IPv6



Bao & Li                Expires December 17, 2009               [Page 6]


Internet-Draft         How Host A learns addresses             June 2009


      translator and translated into the IPv4 packets and will be
      forwarded to the host B 202.38.108.2.

   o  If 202.38.108.2 is mapped to IPv6 and used by physical IPv6 host,
      the routing entry covers the IPv4 address 202.38.108.2 will be
      [LIR:202.38.108.0:SUFFIX]/(M+k), where M is the LIR prefix length
      and k is the prefix length of the service provider's IPv4 block
      which is mapped to IPv6.  The IPv6 packets containing [PREFIX:
      202.38.108.2:SUFFIX] as the destination address will be forwarded
      to the host B [PREFIX:202.38.108.2:SUFFIX] directly.

5.2.  Case 4: WKP is used to represent IPv4 in IPv6 and LIR is used to
      represent IPv6 in IPv4

   In this case, depending on whether the IPv4 address is used by
   physical IPv4 host or the physical IPv6 host, the WKP or LIR should
   be correctly determined, since the former means representing IPv4 in
   IPv6 and the latter means representing IPv6 in IPv4.

   o  If the IPv4 address 202.38.108.2 is used by IPv4 host, the routing
      entry covers the address will be [WKP::]/M, where M is the WKP
      prefix length.  Then user of host A must type in telnet [WKP:
      202.38.108.2:SUFFIX] to access host B.

   o  If the IPv4 address 202.38.108.2 is mapped to IPv6 and used by
      IPv6 host, the routing entry covers the address will be [LIR:
      202.38.108.0:SUFFIX]/(N+k), where N is the LIR prefix length and k
      is the prefix length of the service provider's IPv4 block which is
      mapped to IPv6, then the user of host A must type in telnet [LIR:
      202.38.108.2:SUFFIX] to access host B.

   Therefore, host A must know which prefix to use.  There are several
   methods to use, but they all have drawbacks.

5.2.1.  Design a protocol to download the IPv4 address database to host
        A

   It is possible to design a protocol to download the database of all
   the IPv4 blocks which are mapped to IPv6 and used by physical IPv6
   hosts (in the service provider's administrative domain) to host A.
   However, this is not a good solution due to the complicity.

5.2.2.  Add the NAT66 function to the stateless translator based on the
        IPv4 address database

   If the IPv4/IPv6 translator can perform the NAT66 translation
   function, i.e. swap the prefixes between LIR and WKP, then it is
   possible for host A to use WKP to reach host B no matter which



Bao & Li                Expires December 17, 2009               [Page 7]


Internet-Draft         How Host A learns addresses             June 2009


   address family it locates.  However, in this case, the routing is not
   optimal.  For example, host A can convert the host B's IPv4 address
   202.38.108.2 to [WKP:202.38.108.2:SUFFIX].  The network will forward
   the packets containing [WKP:202.38.108.2:SUFFIX] as the destination
   address to the translator.  Then the translator will check the
   database of all the IPv4 blocks which are mapped to IPv6 and used by
   physical IPv6 hosts.

   o  If the destination address in the packets does not match the entry
      in the database, the translator will translate the IPv6 packets to
      IPv4 and forward the packets to host B 202.38.108.2.

   o  If the destination address in the packets matches the entry in the
      database, the NAT66 function will swap the WKP to LIR and re-route
      the packets back to the IPv6 network to the host B [LIR:
      202.38.108.2:SUFFIX].

   However, this is not a good solution due to the nature of non-optimal
   routing.

5.2.3.  Configure the DNS64 based on the IPv4 address database

   If the DNS64 is configured with database of all the IPv4 blocks which
   are mapped to IPv6 and used by physical IPv6 hosts, the DNS64 can
   return the AAAA record with the correct PREFIX.

   However, this is not a good solution due to the lack of support for
   "The user of host A gets the IP address manually" case.


6.  Conclusions

   In the unicast communication scheme, when host A needs to communicate
   with host B, host A must know the IP address of host B. This document
   describe how host A learn the IPv6 address representation of host B
   in BEHAVE's "An IPv6 network to the IPv4 Internet" scenario.

   It clear that for the stateless translation case, the PREFIX used to
   represent IPv4 in IPv6 and to represent IPv6 in IPv4 must be the same
   and LIR must be used.


7.  Security Considerations

   There is no security considerations.






Bao & Li                Expires December 17, 2009               [Page 8]


Internet-Draft         How Host A learns addresses             June 2009


8.  IANA Considerations

   This memo adds no new IANA considerations.


9.  Informative References

   [I-D.bagnulo-behave-dns64]
              Bagnulo, M., Sullivan, A., Matthews, P., Beijnum, I., and
              M. Endo, "DNS64: DNS extensions for Network Address
              Translation from IPv6 Clients to  IPv4 Servers",
              draft-bagnulo-behave-dns64-02 (work in progress),
              March 2009.

   [I-D.baker-behave-v4v6-framework]
              Baker, F., Li, X., and C. Bao, "Framework for IPv4/IPv6
              Translation", draft-baker-behave-v4v6-framework-02 (work
              in progress), February 2009.

   [I-D.baker-behave-v4v6-translation]
              Baker, F., "IP/ICMP Translation Algorithm",
              draft-baker-behave-v4v6-translation-02 (work in progress),
              February 2009.

   [I-D.ietf-behave-turn-ipv6]
              Camarillo, G. and O. Novo, "Traversal Using Relays around
              NAT (TURN) Extension for IPv6",
              draft-ietf-behave-turn-ipv6-06 (work in progress),
              March 2009.

   [I-D.ietf-mmusic-ice]
              Rosenberg, J., "Interactive Connectivity Establishment
              (ICE): A Protocol for Network Address  Translator (NAT)
              Traversal for Offer/Answer Protocols",
              draft-ietf-mmusic-ice-19 (work in progress), October 2007.

   [I-D.ietf-sipping-v6-transition]
              Camarillo, G., "IPv6 Transition in the Session Initiation
              Protocol (SIP)", draft-ietf-sipping-v6-transition-07 (work
              in progress), August 2007.

   [I-D.wing-behave-learn-prefix]
              Wing, D., Wang, X., and X. Xu, "Learning the IPv6 Prefix
              of an IPv6/IPv4 Translator",
              draft-wing-behave-learn-prefix-02 (work in progress),
              May 2009.

   [I-D.wing-behave-nat64-referrals]



Bao & Li                Expires December 17, 2009               [Page 9]


Internet-Draft         How Host A learns addresses             June 2009


              Wing, D., "Referrals Across a NAT64",
              draft-wing-behave-nat64-referrals-00 (work in progress),
              March 2009.

   [I-D.xli-behave-v4v6-prefix]
              Bao, C., Baker, F., and X. Li, "IPv4/IPv6 Translation
              Prefix Recommendation", draft-xli-behave-v4v6-prefix-00
              (work in progress), April 2009.

   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
              Description Protocol", RFC 4566, July 2006.


Authors' Addresses

   Congxiao Bao
   CERNET Center/Tsinghua University
   Room 225, Main Building, Tsinghua University
   Beijing  100084
   CN

   Phone: +86 62785983
   Email: congxiao@cernet.edu.cn


   Xing Li
   CERNET Center/Tsinghua University
   Room 225, Main Building, Tsinghua University
   Beijing  100084
   CN

   Phone: +86 62785983
   Email: xing@cernet.edu.cn


















Bao & Li                Expires December 17, 2009              [Page 10]