From internet-drafts@ietf.org Wed Dec 7 06:24:48 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D799821F8B9C; Wed, 7 Dec 2011 06:24:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kz5tNiBigmUn; Wed, 7 Dec 2011 06:24:48 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EAAC21F8AD6; Wed, 7 Dec 2011 06:24:48 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64 Message-ID: <20111207142448.17087.70251.idtracker@ietfa.amsl.com> Date: Wed, 07 Dec 2011 06:24:48 -0800 Cc: behave@ietf.org Subject: [BEHAVE] I-D Action: draft-ietf-behave-v4v6-bih-07.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2011 14:24:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Behavior Engineering for Hindrance Av= oidance 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-07.txt Pages : 29 Date : 2011-12-07 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-07.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-07.txt From jouni.nospam@gmail.com Fri Dec 9 02:13:20 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F46E21F84A3 for ; Fri, 9 Dec 2011 02:13:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.905 X-Spam-Level: X-Spam-Status: No, score=-2.905 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LnRSb1Zo3jp5 for ; Fri, 9 Dec 2011 02:13:20 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id AAF5121F84A1 for ; Fri, 9 Dec 2011 02:13:19 -0800 (PST) Received: by bkbzs8 with SMTP id zs8so3086651bkb.31 for ; Fri, 09 Dec 2011 02:13:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=Anh55ZzYenB+RMdIiViMLIIE2F9LtCfURpRQ99WLRYU=; b=TQZNPqnrxaoo1XLmOJdrLYRRmgIxvP0vYjvgb0qtl5A+ZciE1Sgjm2rTpiI2v0/83r h2pp81l/0CPhs+wVmw5BKw9r47oGiuECEUaPP61rQXu/rWgaW9imZ4RLJBgafJ6nlwyv AckRrsGIlNPrgXonx10bvF5MhJa7osjS8YiIQ= Received: by 10.180.94.71 with SMTP id da7mr10052809wib.29.1323425598347; Fri, 09 Dec 2011 02:13:18 -0800 (PST) Received: from [10.255.134.144] ([192.100.123.77]) by mx.google.com with ESMTPS id hn15sm12608188wib.22.2011.12.09.02.13.16 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 09 Dec 2011 02:13:16 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: Date: Fri, 9 Dec 2011 12:13:09 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <77E3CD15-1BC5-4CEF-B15E-4DB8E0F5094A@gmail.com> References: To: Songhaibin X-Mailer: Apple Mail (2.1084) Cc: Behave WG Subject: Re: [BEHAVE] tsv-dir review of draft-ietf-behave-nat64-learn-analysis-01 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2011 10:13:20 -0000 Haibin, On Nov 11, 2011, at 3:18 AM, Songhaibin wrote: >>> Another minor comment: >>>=20 >>> In section 4.6.1 , [I-D.boucadair-dhcpv6-shared-address-option] also = support >> NAT64 prefix allocation for building IPv4-embedded IPv6 address using = DHCPv6 >> option. And this should be mentioned in the document. >>=20 >> Ok. Will add this. >>=20 >=20 > Then I am okay with this draft. Now that I made edits to the I-D I think the above is already covered in = -01. The current text says: Section 4 of [I-D.boucadair-dhcpv6-shared-address-option] defines a DHCPv6 option that can be used to communicate to a requesting host the prefix used for building IPv4-Converted IPv6 addresses together with the format type and therefore also the used address synthesis algorithm. Provisioning the format type is required so as to be correctly handled by the NAT64-enabled devices deployed in a given domain. So we can convey the pref64 to the host, which can then use it to = construct an ipv4-concerted ip6 address (which is a variant of = IPv4-embedded IPv6 addresses per RFC6052). - Jouni= From internet-drafts@ietf.org Fri Dec 9 02:15:43 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A11121F85DB; Fri, 9 Dec 2011 02:15:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W3mh52ZpF8Nk; Fri, 9 Dec 2011 02:15:42 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B61E221F84A1; Fri, 9 Dec 2011 02:15:42 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64 Message-ID: <20111209101542.6375.3479.idtracker@ietfa.amsl.com> Date: Fri, 09 Dec 2011 02:15:42 -0800 Cc: behave@ietf.org Subject: [BEHAVE] I-D Action: draft-ietf-behave-nat64-learn-analysis-02.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2011 10:15:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Behavior Engineering for Hindrance Av= oidance Working Group of the IETF. Title : Analysis of solution proposals for hosts to learn NAT64 = prefix Author(s) : Jouni Korhonen Teemu Savolainen Filename : draft-ietf-behave-nat64-learn-analysis-02.txt Pages : 25 Date : 2011-12-09 Hosts and applications may benefit from the knowledge if an IPv6 address is synthesized, which would mean a NAT64 is used to reach the IPv4 network or Internet. This document analyses a number of proposed solutions for communicating whether the synthesis is taking place, used address format, and the IPv6 prefix used by the NAT64 and DNS64. The solutions enable both NAT64 avoidance and intentional utilization by allowing local IPv6 address synthesis. The document concludes by recommending selection of heuristic discovery based solution. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-nat64-learn-analysis-= 02.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-nat64-learn-analysis-0= 2.txt From dwing@cisco.com Fri Dec 9 08:44:48 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52D1521F8801 for ; Fri, 9 Dec 2011 08:44:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.473 X-Spam-Level: X-Spam-Status: No, score=-106.473 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uXTTybwiOF2a for ; Fri, 9 Dec 2011 08:44:47 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 59D1521F8797 for ; Fri, 9 Dec 2011 08:44:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=8503; q=dns/txt; s=iport; t=1323449087; x=1324658687; h=from:to:subject:date:message-id:mime-version: content-transfer-encoding; bh=hQcZXMnh+gyU75WOncduqoQNL5vXDxQE/YoN/SPYfGc=; b=ZckomM17CoEH7/I7vCjlTJgQBoOTK6MRWe7ynjNJp4Jx3nCdhNc2ZDI6 SSAnaeQ5NNG/CqeaWkuXCnZ682Mj5G0D7DZpZBDUBHBXpaPDNGNq4o8Iw Cr1YpfOH2RZrYnvknYdiRqZzDZnDOjjge7dBKR1vxJ0Xd4dxDull+QSw5 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApIAAOA64k6rRDoI/2dsb2JhbABDmjuBao5UgQWBcgEBAQEDCAoBFxAtBAMXAQUJDwIEAQEoICMKBwEBBQQBBBMJAheHbZYpgSYBngyLcgSIMIRIKAGaFw X-IronPort-AV: E=Sophos;i="4.71,326,1320624000"; d="scan'208";a="18943005" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 09 Dec 2011 16:44:47 +0000 Received: from dwingWS ([10.32.240.195]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id pB9GikOw021095 for ; Fri, 9 Dec 2011 16:44:46 GMT From: "Dan Wing" To: Date: Fri, 9 Dec 2011 08:44:46 -0800 Message-ID: <030f01ccb691$dc50d5a0$94f280e0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acy2kcByqGAWhY++RnaX2SxsFVRe1gAABEWA Content-Language: en-us Subject: [BEHAVE] FW: publication request, draft-ietf-behave-lsn-requirements-05 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2011 16:44:48 -0000 FYI -----Original Message----- From: Dan Wing [mailto:dwing@cisco.com] Sent: Friday, December 09, 2011 8:44 AM To: 'iesg-secretary@ietf.org' Cc: 'behave-chairs@tools.ietf.org'; 'draft-ietf-behave-lsn-requirements@tools.ietf.org' Subject: publishcation request, draft-ietf-behave-lsn-requirements-05 BEHAVE has finished with draft-ietf-behave-lsn-requirements-05, and requests publication. Proto writeup below. Thanks, -d ----- (1.a) Who is the Document Shepherd for this document? document: draft-ietf-behave-lsn-requirements-05 shepherd: Dan Wing, dwing@cisco.com Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Yes. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? Yes, sufficient review has been performed. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization, or XML? No concerns. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. No concerns. An IPR declaration exists against the document, https://datatracker.ietf.org/ipr/1648/ (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? Consensus is strong, except for a split between some WG members wanting "SHOULD support bulk port allocation" (in order to reduce logging) and other WG members who think no recommendation should be made. So, the document merely describes the trade-offs in its Section 5. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No significant conflict with this document has occurred. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/.) Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type, and URI type reviews? No such reviews are needed. If the document does not already indicate its intended status at the top of the first page, please indicate the intended status here. Intended status: BCP (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. Yes, all references are split. (1.i) Has the Document Shepherd verified that the document's IANA Considerations section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC2434]. If the document describes an Expert Review process, has the Document Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during IESG Evaluation? This document does not need any IANA action. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? There is nothing in this document defined in a formal language. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. "This document defines common requirements for Carrier-Grade NAT (CGN)." Working Group Summary Was there anything in the WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? Some controversy around bulk port allocation, as described above. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type, or other Expert Review, what was its course (briefly)? In the case of a Media Type Review, on what date was the request posted? Personnel Who is the Document Shepherd for this document? Who is the Responsible Area Director? If the document requires IANA experts(s), insert 'The IANA Expert(s) for the registries in this document are .' shepherd: Dan Wing, dwing@cisco.com responsible AD: David Harrington The Document Shepherd MUST send the Document Shepherd Write-Up to the Responsible Area Director and iesg-secretary@ietf.org together with the request to publish the document. The Document Shepherd SHOULD also send the entire Document Shepherd Write-Up to the working group mailing list. If the Document Shepherd feels that information which may prove to be sensitive, may lead to possible appeals, or is personal needs to be written up, it SHOULD be sent in direct email to the Responsible Area Director, because the Document Shepherd Write-Up is published openly in the ID Tracker. Question (1.f) of the Write-Up covers any material of this nature and specifies this more confidential handling. From dwing@cisco.com Mon Dec 19 10:33:20 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A494F1F0C55 for ; Mon, 19 Dec 2011 10:33:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H9KQDVZae2XH for ; Mon, 19 Dec 2011 10:33:20 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 006E41F0C54 for ; Mon, 19 Dec 2011 10:33:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=791; q=dns/txt; s=iport; t=1324319600; x=1325529200; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=B55Luuc13Tfo+dy81IVTK9TzZz0DWzjxE/sr8FCXTVk=; b=iHYrWpZ83xPYqGle7PUBZA5niJIdHwYUKGdXzDwIt76EwvxwxdtOeybl aBuxGogjE/zTBEi+noRLpP9IGp6dIDioJ1dUUgfuthxVRWcCMLm9pXMJk yzvyijAdl11K13spBPwroT5HkZTa6IEZ8YmkiEv9kn3wxvhxLCN7LPoac k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAHuC706rRDoI/2dsb2JhbAA5Cpx+jmaBBYF5CAoBFQIQPw0FGFAjHAEEHAIXh2CZdAGeOYhLH4MaBIg2hE4pAZof X-IronPort-AV: E=Sophos;i="4.71,377,1320624000"; d="scan'208";a="21548530" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 19 Dec 2011 18:33:16 +0000 Received: from dwingWS (sjc-vpn5-1853.cisco.com [10.21.95.61]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id pBJIXFK3023201; Mon, 19 Dec 2011 18:33:16 GMT From: "Dan Wing" To: Date: Mon, 19 Dec 2011 10:33:15 -0800 Message-ID: <000101ccbe7c$ac9eeb60$05dcc220$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acy+fGBQxa/Co/VCQz+xTNL9B13HSg== Content-Language: en-us Cc: behave-chairs@tools.ietf.org Subject: [BEHAVE] IETF82 minutes posted X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 18:33:20 -0000 Minutes for BEHAVE's meeting at IETF82 are now posted at http://www.ietf.org/proceedings/82/minutes/behave.txt Corrections to the minutes are accepted by IETF until January 5th. The chairs will need corrections a day or two before that deadline. There was one comment during Alain Durand's SD-NAT presentation where we didn't get the speaker's name because the speaker didn't provide his name at the microphone. If someone can help identify the speaker, it is at 137:30 into the recording at http://www.ietf.org/audio/ietf82/ietf82-3fbanquet-20111117-1506-am.mp3, and minutes show: SD-NAT (Alain Durand) --------------------- ?: doesn't this break port randomization Alain: port randomization happens within the port block at the host/cpe Thanks, -d From internet-drafts@ietf.org Tue Dec 20 00:35:40 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0589021F8AAF; Tue, 20 Dec 2011 00:35:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pOFeKh7EVdKJ; Tue, 20 Dec 2011 00:35:39 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89F5F21F8A4E; Tue, 20 Dec 2011 00:35:39 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20111220083539.23539.13400.idtracker@ietfa.amsl.com> Date: Tue, 20 Dec 2011 00:35:39 -0800 Cc: behave@ietf.org Subject: [BEHAVE] I-D Action: draft-ietf-behave-nat64-discovery-heuristic-04.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 08:35:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Behavior Engineering for Hindrance Av= oidance Working Group of the IETF. Title : Discovery of a Network-Specific NAT64 Prefix using a Wel= l-Known Name Author(s) : Teemu Savolainen Jouni Korhonen Filename : draft-ietf-behave-nat64-discovery-heuristic-04.txt Pages : 10 Date : 2011-12-20 This document describes a method for detecting presence of DNS64 and for learning IPv6 prefix used for protocol translation on an access network without explicit support from the access network. The method depends on existence of a well-known IPv4-only domain name "ipv4only.arpa". The information learned enables applications and hosts to perform local IPv6 address synthesis and on dual-stack accesses avoid traversal through NAT64. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-nat64-discovery-heuri= stic-04.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-nat64-discovery-heuris= tic-04.txt From teemu.savolainen@nokia.com Tue Dec 20 00:43:03 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5169C21F8AFA for ; Tue, 20 Dec 2011 00:43:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AUAkLReotfG4 for ; Tue, 20 Dec 2011 00:43:02 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id A1EB721F8AF7 for ; Tue, 20 Dec 2011 00:43:02 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id pBK8gxhv011595 for ; Tue, 20 Dec 2011 10:43:00 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.56]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Dec 2011 10:42:58 +0200 Received: from 008-AM1MPN1-053.mgdnok.nokia.com ([169.254.3.196]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.01.0355.003; Tue, 20 Dec 2011 09:42:57 +0100 From: To: Thread-Topic: [BEHAVE] I-D Action: draft-ietf-behave-nat64-discovery-heuristic-04.txt Thread-Index: AQHMvvLWhdTfxWfW7kuAlM3v0JSeMpXkZ+Nw Date: Tue, 20 Dec 2011 08:42:57 +0000 Message-ID: <916CE6CF87173740BC8A2CE443096962042A5389@008-AM1MPN1-053.mgdnok.nokia.com> References: <20111220083539.23539.13400.idtracker@ietfa.amsl.com> In-Reply-To: <20111220083539.23539.13400.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Company Confidential;Project=None; x-titus-version: 3.3.8.1 x-headerinfofordlp: None x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7IiK+ntKbo4xPTApCTPxRn9Xp0LtY+cpSPQLNR71P2TG4kgg0XOW5vk1ilxPAk1qHuq6hNFWU6OECc3tPiMkO+UZqbpNZKDBYOw6mwtrRUOqURqfYHrl7zDlkQY38e0JxQTPjdPYKxRy+y8y1eMcSkXJ+oPoPsN/4TvIpr312KBlnKgxG7V15ExrBP7tPpQK5Y6S+yOZzg8xmoeX9WSEW3bqFg3l+YDBEFpPULzPyOVnTQT7ejnMUJDTCOCFT4nw6gbHFJfPyNsFTqxrL7tV1nTU= x-originating-ip: [10.162.89.107] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 20 Dec 2011 08:42:58.0970 (UTC) FILETIME=[605957A0:01CCBEF3] X-Nokia-AV: Clean Subject: Re: [BEHAVE] I-D Action: draft-ietf-behave-nat64-discovery-heuristic-04.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 08:43:03 -0000 Hi all, Here is a revision that uses "ipv4only.arpa" as the well-known IPv4-only do= main name and introduces text for secure NAT64 prefix discovery (section 3.= 1), which is essentially what Dan has proposed earlier. The discovery text = also notes there could be multiple prefixes in use, and hence there could b= e one or more AAAA records per one or more NAT64 FQDN. Also some clarifications here and there. Best regards, Teemu > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf > Of ext internet-drafts@ietf.org > Sent: 20. joulukuuta 2011 10:36 > To: i-d-announce@ietf.org > Cc: behave@ietf.org > Subject: [BEHAVE] I-D Action: draft-ietf-behave-nat64-discovery-heuristic= - > 04.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Behavior Engineering for Hindrance Avoid= ance > Working Group of the IETF. > > Title : Discovery of a Network-Specific NAT64 Prefix usin= g a Well- > Known Name > Author(s) : Teemu Savolainen > Jouni Korhonen > Filename : draft-ietf-behave-nat64-discovery-heuristic-04.tx= t > Pages : 10 > Date : 2011-12-20 > > This document describes a method for detecting presence of DNS64 and > for learning IPv6 prefix used for protocol translation on an access > network without explicit support from the access network. The method > depends on existence of a well-known IPv4-only domain name > "ipv4only.arpa". The information learned enables applications and > hosts to perform local IPv6 address synthesis and on dual-stack > accesses avoid traversal through NAT64. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-behave-nat64-discovery- > heuristic-04.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-nat64-discovery-heur= istic- > 04.txt > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From john@selbie.com Thu Dec 22 13:17:14 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0378621F84DF for ; Thu, 22 Dec 2011 13:17:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.213 X-Spam-Level: X-Spam-Status: No, score=-1.213 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MISSING_SUBJECT=1.762, RCVD_IN_DNSWL_LOW=-1, WEIRD_PORT=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nZS5R-gY7Pz0 for ; Thu, 22 Dec 2011 13:17:13 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3DD9B21F84DD for ; Thu, 22 Dec 2011 13:17:13 -0800 (PST) Received: by qcsf15 with SMTP id f15so6446280qcs.31 for ; Thu, 22 Dec 2011 13:17:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.188.137 with SMTP id da9mr9472802qab.29.1324588631394; Thu, 22 Dec 2011 13:17:11 -0800 (PST) Received: by 10.229.223.194 with HTTP; Thu, 22 Dec 2011 13:17:11 -0800 (PST) Date: Thu, 22 Dec 2011 13:17:11 -0800 Message-ID: From: John Selbie To: behave@ietf.org Content-Type: multipart/alternative; boundary=20cf303349afd90b4704b4b4d2e2 Subject: [BEHAVE] (no subject) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 21:17:14 -0000 --20cf303349afd90b4704b4b4d2e2 Content-Type: text/plain; charset=ISO-8859-1 In regards to the NAT mapping test described in RFC 5780, section 4.3. If I read the RFC correctly: Test 1 - binding request to Primary IP and Primary Port ( stun1.mydomain.com:3478) If no NAT detected, then stop, otherwise perform test 2. Test 2 - binding request to Alternate IP and Primary Port ( stun2.mydomain.com:3478) If port mapping from test 1 is the same, then infer "endpoint-indepenent", otherwise test 3 Test 3 - binding request to Alternate IP and Alternate Port ( stun2.mydomain.com:3479) Infer either "address dependent" or "address+port dependent" mapping based on result I am curious about this. But it seems like if test 2 and test 3 should be swapped. Such that test 2 was the one that hits the alternate port on the alternate IP. And if the result was the same as test 1, then that would be more reliable to infer "endpoint independent" mapping than just comparing the two test results against identical port numbers on different IPs. Otherwise, as the test sequence stands now, it implies that there could never be "port dependent mapping". Thoughts? John Selbie 4.3. Determining NAT Mapping Behavior This will require at most three tests. In test I, the client performs the UDP connectivity test. The server will return its alternate address and port in OTHER-ADDRESS in the binding response. If OTHER-ADDRESS is not returned, the server does not support this usage and this test cannot be run. The client examines the XOR- MAPPED-ADDRESS attribute. If this address and port are the same as the local IP address and port of the socket used to send the request, the client knows that it is not NATed and the effective mapping will be Endpoint-Independent. In test II, the client sends a Binding Request to the alternate address, but primary port. If the XOR-MAPPED-ADDRESS in the Binding Response is the same as test I the NAT currently has Endpoint- Independent Mapping. If not, test III is performed: the client sends a Binding Request to the alternate address and port. If the XOR- MAPPED-ADDRESS matches test II, the NAT currently has Address- Dependent Mapping; if it doesn't match it currently has Address and Port-Dependent Mapping. --20cf303349afd90b4704b4b4d2e2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable In regards to the NAT mapping test described in RFC 5780, section 4.3.
<= br>If I read the RFC correctly:

Test 1 - binding request to Primary = IP and Primary Port (stun1.mydom= ain.com:3478)
If no NAT detected, then stop, otherwise perform test 2.

Test 2 - bi= nding request to Alternate IP and Primary Port (stun2.mydomain.com:3478)
If port mapping from test 1= is the same, then infer "endpoint-indepenent", otherwise test 3<= br>
Test 3 - binding request to Alternate IP and Alternate Port (stun2.mydomain.com:3479)
=A0=A0 Inf= er either "address dependent" or "address+port dependent&quo= t; mapping based on result

I am curious about this.=A0 But it seems like if test 2 and test 3 shou= ld be swapped. Such that test 2 was the one that hits the alternate port on= the alternate IP.=A0 And if the result was the same as test 1, then that w= ould be more reliable to infer "endpoint independent" mapping tha= n just comparing the two test results against identical port numbers on dif= ferent IPs.=A0

Otherwise, as the test sequence stands now, it implies that there could= never be "port dependent mapping".

Thoughts?

John = Selbie



4.3.=A0 Determining NAT Mapping Behavior

=A0= =A0 This will require at most three tests.=A0 In test I, the client
=A0=A0 performs the UDP connectivity test.=A0 The server will return its=A0=A0 alternate address and port in OTHER-ADDRESS in the binding response= .
=A0=A0 If OTHER-ADDRESS is not returned, the server does not support t= his
=A0=A0 usage and this test cannot be run.=A0 The client examines the= XOR-
=A0=A0 MAPPED-ADDRESS attribute.=A0 If this address and port are the same a= s
=A0=A0 the local IP address and port of the socket used to send the re= quest,
=A0=A0 the client knows that it is not NATed and the effective ma= pping will
=A0=A0 be Endpoint-Independent.

=A0=A0 In test II, the client sends = a Binding Request to the alternate
=A0=A0 address, but primary port.=A0 = If the XOR-MAPPED-ADDRESS in the Binding
=A0=A0 Response is the same as = test I the NAT currently has Endpoint-
=A0=A0 Independent Mapping.=A0 If not, test III is performed: the client se= nds
=A0=A0 a Binding Request to the alternate address and port.=A0 If th= e XOR-
=A0=A0 MAPPED-ADDRESS matches test II, the NAT currently has Addr= ess-
=A0=A0 Dependent Mapping; if it doesn't match it currently has = Address and
=A0=A0 Port-Dependent Mapping.
--20cf303349afd90b4704b4b4d2e2-- From john@selbie.com Thu Dec 22 13:20:59 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA9C611E8095 for ; Thu, 22 Dec 2011 13:20:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.094 X-Spam-Level: X-Spam-Status: No, score=-2.094 tagged_above=-999 required=5 tests=[AWL=0.881, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, WEIRD_PORT=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b9m+ZZNsk4eu for ; Thu, 22 Dec 2011 13:20:59 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id CEF2011E8089 for ; Thu, 22 Dec 2011 13:20:58 -0800 (PST) Received: by qcsf15 with SMTP id f15so6448034qcs.31 for ; Thu, 22 Dec 2011 13:20:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.136.85 with SMTP id q21mr4852289qct.24.1324588858335; Thu, 22 Dec 2011 13:20:58 -0800 (PST) Received: by 10.229.223.194 with HTTP; Thu, 22 Dec 2011 13:20:58 -0800 (PST) Date: Thu, 22 Dec 2011 13:20:58 -0800 Message-ID: From: John Selbie To: behave@ietf.org Content-Type: multipart/alternative; boundary=00248c768dc65fe02c04b4b4e0ab Subject: [BEHAVE] RFC 5780 - Order of mapping tests X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 21:20:59 -0000 --00248c768dc65fe02c04b4b4e0ab Content-Type: text/plain; charset=ISO-8859-1 In regards to the NAT mapping test described in RFC 5780, section 4.3. If I read the RFC correctly: Test 1 - binding request to Primary IP and Primary Port ( stun1.mydomain.com:3478) If no NAT detected, then stop, otherwise perform test 2. Test 2 - binding request to Alternate IP and Primary Port ( stun2.mydomain.com:3478) If port mapping from test 1 is the same, then infer "endpoint-indepenent", otherwise test 3 Test 3 - binding request to Alternate IP and Alternate Port ( stun2.mydomain.com:3479) Infer either "address dependent" or "address+port dependent" mapping based on result I am curious about this. But it seems like if test 2 and test 3 should be swapped. Such that test 2 was the one that hits the alternate port on the alternate IP. And if the result was the same as test 1, then that would be more reliable to infer "endpoint independent" mapping than just comparing the two test results against identical port numbers on different IPs. Otherwise, as the test sequence stands now, it implies that there could never be "port dependent mapping". Thoughts? John Selbie 4.3. Determining NAT Mapping Behavior This will require at most three tests. In test I, the client performs the UDP connectivity test. The server will return its alternate address and port in OTHER-ADDRESS in the binding response. If OTHER-ADDRESS is not returned, the server does not support this usage and this test cannot be run. The client examines the XOR- MAPPED-ADDRESS attribute. If this address and port are the same as the local IP address and port of the socket used to send the request, the client knows that it is not NATed and the effective mapping will be Endpoint-Independent. In test II, the client sends a Binding Request to the alternate address, but primary port. If the XOR-MAPPED-ADDRESS in the Binding Response is the same as test I the NAT currently has Endpoint- Independent Mapping. If not, test III is performed: the client sends a Binding Request to the alternate address and port. If the XOR- MAPPED-ADDRESS matches test II, the NAT currently has Address- Dependent Mapping; if it doesn't match it currently has Address and Port-Dependent Mapping. --00248c768dc65fe02c04b4b4e0ab Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <adding subject header - sorry for dupe>

In regards to the NAT= mapping test described in RFC 5780, section 4.3.

If I read the RFC = correctly:

Test 1 - binding request to Primary IP and Primary Port (= stun1.mydomai= n.com:3478)
If no NAT detected, then stop, otherwise perform test 2.

Test 2 - bi= nding request to Alternate IP and Primary Port (stun2.mydomain.com:3478)
If port = mapping from test 1 is the same, then infer "endpoint-indepenent"= , otherwise test 3

Test 3 - binding request to Alternate IP and Alternate Port (stun2.mydomain.com:3479= )
=A0=A0 Infer either "address dependent" or "address= +port dependent" mapping based on result

I am curious about this.=A0 But it seems like if test 2 and test 3=20 should be swapped. Such that test 2 was the one that hits the alternate=20 port on the alternate IP.=A0 And if the result was the same as test 1,=20 then that would be more reliable to infer "endpoint independent" = mapping than just comparing the two test results against identical port numbers on different IPs.=A0

Otherwise, as the test sequence stands now, it implies that there could= never be "port dependent mapping".

Thoughts?

John = Selbie

4.3.=A0 Determining NAT Mapping Behavior

=A0=A0 This w= ill require at most three tests.=A0 In test I, the client
=A0=A0 performs the UDP connectivity test.=A0 The server will return its=A0=A0 alternate address and port in OTHER-ADDRESS in the binding response= .
=A0=A0 If OTHER-ADDRESS is not returned, the server does not support t= his
=A0=A0 usage and this test cannot be run.=A0 The client examines the= XOR-
=A0=A0 MAPPED-ADDRESS attribute.=A0 If this address and port are the same a= s
=A0=A0 the local IP address and port of the socket used to send the re= quest,
=A0=A0 the client knows that it is not NATed and the effective ma= pping will
=A0=A0 be Endpoint-Independent.

=A0=A0 In test II, the client sends = a Binding Request to the alternate
=A0=A0 address, but primary port.=A0 = If the XOR-MAPPED-ADDRESS in the Binding
=A0=A0 Response is the same as = test I the NAT currently has Endpoint-
=A0=A0 Independent Mapping.=A0 If not, test III is performed: the client se= nds
=A0=A0 a Binding Request to the alternate address and port.=A0 If th= e XOR-
=A0=A0 MAPPED-ADDRESS matches test II, the NAT currently has Addr= ess-
=A0=A0 Dependent Mapping; if it doesn't match it currently has = Address and
=A0=A0 Port-Dependent Mapping.


--00248c768dc65fe02c04b4b4e0ab-- From internet-drafts@ietf.org Thu Dec 22 23:23:43 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 365E111E80F4; Thu, 22 Dec 2011 23:23:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e7hxqxKcB6eB; Thu, 22 Dec 2011 23:23:42 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C792211E80EB; Thu, 22 Dec 2011 23:23:42 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20111223072342.8172.70568.idtracker@ietfa.amsl.com> Date: Thu, 22 Dec 2011 23:23:42 -0800 Cc: behave@ietf.org Subject: [BEHAVE] I-D Action: draft-ietf-behave-v4v6-bih-08.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 07:23:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Behavior Engineering for Hindrance Av= oidance 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 From teemu.savolainen@nokia.com Thu Dec 22 23:31:47 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDC6B21F88B7 for ; Thu, 22 Dec 2011 23:31:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a4hfVITBGqgv for ; Thu, 22 Dec 2011 23:31:47 -0800 (PST) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 0F36821F84A9 for ; Thu, 22 Dec 2011 23:31:46 -0800 (PST) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-sa01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id pBN7VjID025387 for ; Fri, 23 Dec 2011 09:31:45 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.59]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 23 Dec 2011 09:31:44 +0200 Received: from 008-AM1MPN1-053.mgdnok.nokia.com ([169.254.3.196]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi id 14.01.0355.003; Fri, 23 Dec 2011 08:31:44 +0100 From: To: Thread-Topic: Changes on draft-ietf-behave-v4v6-bih-08.txt Thread-Index: AczBRGjS/q4k0O65RVKs+/X8gY+4Lg== Date: Fri, 23 Dec 2011 07:31:43 +0000 Message-ID: <916CE6CF87173740BC8A2CE443096962042A7E0B@008-AM1MPN1-053.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Company Confidential;Project=None; x-titus-version: 3.3.8.1 x-headerinfofordlp: None x-tituslabs-classificationhash-30: wMRUUUZB6NdpUEshuhzL9ZF3CvSbb1GZBwS8kjSBDuFndY1xGfJ1TxW3drE+ewYAEyd+oHFo2rr/MSm/1UvoSiOBKFTQYVZxQxmd8+JmOvn92hErpQ7o53IVtntRMsaon89vJJFPvLOpoH5vqKRvoCydHJVr4kqUMlZMGO5v8Wn1S14knvoOQo/h5oiD4DmIcCRhodbSTmXrv8KgougZU8EJYy4hQ0MY2B0J9I5gUshe+4GErJMne+PL10mEohwR x-originating-ip: [10.162.89.107] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 23 Dec 2011 07:31:44.0888 (UTC) FILETIME=[EC096F80:01CCC144] X-Nokia-AV: Clean Subject: [BEHAVE] Changes on draft-ietf-behave-v4v6-bih-08.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 07:31:48 -0000 Behave WG, A new revision of BIH was made to respond to comments given by IESG. In add= ition to some clarifications best seen in diff (http://tools.ietf.org/rfcdi= ff?url2=3Ddraft-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 explic= it negative response on the A record lookup, or can it synthesize from the AAAA in othe= r 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 positiv= e AAAA response, the ENR MAY choose to proceed as if there were only AAAA r= ecord available for the destination. -- Any comments? Best regards, Teemu -----Original Message----- From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of= ext internet-drafts@ietf.org Sent: 23. joulukuuta 2011 09:24 To: i-d-announce@ietf.org Cc: behave@ietf.org Subject: [BEHAVE] I-D Action: draft-ietf-behave-v4v6-bih-08.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Behavior Engineering for Hindrance Av= oidance 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 Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From internet-drafts@ietf.org Thu Dec 22 23:33:12 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E328011E80F7; Thu, 22 Dec 2011 23:33:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GIYAnIl79wC0; Thu, 22 Dec 2011 23:33:12 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C2D311E80EE; Thu, 22 Dec 2011 23:33:12 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20111223073312.11000.35808.idtracker@ietfa.amsl.com> Date: Thu, 22 Dec 2011 23:33:12 -0800 Cc: behave@ietf.org Subject: [BEHAVE] I-D Action: draft-ietf-behave-64-analysis-05.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 07:33:13 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Behavior Engineering for Hindrance Av= oidance Working Group of the IETF. Title : Analysis of Stateful 64 Translation Author(s) : Reinaldo Penno Tarun Saxena Mohamed Boucadair Senthil Sivakumar Filename : draft-ietf-behave-64-analysis-05.txt Pages : 15 Date : 2011-12-22 Due to specific problems, NAT-PT was deprecated by the IETF as a mechanism to perform IPv6-IPv4 translation. Since then, new efforts have been undertaken within IETF to standardize alternative mechanisms to perform IPv6-IPv4 translation. This document evaluates how the new stateful translation mechanisms avoid the problems that caused the IETF to deprecate NAT-PT. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-64-analysis-05.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-64-analysis-05.txt From wwwrun@rfc-editor.org Fri Dec 23 03:13:43 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF83021F8B24 for ; Fri, 23 Dec 2011 03:13:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.36 X-Spam-Level: X-Spam-Status: No, score=-102.36 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A602aprBSix8 for ; Fri, 23 Dec 2011 03:13:43 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 7CFA421F8B2A for ; Fri, 23 Dec 2011 03:13:43 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 728FB72E002; Fri, 23 Dec 2011 03:12:13 -0800 (PST) To: xing@cernet.edu.cn, congxiao@cernet.edu.cn, fred@cisco.com, ietfdbh@comcast.net, wes@mti-systems.com, dthaler@microsoft.com, dwing@cisco.com From: RFC Errata System Message-Id: <20111223111213.728FB72E002@rfc-editor.org> Date: Fri, 23 Dec 2011 03:12:13 -0800 (PST) Cc: gandhar.gokhale@lsi.com, behave@ietf.org, rfc-editor@rfc-editor.org Subject: [BEHAVE] [Technical Errata Reported] RFC6145 (3059) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 11:13:44 -0000 The following errata report has been submitted for RFC6145, "IP/ICMP Translation Algorithm". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6145&eid=3059 -------------------------------------- Type: Technical Reported by: Gandhar Gokhale Section: 5.1 Original Text ------------- Corrected Text -------------- If any of an IPv6 Hop-by-Hop Options header, Destination Options header, or Routing header with the Segments Left field equal to zero are present in the IPv6 packet, those IPv6 extension headers MUST be ignored (i.e., there is no attempt to translate the extension headers) and the packet translated normally. However, the Total Length field and the Protocol field are adjusted to "skip" these extension headers. Notes ----- Since the extension headers shall be removed from the packet while translating to IPv4 the translator should deduct from IPv4 Total Length the length of all the extension headers present in the original IPv6 packet except ESP header (in transport mode). AH is not supposed to be translated. RFC 2765 had explicitly stated this and RFC 6145 also should continue to have this stated. Copied the correction text from RFC 2765. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6145 (draft-ietf-behave-v6v4-xlate-23) -------------------------------------- Title : IP/ICMP Translation Algorithm Publication Date : April 2011 Author(s) : X. Li, C. Bao, F. Baker Category : PROPOSED STANDARD Source : Behavior Engineering for Hindrance Avoidance Area : Transport Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Fri Dec 23 03:19:12 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F7B121F8B2B for ; Fri, 23 Dec 2011 03:19:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.375 X-Spam-Level: X-Spam-Status: No, score=-102.375 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PM+YT96SRjje for ; Fri, 23 Dec 2011 03:19:11 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id E369E21F8B0F for ; Fri, 23 Dec 2011 03:19:11 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id D7E6372E004; Fri, 23 Dec 2011 03:17:41 -0800 (PST) To: xing@cernet.edu.cn, congxiao@cernet.edu.cn, fred@cisco.com, ietfdbh@comcast.net, wes@mti-systems.com, dthaler@microsoft.com, dwing@cisco.com From: RFC Errata System Message-Id: <20111223111741.D7E6372E004@rfc-editor.org> Date: Fri, 23 Dec 2011 03:17:41 -0800 (PST) Cc: gandhar.gokhale@lsi.com, behave@ietf.org, rfc-editor@rfc-editor.org Subject: [BEHAVE] [Technical Errata Reported] RFC6145 (3060) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 11:19:12 -0000 The following errata report has been submitted for RFC6145, "IP/ICMP Translation Algorithm". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6145&eid=3060 -------------------------------------- Type: Technical Reported by: Gandhar Gokhale Section: 5.1.1 Original Text ------------- Total Length: Payload length value from IPv6 header, minus 8 for the Fragment Header, plus the size of the IPv4 header. Corrected Text -------------- Total Length: If the Next Header field of the Fragment Header is not an extension header (except ESP) then Total Length MUST be set to Payload Length value from IPv6 header, minus length of extension headers up to Fragmentation Header, minus 8 for the Fragment Header, plus the size of the IPv4 header. If the Next Header field of the Fragment Header is an extension header (except ESP) then the packet SHOULD be dropped and logged. Notes ----- If the fragmentable part (as described in RFC 2460) of the original unfragmented IPv6 packet had extension headers then the translator can not calculate the total length of the IPv4 fragment for non-initial fragments. In case of initial fragment also, only if all the extension headers of the fragmentable part are contained within the initial fragment itself then translator can know of how much length to deduct from the total length. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6145 (draft-ietf-behave-v6v4-xlate-23) -------------------------------------- Title : IP/ICMP Translation Algorithm Publication Date : April 2011 Author(s) : X. Li, C. Bao, F. Baker Category : PROPOSED STANDARD Source : Behavior Engineering for Hindrance Avoidance Area : Transport Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Fri Dec 23 03:21:19 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A0AB21F8B2B for ; Fri, 23 Dec 2011 03:21:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.388 X-Spam-Level: X-Spam-Status: No, score=-102.388 tagged_above=-999 required=5 tests=[AWL=0.212, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lS3breR3UBF5 for ; Fri, 23 Dec 2011 03:21:18 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id A65F321F8B0F for ; Fri, 23 Dec 2011 03:21:18 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 9759872E008; Fri, 23 Dec 2011 03:19:47 -0800 (PST) To: xing@cernet.edu.cn, congxiao@cernet.edu.cn, fred@cisco.com, ietfdbh@comcast.net, wes@mti-systems.com, dthaler@microsoft.com, dwing@cisco.com From: RFC Errata System Message-Id: <20111223111948.9759872E008@rfc-editor.org> Date: Fri, 23 Dec 2011 03:19:47 -0800 (PST) Cc: gandhar.gokhale@lsi.com, behave@ietf.org, rfc-editor@rfc-editor.org Subject: [BEHAVE] [Technical Errata Reported] RFC6145 (3061) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 11:21:19 -0000 The following errata report has been submitted for RFC6145, "IP/ICMP Translation Algorithm". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6145&eid=3061 -------------------------------------- Type: Technical Reported by: Gandhar Gokhale Section: 5.1.1 Original Text ------------- Fragment Offset: Copied from the Fragment Offset field of the IPv6 Fragment Header. Corrected Text -------------- Fragment Offset: If the Next Header field of the Fragment Header is not an extension header (except ESP) then Fragment Offset MUST be copied from the Fragment Offset field of the IPv6 Fragment Header. If the Next Header field of the Fragment Header is an extension header (except ESP) then the packet SHOULD be dropped and logged. Notes ----- If the fragmentable part (as described in RFC 2460) of the original unfragmented IPv6 packet had extension headers then the translator can not calculate the offset of the IPv4 fragment for non-initial fragments. If extension headers are present in the fragmentable part then the fragment offset value of the IPv6 header includes length of the extension headers also. Since translator strips of the IPv6 extension headers the fragment offset value set by the sender of IPv6 fragments can not match that received by the IPv4 receiver and the reassembly will fail. For non-initial fragments the translator does not have the knowledge of this delta when there is no state maintained. The legth issue stated in erratum 2 is not in itself sufficient to advocate packet drop. However, the offset issue is sufficient to advocate packet drop as the reassembly is bound to fail. Therefore I'm putting a SHOULD in both cases. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6145 (draft-ietf-behave-v6v4-xlate-23) -------------------------------------- Title : IP/ICMP Translation Algorithm Publication Date : April 2011 Author(s) : X. Li, C. Bao, F. Baker Category : PROPOSED STANDARD Source : Behavior Engineering for Hindrance Avoidance Area : Transport Stream : IETF Verifying Party : IESG From cb.list6@gmail.com Fri Dec 23 04:06:51 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEFC221F8B5E for ; Fri, 23 Dec 2011 04:06:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qak9NdAnBjJ4 for ; Fri, 23 Dec 2011 04:06:49 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4DFCD21F8B55 for ; Fri, 23 Dec 2011 04:06:49 -0800 (PST) Received: by dajz8 with SMTP id z8so8654350daj.31 for ; Fri, 23 Dec 2011 04:06:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wmtZw6PDUg2oZ7Eb/TaFyIsqDJo+9bUbVxzPGluxfoA=; b=mw/zi+R+uS+1EI96ZQ7KoZAOxokbC+mTlNyEwzXbOtVvwCEanOkRnUn+/RjOrbiMQi 9vuwhzPWPhiKzAgOOlay+O9ZFbZze9VLU+nMuuFcUnq98qepaRwS5i7BdQ1wnKNxB7aS CjfEGX1deUbCXsYP4+NLgeuYwZ6gpJ4/lr7tw= MIME-Version: 1.0 Received: by 10.68.189.170 with SMTP id gj10mr21875280pbc.16.1324642008991; Fri, 23 Dec 2011 04:06:48 -0800 (PST) Received: by 10.143.67.21 with HTTP; Fri, 23 Dec 2011 04:06:48 -0800 (PST) Received: by 10.143.67.21 with HTTP; Fri, 23 Dec 2011 04:06:48 -0800 (PST) In-Reply-To: <916CE6CF87173740BC8A2CE443096962042A7E0B@008-AM1MPN1-053.mgdnok.nokia.com> References: <916CE6CF87173740BC8A2CE443096962042A7E0B@008-AM1MPN1-053.mgdnok.nokia.com> Date: Fri, 23 Dec 2011 04:06:48 -0800 Message-ID: From: Cameron Byrne To: teemu.savolainen@nokia.com Content-Type: multipart/alternative; boundary=e89a8ff1cc1c6689e004b4c140aa Cc: behave@ietf.org Subject: Re: [BEHAVE] Changes on draft-ietf-behave-v4v6-bih-08.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 12:06:51 -0000 --e89a8ff1cc1c6689e004b4c140aa Content-Type: text/plain; charset=ISO-8859-1 On Dec 23, 2011 2:31 AM, 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: > - 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. > -- > Do you have any data to support 300ms? My concern is the highly latent wireless networks will not work best with 300 ms. Cb > Any comments? > > Best regards, > > Teemu > > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of ext internet-drafts@ietf.org > Sent: 23. joulukuuta 2011 09:24 > To: i-d-announce@ietf.org > Cc: behave@ietf.org > 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 > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave --e89a8ff1cc1c6689e004b4c140aa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Dec 23, 2011 2:31 AM, <= teemu.savolainen@nokia.com> wrote:
>
> Behave WG,
>
> A new revision of BIH was made to respond to comments given by IESG. I= n addition to some clarifications best seen in diff (http://tools.ietf.= org/rfcdiff?url2=3Ddraft-ietf-behave-v4v6-bih-08), the main changes wer= e:
> - Introduction of 1.1 Terminology section
> - Significantly revising section 8. =A0Changes since RFC2767 and RFC33= 38
>
> 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 foll= owing text was added:
> --
> If no reply for A query is received after 300 ms since reception of po= sitive AAAA response, the ENR MAY choose to proceed as if there were only A= AAA record available for the destination.
> --
>

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

Cb

> Any comments?
>
> Best regards,
>
> =A0 =A0 =A0 =A0Teemu
>
> -----Original Message-----
> From: behave-bounces@ietf.o= rg [mailto:behave-bounces@ie= tf.org] On Behalf Of ext in= ternet-drafts@ietf.org
> Sent: 23. joulukuuta 2011 09:24
> To: i-d-announce@ietf.org=
> Cc: behave@ietf.org
> Subject: [BEHAVE] I-D Action: draft-ietf-behave-v4v6-bih-08.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories. This draft is a work item of the Behavior Engineering for Hindran= ce Avoidance Working Group of the IETF.
>
> =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Dual Stack Hosts Using &quo= t;Bump-in-the-Host" (BIH)
> =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Bill Huang
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Hui Deng
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Teemu Savolainen > =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-behave-v4v6-bih-08= .txt
> =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 29
> =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-12-22
>
> =A0 Bump-In-the-Host (BIH) is a host-based IPv4 to IPv6 protocol
> =A0 translation mechanism that allows a class of IPv4-only application= s
> =A0 that work through NATs to communicate with IPv6-only peers. =A0The= host
> =A0 on which applications are running may be connected to IPv6-only or=
> =A0 dual-stack access networks. =A0BIH hides IPv6 and makes the IPv4-o= nly
> =A0 applications think they are talking with IPv4 peers by local
> =A0 synthesis of IPv4 addresses. =A0This document obsoletes RFC 2767 a= nd
> =A0 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/int= ernet-drafts/
>
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-behave-v4v6-bih-08= .txt
>
> _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www.i= etf.org/mailman/listinfo/behave
> _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www.i= etf.org/mailman/listinfo/behave

--e89a8ff1cc1c6689e004b4c140aa-- From teemu.savolainen@nokia.com Fri Dec 23 04:57:58 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05A2A21F8B5A for ; Fri, 23 Dec 2011 04:57:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ae5jtU3ilsgv for ; Fri, 23 Dec 2011 04:57:57 -0800 (PST) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id 9199E21F8513 for ; Fri, 23 Dec 2011 04:57:56 -0800 (PST) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-sa02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id pBNCvr5f021172; Fri, 23 Dec 2011 14:57:54 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.25]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 23 Dec 2011 14:57:53 +0200 Received: from 008-AM1MPN1-053.mgdnok.nokia.com ([169.254.3.196]) by 008-AM1MMR1-009.mgdnok.nokia.com ([65.54.30.25]) with mapi id 14.01.0355.003; Fri, 23 Dec 2011 13:57:53 +0100 From: To: Thread-Topic: [BEHAVE] Changes on draft-ietf-behave-v4v6-bih-08.txt Thread-Index: AczBRGjS/q4k0O65RVKs+/X8gY+4LgAHo4QAAAO1Nbw= Date: Fri, 23 Dec 2011 12:57:52 +0000 Message-ID: <916CE6CF87173740BC8A2CE443096962042A8187@008-AM1MPN1-053.mgdnok.nokia.com> References: <916CE6CF87173740BC8A2CE443096962042A7E0B@008-AM1MPN1-053.mgdnok.nokia.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [88.115.224.28] Content-Type: multipart/alternative; boundary="_000_916CE6CF87173740BC8A2CE443096962042A8187008AM1MPN1053mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 23 Dec 2011 12:57:53.0294 (UTC) FILETIME=[7BB73AE0:01CCC172] X-Nokia-AV: Clean Cc: behave@ietf.org Subject: Re: [BEHAVE] Changes on draft-ietf-behave-v4v6-bih-08.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 12:57:58 -0000 --_000_916CE6CF87173740BC8A2CE443096962042A8187008AM1MPN1053mg_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The host should send A and AAAA in parallel, hence one would assume in usua= l case replies should arrive roughly at the same time. This 300ms is for di= fference 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 diff= erent thing. I was also considering reference to Happy Eyeballs draft: draf= t-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 r= eply for A query is received after ENR implementation specific timeout, aft= er 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 [cb.list6@gmail.com] Sent: Friday, December 23, 2011 2:06 PM To: Savolainen Teemu (Nokia-NRC/Tampere) Cc: behave@ietf.org Subject: Re: [BEHAVE] Changes on draft-ietf-behave-v4v6-bih-08.txt On Dec 23, 2011 2:31 AM, > wrote: > > Behave WG, > > A new revision of BIH was made to respond to comments given by IESG. In a= ddition to some clarifications best seen in diff (http://tools.ietf.org/rfc= diff?url2=3Ddraft-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 expl= icit negative > response on the A record lookup, or can it synthesize from the AAAA in ot= her > circumstances? Probably best to explicitly say so." For this following te= xt was added: > -- > If no reply for A query is received after 300 ms since reception of posit= ive 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 wir= eless networks will not work best with 300 ms. Cb > Any comments? > > Best regards, > > Teemu > > -----Original Message----- > From: behave-bounces@ietf.org [mailto:beh= ave-bounces@ietf.org] On Behalf Of ext inte= rnet-drafts@ietf.org > Sent: 23. joulukuuta 2011 09:24 > To: i-d-announce@ietf.org > Cc: behave@ietf.org > Subject: [BEHAVE] I-D Action: draft-ietf-behave-v4v6-bih-08.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. 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 > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave --_000_916CE6CF87173740BC8A2CE443096962042A8187008AM1MPN1053mg_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
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 se= nds queries in series, then it would be different thing. I was also conside= ring 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 [cb.list6@gmail.c= om]
Sent: Friday, December 23, 2011 2:06 PM
To: Savolainen Teemu (Nokia-NRC/Tampere)
Cc: behave@ietf.org
Subject: Re: [BEHAVE] Changes on draft-ietf-behave-v4v6-bih-08.txt


On Dec 23, 2011 2:31 AM, <teemu.savolainen@nokia.com> wrote:
>
> Behave WG,
>
> A new revision of BIH was made to respond to comments given by IESG. I= n addition to some clarifications best seen in diff (= http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-behave-v4v6-bih-08), the main changes were:
> - Introduction of 1.1 Terminology section
> - Significantly revising section 8.  Changes since RFC2767 and RF= C3338
>
> 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 foll= owing text was added:
> --
> If no reply for A query is received after 300 ms since reception of po= sitive AAAA response, the ENR MAY choose to proceed as if there were only A= AAA record available for the destination.
> --
>

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

Cb

> Any comments?
>
> Best regards,
>
>        Teemu
>
> -----Original Message-----
> From: beh= ave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of ext internet-draf= ts@ietf.org
> Sent: 23. joulukuuta 2011 09:24
> To: i-d-ann= ounce@ietf.org
> Cc: behave@ietf.o= rg
> Subject: [BEHAVE] I-D Action: draft-ietf-behave-v4v6-bih-08.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories. This draft is a work item of the Behavior Engineering for Hindran= ce 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           &nb= sp;: 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 applicat= ions
>   that work through NATs to communicate with IPv6-only peers. &nb= sp;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
> Behave@ietf.org
> https://www.ietf.org/mailman/listinfo/behave
> _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www.ietf.org/mailman/listinfo/behave

--_000_916CE6CF87173740BC8A2CE443096962042A8187008AM1MPN1053mg_-- From cb.list6@gmail.com Fri Dec 23 07:38:02 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5249C21F8B0B for ; Fri, 23 Dec 2011 07:38:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DFdL9hTXP3K4 for ; Fri, 23 Dec 2011 07:38:01 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 48FA121F8B11 for ; Fri, 23 Dec 2011 07:38:01 -0800 (PST) Received: by pbdd12 with SMTP id d12so7667951pbd.31 for ; Fri, 23 Dec 2011 07:38:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ooWGHjypHvc6iB2lkX1ZPDbNtw1aF114ZhausEnARN8=; b=oIykzIuALiJARz9nkjoZaNDSLlMN9dnkrKjbbLrEGfbASEgUphxP/HCAAuxnhArRcW wK2bXBYOoalrrdtO0iNudKQP20FuQHQnur/6SxGBk9O8q9Z04EkCo/YMonKYyZVr9biQ 6NX7NLQZKABgmNWN+dfxJbPsDIgOnEbERA6OI= MIME-Version: 1.0 Received: by 10.68.72.73 with SMTP id b9mr6215091pbv.67.1324654679638; Fri, 23 Dec 2011 07:37:59 -0800 (PST) Received: by 10.143.67.21 with HTTP; Fri, 23 Dec 2011 07:37:59 -0800 (PST) Received: by 10.143.67.21 with HTTP; Fri, 23 Dec 2011 07:37:59 -0800 (PST) In-Reply-To: <916CE6CF87173740BC8A2CE443096962042A8187@008-AM1MPN1-053.mgdnok.nokia.com> References: <916CE6CF87173740BC8A2CE443096962042A7E0B@008-AM1MPN1-053.mgdnok.nokia.com> <916CE6CF87173740BC8A2CE443096962042A8187@008-AM1MPN1-053.mgdnok.nokia.com> Date: Fri, 23 Dec 2011 07:37:59 -0800 Message-ID: From: Cameron Byrne To: teemu.savolainen@nokia.com Content-Type: multipart/alternative; boundary=f46d040f9b98a1415d04b4c43328 Cc: behave@ietf.org Subject: Re: [BEHAVE] Changes on draft-ietf-behave-v4v6-bih-08.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 15:38:02 -0000 --f46d040f9b98a1415d04b4c43328 Content-Type: text/plain; charset=ISO-8859-1 On Dec 23, 2011 7:57 AM, 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 > Best regards, > > Teemu > > ________________________________ > From: ext Cameron Byrne [cb.list6@gmail.com] > Sent: Friday, December 23, 2011 2:06 PM > To: Savolainen Teemu (Nokia-NRC/Tampere) > Cc: behave@ietf.org > Subject: Re: [BEHAVE] Changes on draft-ietf-behave-v4v6-bih-08.txt > > > On Dec 23, 2011 2:31 AM, 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: > > - 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. > > -- > > > > Do you have any data to support 300ms? My concern is the highly latent wireless networks will not work best with 300 ms. > > Cb > > > Any comments? > > > > Best regards, > > > > Teemu > > > > -----Original Message----- > > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of ext internet-drafts@ietf.org > > Sent: 23. joulukuuta 2011 09:24 > > To: i-d-announce@ietf.org > > Cc: behave@ietf.org > > 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 > > Behave@ietf.org > > https://www.ietf.org/mailman/listinfo/behave > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www.ietf.org/mailman/listinfo/behave --f46d040f9b98a1415d04b4c43328 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Dec 23, 2011 7:57 AM, <= teemu.savolainen@nokia.com> 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 f= or difference on reply arrival times and hence should not depend much on ac= cess 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:&qu= ot;If no reply for A query is received after ENR implementation specific ti= meout, after reception of positive AAAA response, the ENR MAY choose to pro= ceed 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 refres= hed separately.

Cb
> Best regards,
>
> Teemu
>
> ________________________________
> From: ext Cameron Byrne [cb.list= 6@gmail.com]
> Sent: Friday, December 23, 2011 2:06 PM
> To: Savolainen Teemu (Nokia-NRC/Tampere)
> Cc: behave@ietf.org
> Subject: Re: [BEHAVE] Changes on draft-ietf-behave-v4v6-bih-08.txt
>
>
> On Dec 23, 2011 2:31 AM, <teemu.savolainen@nokia.com> wrote:
> >
> > Behave WG,
> >
> > A new revision of BIH was made to respond to comments given by IE= SG. In addition to some clarifications best seen in diff (http://tools.= ietf.org/rfcdiff?url2=3Ddraft-ietf-behave-v4v6-bih-08), the main change= s were:
> > - Introduction of 1.1 Terminology section
> > - Significantly revising section 8. =A0Changes since RFC2767 and = RFC3338
> >
> > Then there was question from Pete Resnick: "MUST the ENR wai= t for an explicit negative
> > response on the A record lookup, or can it synthesize from the AA= AA 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 o= nly AAAA record available for the destination.
> > --
> >
>
> Do you have any data to support 300ms?=A0 My concern is the highly lat= ent wireless networks will not work best with 300 ms.
>
> Cb
>
> > Any comments?
> >
> > Best regards,
> >
> > =A0 =A0 =A0 =A0Teemu
> >
> > -----Original Message-----
> > From: behave-bounces@i= etf.org [mailto:behave-bounc= es@ietf.org] On Behalf Of ext internet-drafts@ietf.org
> > Sent: 23. joulukuuta 2011 09:24
> > To: i-d-announce@ietf.or= g
> > Cc: behave@ietf.org
> > Subject: [BEHAVE] I-D Action: draft-ietf-behave-v4v6-bih-08.txt > >
> >
> > A New Internet-Draft is available from the on-line Internet-Draft= s directories. This draft is a work item of the Behavior Engineering for Hi= ndrance Avoidance Working Group of the IETF.
> >
> > =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Dual Stack Hosts Using= "Bump-in-the-Host" (BIH)
> > =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Bill Huang
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Hui Deng
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Teemu Savolain= en
> > =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-behave-v4v6-b= ih-08.txt
> > =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 29
> > =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-12-22
> >
> > =A0 Bump-In-the-Host (BIH) is a host-based IPv4 to IPv6 protocol<= br> > > =A0 translation mechanism that allows a class of IPv4-only applic= ations
> > =A0 that work through NATs to communicate with IPv6-only peers. = =A0The host
> > =A0 on which applications are running may be connected to IPv6-on= ly or
> > =A0 dual-stack access networks. =A0BIH hides IPv6 and makes the I= Pv4-only
> > =A0 applications think they are talking with IPv4 peers by local<= br> > > =A0 synthesis of IPv4 addresses. =A0This document obsoletes RFC 2= 767 and
> > =A0 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.or= g/internet-drafts/
> >
> > This Internet-Draft can be retrieved at:
> > ftp://ftp.ietf.org/internet-drafts/draft-ietf-behave-v4v6-b= ih-08.txt
> >
> > _______________________________________________
> > Behave mailing list
> > Behave@ietf.org
> > https://= www.ietf.org/mailman/listinfo/behave
> > _______________________________________________
> > Behave mailing list
> > Behave@ietf.org
> > https://= www.ietf.org/mailman/listinfo/behave

--f46d040f9b98a1415d04b4c43328--