Subject: [v6ops] 464xlat WGLC: BIH/CLAT behavior is uncertain

From: Maoke <[email-masked]>
Date: Mon, 10 Sep 2012 22:43:42 +0900

hi all,

sorry but raise this topic at the last minute of the last call.

i doubt there is really not uncertainty to put BIH with CLAT together. i
proposed a case where BIH/CLAT is poorly running for an in-domain server
(which is a naturally established use-case of the CLAT without BIH) but it
is argued this case is out of scope.

however, there is a very detailed discussion, in scope:

1. a host behind the BIH/CLAT is to send out a request to a server, who has
both AAAA and A type resolutions.

2. NOTE BIH is working since the stage of DNS because the host behind is
possibly IPv4-only. if BIH cannot get an AAAA, it could be silent as there
needed double-translation, fine. however, once BIH can get the AAAA type of
the server, it traslates that AAAA to an A type resolution with an IPv4
address, i.e., the synthetic IPv4 address, under its configuration.

3. then the host possibly receive two A type resolutions: the one of the
genuine A of the server (let's note it as A#1); the one of the synthetic
version made by the BIH (A#2). it might randomly select one to send out the
request.

4. the request arrives at the BIH/CLAT, uncertainty happens:
    - who takes over the work? the BIH module or the CLAT module? (not
specified yet)

    - if it is the BIH, but the host actually selects A#1, then BIH has no
state about this A#1, it has to drop the request;
    - if it is the CLAT module, but it happens that the host choose A#2,
then the CLAT will send the request to nowhere.

i don't know what we still need to make the *combination* of BIH and
464xlat safe in this document.

according to this observation and the discussion above, i suggest modifying
the last paragraph of Section 1 to the following (d) and revise other text
regarding the BIH.

(d)

   464xlat is not designed to cover the case of IPv4-only applications
   having access to IPv6-only servers. If that is needed, another
transition
   mechanism is needed.

if someone insist to cite BIH, we can add either following (e) or (f) to (d)

(e)

  This BCP doesn't guarantee the integrity of putting 464xlat and
BIH[RFC6535]
  together. If operator would like to do so, we leave the details of
the co-existance
  an open issue.

(f)
  It is not recommended to use 464xlat together with BIH [RFC6535] at the
CLAT.

- maoke

---

From: Maoke <[email-masked]>
Date: Tue, 11 Sep 2012 00:19:42 +0900

hi Remi,

sorry but i didn't explained clearly. here you are. see below my
suggestion. (d) + (e) might be acceptable to all. but in the middle, you
have clarified that BIH doesn't do the systhesis when A and AAAA are
simultaneously resolved. this has not yet reflected in the following text.

- maoke

2012/9/10 Maoke <[email-masked]>

> 1. a host behind the BIH/CLAT is to send out a request to a server, who
> has both AAAA and A type resolutions.
>
> according to this observation and the discussion above, i suggest
> modifying the last paragraph of Section 1 to the following (d) and revise
> other text regarding the BIH.
>
> (d)
>