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 > >
- [BEHAVE] draft-bcx-behave-learn-address-00 Xing Li
- Re: [BEHAVE] draft-bcx-behave-learn-address-00 marcelo bagnulo braun