Re: [BEHAVE] draft-bcx-behave-learn-address-00

marcelo bagnulo braun <marcelo@it.uc3m.es> Sat, 27 June 2009 08:39 UTC

Return-Path: <marcelo@it.uc3m.es>
X-Original-To: behave@core3.amsl.com
Delivered-To: behave@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19D813A686D for <behave@core3.amsl.com>; Sat, 27 Jun 2009 01:39:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.031
X-Spam-Level:
X-Spam-Status: No, score=-6.031 tagged_above=-999 required=5 tests=[AWL=-0.515, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, URIBL_RHS_DOB=1.083]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CnqrKK-CNPQR for <behave@core3.amsl.com>; Sat, 27 Jun 2009 01:39:18 -0700 (PDT)
Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 5A4E23A6829 for <behave@ietf.org>; Sat, 27 Jun 2009 01:39:17 -0700 (PDT)
Received: from marcelo-bagnulos-macbook-pro.local (133.pool85-53-136.dynamic.orange.es [85.53.136.133]) by smtp01.uc3m.es (Postfix) with ESMTP id A73F4BA00F7; Sat, 27 Jun 2009 10:39:34 +0200 (CEST)
Message-ID: <4A45DAC5.6030606@it.uc3m.es>
Date: Sat, 27 Jun 2009 10:39:33 +0200
From: marcelo bagnulo braun <marcelo@it.uc3m.es>
User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302)
MIME-Version: 1.0
To: Xing Li <xing@cernet.edu.cn>
References: <4A45BE96.1020405@cernet.edu.cn>
In-Reply-To: <4A45BE96.1020405@cernet.edu.cn>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16728.006
Cc: congxiao <congxiao@cernet.edu.cn>, behave@ietf.org
Subject: Re: [BEHAVE] draft-bcx-behave-learn-address-00
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 27 Jun 2009 08:39:20 -0000

Hi,

I am confused by this draft, let me present some questions below....

the draft reads:

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

       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.



I don't think this is the case.

I mean, when there is a packet flying from the IPv6 side to the IPv4 
side, there are two different methods for transforming the IPv6 
addresses contained in the IPv6 packet into IPv4 addresses.
there is one method for transforming the destiantion address, which is 
algorithmic and there is another method for transforming the the source 
address, which relies on a binding table state.

Now, the reverse methos of each of those is applies to the IPv4 
addresses contained in the IPv4 packets that fly in the oposite direction.

So, in nat64 there are two methods and their respective reverse methods.


So, it is certainly not true that the address mapping algortihm is used 
for turning IPv4 addresses into IPv6 addresses and that the table is 
used for turning IPv6 addresses into IPv4 addresses. Both methods are 
used for both type of addresses, but it depends whether they are used as 
source or destiantion address.

Later on the draft reads:

    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.


Again, i am kind of confused by the discussion. I mean, what do you mean 
that you will use an IPv6 prefix to represent an IPv6 address in IPv4?

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.

But why an IPv6 host woudl ever want to use the IPv4 representation of 
the IPv6 host to initiate an IPv6 communication?
Why doesn't the IPv6 initiator simply uses the IPv6 address of the IPv6 
target host?



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

I think you need to first state what method for getting the target host 
address you are using of the 3 methods you have described earlier int he 
draft i.e. either manual config, dns64 or referral


    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.

I fail to understand this option. what method of getting the target host 
address are you considering? manual, dns64 of referals?


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

 This is a feature called hairpinning in IPv4 nats and that it must be 
supported according to the behave requriements. It is expected to be 
used in corner cases, as i think it is the one you are considering. I 
mean, the normal situation would be that the IPv6 intiator uses the IPv6 
address fo the target host. In the rare case that this is not, then 
hairpinning is a reasonable solution



    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.

This case i simply don't understand.
the IPv6 hosts have an AAAA RR wich contains the IPv6 address. The DNS 
64 will return the real AAAA RR if exists. It will only synthesize if 
there is no real AAAA RR. So for IPv6 nodes, the dns64 will return the 
real IPv6 address, so it will only return synthetic AAAA RR for IPv4 
only hosts. So, there is nothing special the dns64 needs to do in order 
to behave properly in this situation.
So if dns64 is involved, then i don't see any probelms



       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.

But that basically assumes that the user that is introdudcing the 
address manually knows the IPv4 represetnation of the IPv6 target and 
not the IPv6 address, whcih would be the reasonable thing to know.

So, i don't see there is a problem here.

Regards, marcelo



Xing Li escribió:
> We have uploaded an Internet Draft "How Host A learns the IP address of
> Host B" [http://tools.ietf.org/html/draft-bcx-behave-learn-address-00],
> which is not expected to be published as an RFC. But it 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. It contains some
> technical details which are not presented in the current prefix document
> [http://tools.ietf.org/html/draft-xli-behave-v4v6-prefix-00].
>
> xing
>
>
> _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www.ietf.org/mailman/listinfo/behave
>
>