Subject: [BEHAVE] Changes on draft-ietf-behave-v4v6-bih-08.txt

From: <[email-masked]>
Date: Fri, 23 Dec 2011 07:31:43 +0000

Behave WG,

A new revision of BIH was made to respond to comments given by IESG. In addition to some clarifications best seen in diff (http://tools.ietf.org/rfcdiff?url2=draft-ietf-behave-v4v6-bih-08), the main changes were:
- Introduction of 1.1 Terminology section
- Significantly revising section 8.  Changes since RFC2767 and RFC3338

Then there was question from Pete Resnick: "MUST the ENR wait for an explicit negative
response on the A record lookup, or can it synthesize from the AAAA in other
circumstances? Probably best to explicitly say so." For this following text was added:
--
If no reply for A query is received after 300 ms since reception of positive AAAA response, the ENR MAY choose to proceed as if there were only AAAA record available for the destination.
--

Any comments?

Best regards,

        Teemu

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext [email-masked]
Sent: 23. joulukuuta 2011 09:24
To: [email-masked]
Cc: [email-masked]
Subject: [BEHAVE] I-D Action: draft-ietf-behave-v4v6-bih-08.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF.

        Title           : Dual Stack Hosts Using "Bump-in-the-Host" (BIH)
        Author(s)       : Bill Huang
                          Hui Deng
                          Teemu Savolainen
        Filename        : draft-ietf-behave-v4v6-bih-08.txt
        Pages           : 29
        Date            : 2011-12-22

   Bump-In-the-Host (BIH) is a host-based IPv4 to IPv6 protocol
   translation mechanism that allows a class of IPv4-only applications
   that work through NATs to communicate with IPv6-only peers.  The host
   on which applications are running may be connected to IPv6-only or
   dual-stack access networks.  BIH hides IPv6 and makes the IPv4-only
   applications think they are talking with IPv4 peers by local
   synthesis of IPv4 addresses.  This document obsoletes RFC 2767 and
   RFC 3338.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-behave-v4v6-bih-08.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-behave-v4v6-bih-08.txt

_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Cameron Byrne <[email-masked]>
Date: Fri, 23 Dec 2011 04:06:48 -0800

On Dec 23, 2011 2:31 AM, <[email-masked]> wrote:
>
> Behave WG,
>
> A new revision of BIH was made to respond to comments given by IESG. In
addition to some clarifications best seen in diff (
http://tools.ietf.org/rfcdiff?url2=draft-ietf-behave-v4v6-bih-08), the main
changes were:
> If no reply for A query is received after 300 ms since reception of
positive AAAA response, the ENR MAY choose to proceed as if there were only
AAAA record available for the destination.

Do you have any data to support 300ms?  My concern is the highly latent
wireless networks will not work best with 300 ms.

Cb

> A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Behavior Engineering for
Hindrance Avoidance Working Group of the IETF.

---

From: <[email-masked]>
Date: Fri, 23 Dec 2011 12:57:52 +0000

The host should send A and AAAA in parallel, hence one would assume in usual case replies should arrive roughly at the same time. This 300ms is for difference on reply arrival times and hence should not depend much on access network latency. If the host sends queries in series, then it would be different thing. I was also considering reference to Happy Eyeballs draft: draft-ietf-v6ops-happy-eyeballs-07 , but thought maybe not..

If it is hard to agree on specific time, we could just say instead:"If no reply for A query is received after ENR implementation specific timeout, after reception of positive AAAA response, the ENR MAY choose to proceed as if there were only AAAA record available for the destination."

Best regards,

Teemu

________________________________
From: ext Cameron Byrne [[email-masked]]
Sent: Friday, December 23, 2011 2:06 PM
To: Savolainen Teemu (Nokia-NRC/Tampere)
Cc: [email-masked]
Subject: Re: [BEHAVE] Changes on draft-ietf-behave-v4v6-bih-08.txt

> circumstances? Probably best to explicitly say so." For this following text was added:

Do you have any data to support 300ms?  My concern is the highly latent wireless networks will not work best with 300 ms.

Cb

> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of ext [email-masked]<mailto:[email-masked]>
> To: [email-masked]<mailto:[email-masked]>
> Cc: [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

---

From: Cameron Byrne <[email-masked]>
Date: Fri, 23 Dec 2011 07:37:59 -0800

On Dec 23, 2011 7:57 AM, <[email-masked]> wrote:
>
> The host should send A and AAAA in parallel, hence one would assume in
usual case replies should arrive roughly at the same time. This 300ms is
for difference on reply arrival times and hence should not depend much on
access network latency. If the host sends queries in series, then it would
be different thing. I was also considering reference to Happy Eyeballs
draft: draft-ietf-v6ops-happy-eyeballs-07 , but thought maybe not..
>
> If it is hard to agree on specific time, we could just say instead:"If no
reply for A query is received after ENR implementation specific timeout,
after reception of positive AAAA response, the ENR MAY choose to proceed as
if there were only AAAA record available for the destination."

I think that new wording is prudent. A and aaaa may be cached and refreshed
separately.

Cb