From mohamed.boucadair@orange.com Fri Jun 1 05:19:15 2012 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 8FF1511E815C for ; Fri, 1 Jun 2012 05:19:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=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 AVbhFMlIq+as for ; Fri, 1 Jun 2012 05:19:15 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 0889311E8132 for ; Fri, 1 Jun 2012 05:19:14 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id B0D622645D5; Fri, 1 Jun 2012 14:19:13 +0200 (CEST) Received: from PUEXCH11.nanterre.francetelecom.fr (unknown [10.101.44.27]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 94BBA27C05B; Fri, 1 Jun 2012 14:19:13 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH11.nanterre.francetelecom.fr ([10.101.44.27]) with mapi; Fri, 1 Jun 2012 14:19:13 +0200 From: To: Simon Perreault , Wesley Eddy Date: Fri, 1 Jun 2012 14:19:11 +0200 Thread-Topic: [BEHAVE] AD review of LSN requirements draft Thread-Index: Ac0/VHP+hOyjQF+1TveFDcs9FsuB3gAm4uNA Message-ID: <94C682931C08B048B7A8645303FDC9F36E2CB78A4F@PUEXCB1B.nanterre.francetelecom.fr> References: <4FC6F151.3080404@mti-systems.com> <4FC7ACE4.2010301@viagenie.ca> In-Reply-To: <4FC7ACE4.2010301@viagenie.ca> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.5.24.112414 Cc: "draft-ietf-behave-lsn-requirements.all@tools.ietf.org" , "behave@ietf.org" Subject: Re: [BEHAVE] AD review of LSN requirements draft 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, 01 Jun 2012 12:19:15 -0000 Hi Simon, all, =20 >-----Message d'origine----- >De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org]=20 >De la part de Simon Perreault >Envoy=E9 : jeudi 31 mai 2012 19:40 >=C0 : Wesley Eddy >Cc : draft-ietf-behave-lsn-requirements.all@tools.ietf.org;=20 >behave@ietf.org >Objet : Re: [BEHAVE] AD review of LSN requirements draft > > >> (6) I think it would be good to have an advisory >> reference to the issues in: >> http://tools.ietf.org/html/draft-donley-nat444-impacts-03 >> and whether or not following the recommendations in this >> document helps to avoid such issues. The RFC 6269 >> reference already in the introduction is okay, but it >> probably glosses over this topic too quickly. > >In addition to Dan's response, the draft-donley does not evaluate CGNs=20 >that have a PCP server, which our draft requires. I think the=20 >inclusion=20 >of PCP would affect the results significantly. Med: Agree. FWIW, an example of a detailed report for an application tested= in draft-donley-* is available at: http://tools.ietf.org/html/draft-boucad= air-pcp-bittorrent-00 (various combinations are tested including playing wi= th the configuration of the BT clients to allow multiple connections from t= he same IP).= From wes@mti-systems.com Fri Jun 1 05:41:19 2012 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 3274021F8AC7 for ; Fri, 1 Jun 2012 05:41:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 k8YyoKgyMwbS for ; Fri, 1 Jun 2012 05:41:18 -0700 (PDT) Received: from omr14.networksolutionsemail.com (omr14.networksolutionsemail.com [205.178.146.64]) by ietfa.amsl.com (Postfix) with ESMTP id B659521F8BD0 for ; Fri, 1 Jun 2012 05:41:16 -0700 (PDT) Received: from cm-omr11 (mail.networksolutionsemail.com [205.178.146.50]) by omr14.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q51CfGwr027452 for ; Fri, 1 Jun 2012 08:41:16 -0400 Authentication-Results: cm-omr11 smtp.user=wes@mti-systems.com; auth=pass (PLAIN) X-Authenticated-UID: wes@mti-systems.com Received: from [69.81.143.202] ([69.81.143.202:10002] helo=[192.168.1.106]) by cm-omr11 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 48/38-11548-B68B8CF4; Fri, 01 Jun 2012 08:41:16 -0400 Message-ID: <4FC8B865.3070001@mti-systems.com> Date: Fri, 01 Jun 2012 08:41:09 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: mohamed.boucadair@orange.com References: <4FC6F151.3080404@mti-systems.com> <4FC7ACE4.2010301@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E2CB78A4F@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E2CB78A4F@PUEXCB1B.nanterre.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: "draft-ietf-behave-lsn-requirements.all@tools.ietf.org" , "behave@ietf.org" Subject: Re: [BEHAVE] AD review of LSN requirements draft 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, 01 Jun 2012 12:41:19 -0000 On 6/1/2012 8:19 AM, mohamed.boucadair@orange.com wrote: > Hi Simon, all, > > >> -----Message d'origine----- >> De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] >> De la part de Simon Perreault >> Envoyé : jeudi 31 mai 2012 19:40 >> À : Wesley Eddy >> Cc : draft-ietf-behave-lsn-requirements.all@tools.ietf.org; >> behave@ietf.org >> Objet : Re: [BEHAVE] AD review of LSN requirements draft >> >> >>> (6) I think it would be good to have an advisory >>> reference to the issues in: >>> http://tools.ietf.org/html/draft-donley-nat444-impacts-03 >>> and whether or not following the recommendations in this >>> document helps to avoid such issues. The RFC 6269 >>> reference already in the introduction is okay, but it >>> probably glosses over this topic too quickly. >> >> In addition to Dan's response, the draft-donley does not evaluate CGNs >> that have a PCP server, which our draft requires. I think the >> inclusion >> of PCP would affect the results significantly. > > > Med: Agree. FWIW, an example of a detailed report for an application tested in draft-donley-* is available at: http://tools.ietf.org/html/draft-boucadair-pcp-bittorrent-00 (various combinations are tested including playing with the configuration of the BT clients to allow multiple connections from the same IP). > I think it would be great to add a sentence in the justification of the PCP requirement to specifically say that it's intended to improve on prior CGN implementations that did not include PCP and were found to have problems with certain applications (with citations). -- Wes Eddy MTI Systems From simon.perreault@viagenie.ca Fri Jun 1 06:00:34 2012 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 A32D411E86FD for ; Fri, 1 Jun 2012 06:00:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-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 6nNpANHpz52t for ; Fri, 1 Jun 2012 06:00:34 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 055B411E876E for ; Fri, 1 Jun 2012 06:00:13 -0700 (PDT) Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c064:d124:e508:53bd:2021]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 3674E41303; Fri, 1 Jun 2012 09:00:12 -0400 (EDT) Message-ID: <4FC8BCDB.3070408@viagenie.ca> Date: Fri, 01 Jun 2012 09:00:11 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1 MIME-Version: 1.0 To: Wesley Eddy References: <4FC6F151.3080404@mti-systems.com> <4FC7ACE4.2010301@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E2CB78A4F@PUEXCB1B.nanterre.francetelecom.fr> <4FC8B865.3070001@mti-systems.com> In-Reply-To: <4FC8B865.3070001@mti-systems.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "draft-ietf-behave-lsn-requirements.all@tools.ietf.org" , "behave@ietf.org" , mohamed.boucadair@orange.com Subject: Re: [BEHAVE] AD review of LSN requirements draft 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, 01 Jun 2012 13:00:34 -0000 On 2012-06-01 08:41, Wesley Eddy wrote: >>>> (6) I think it would be good to have an advisory reference to >>>> the issues in: >>>> http://tools.ietf.org/html/draft-donley-nat444-impacts-03 and >>>> whether or not following the recommendations in this document >>>> helps to avoid such issues. The RFC 6269 reference already in >>>> the introduction is okay, but it probably glosses over this >>>> topic too quickly. >>> >>> In addition to Dan's response, the draft-donley does not evaluate >>> CGNs that have a PCP server, which our draft requires. I think >>> the inclusion of PCP would affect the results significantly. >> >> Med: Agree. FWIW, an example of a detailed report for an >> application tested in draft-donley-* is available at: >> http://tools.ietf.org/html/draft-boucadair-pcp-bittorrent-00 >> (various combinations are tested including playing with the >> configuration of the BT clients to allow multiple connections from >> the same IP). > > I think it would be great to add a sentence in the justification of > the PCP requirement to specifically say that it's intended to improve > on prior CGN implementations that did not include PCP and were found > to have problems with certain applications (with citations). Makes sense. We had this: Justification: Allowing subscribers to manipulate the NAT state table with PCP greatly increases the likelihood that applications will function properly. I added this: A study of PCP-less CGN impacts can be found in [I-D.donley-nat444-impacts]. Another study considering the effects of PCP on a peer-to-peer file sharing protocol can be found in [I-D.boucadair-pcp-bittorrent]. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From simon.perreault@viagenie.ca Fri Jun 1 08:24:09 2012 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 A690511E8088 for ; Fri, 1 Jun 2012 08:24:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-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 Uu7GhlQQgjrP for ; Fri, 1 Jun 2012 08:24:08 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 6F07311E80FC for ; Fri, 1 Jun 2012 08:24:08 -0700 (PDT) Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c064:c585:308d:492b:5a9f]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 88938412D4 for ; Fri, 1 Jun 2012 11:24:07 -0400 (EDT) Message-ID: <4FC8DE96.3040102@viagenie.ca> Date: Fri, 01 Jun 2012 11:24:06 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1 MIME-Version: 1.0 To: "behave@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [BEHAVE] Unjustified SHOULDs in CGN requirements 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, 01 Jun 2012 15:24:09 -0000 Dear BEHAVErs, During AD review of draft-ietf-behave-lsn-requirements it was pointed out that many requirements are at the SHOULD level but do not include justification for why they are not MUSTs. Here's a list of all unjustified SHOULDs (there are 18). I'm asking the WG for a justification for each of them. If a SHOULD isn't justified, I'm going to turn it into a MUST. Note that I'm not looking for a justification for the requirement itself. I'm looking for a reason why we're saying SHOULD instead of MUST. (1) REQ-3: The CGN function SHOULD NOT have any limitations on the size nor the contiguity of the external address pool. In (2) particular, the CGN function SHOULD be configurable with contiguous or non-contiguous external IPv4 address ranges. (3) REQ-4: A CGN SHOULD support limiting the number of external ports (or, equivalently, "identifiers" for ICMP) that are assigned per subscriber. (4) A. Limits SHOULD be configurable by the CGN administrator. (5) C. Additionally, it is RECOMMENDED that the CGN include administrator-adjustable thresholds to prevent a single subscriber from consuming excessive CPU resources from the CGN (e.g., rate limit the subscriber's creation of new mappings). (6) REQ-5: A CGN SHOULD support limiting the amount of state memory allocated per mapping and per subscriber. This may include limiting the number of sessions, the number of filters, etc., depending on the NAT implementation. (7) A. Limits SHOULD be configurable by the CGN administrator. (8) B. Additionally, it SHOULD be possible to limit the rate at which memory-consuming state elements are allocated. (9) REQ-6: It SHOULD be possible to administratively turn off translation for specific destination addresses and/or ports. (10)REQ-7: It is RECOMMENDED that a CGN have an "Endpoint-Independent Filtering" behavior (as defined in [RFC4787] section 5). (11)REQ-8: Once an external port is deallocated, it SHOULD NOT be reallocated to a new mapping until at least 120 seconds have passed The length of time and the maximum number of ports in this (12) state SHOULD be configurable by the CGN administrator. Note that this requirement also applies to the case when a CGN loses state (due to a crash, reboot, failover to a cold standby, etc.). In that case, ports that were in use at the time of state (13) loss SHOULD NOT be reallocated until at least 120 seconds have passed. (14) REQ-10:CGN implementrers SHOULD make their equipment manageable. Standards-based management using standards such as "Definitions of Managed Objects for NAT" [RFC4008] is (15) RECOMMENDED. REQ-11: When a CGN is unable to create a mapping due to resource constraints or administrative restrictions (i.e., quotas): (16) C. it SHOULD send a notification (e.g., SNMP trap) towards a management system (if configured to do so); (Possible justification: SNMP trap generation rate limiting?) (17) D. and it SHOULD NOT delete existing mappings in order to "make room" for the new one. (This only applies to normal CGN behavior, not to manual operator intervention.) (18) REQ-12: A CGN SHOULD NOT log destination addresses or ports. Thanks, Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From ssenthil@cisco.com Fri Jun 1 09:05:40 2012 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 334B511E80BC for ; Fri, 1 Jun 2012 09:05:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 5n6q93AHAQO7 for ; Fri, 1 Jun 2012 09:05:39 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 38D2911E80E0 for ; Fri, 1 Jun 2012 09:05:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ssenthil@cisco.com; l=4958; q=dns/txt; s=iport; t=1338566739; x=1339776339; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=uG6qYso5IaAs+XFCWERJ7Kz00GY0D5AhURkpkbS2em8=; b=CJChCvhZsXmMQQ2qdLKVg5y3GXJ2RJTLHVG3vq8Sci/1M/H/xr7mUOpn 9Cz0SFL0g/EWXNnotXtHNQnZLSfdqSUgNJVAPyiKr3OPHWAPZKCRpSv+i w+rcmz85foxzhwZHXXTgbGi22vCXro/wOt37H/I6RRK+Fq1eojNJNq+qj E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAN7nyE+rRDoJ/2dsb2JhbABFtD2BB4IYAQEBAwESAScCAUENAQgJgRQBAQQBEiKHZAQBmByfY4sjAYVgA41Th0aOD4FmgnyBOgE X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="47207229" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 01 Jun 2012 16:05:39 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q51G5cLS008154; Fri, 1 Jun 2012 16:05:38 GMT Received: from xmb-sjc-23e.amer.cisco.com ([128.107.191.15]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 1 Jun 2012 09:05:38 -0700 Received: from 10.150.24.179 ([10.150.24.179]) by xmb-sjc-23e.amer.cisco.com ([128.107.191.15]) with Microsoft Exchange Server HTTP-DAV ; Fri, 1 Jun 2012 16:05:38 +0000 User-Agent: Microsoft-Entourage/12.31.0.110725 Date: Fri, 01 Jun 2012 12:05:37 -0400 From: ssenthil To: Simon Perreault , "behave@ietf.org" Message-ID: Thread-Topic: [BEHAVE] Unjustified SHOULDs in CGN requirements Thread-Index: Ac1AEGHqQBmzBGxBgkOIfwxnCC7hGA== In-Reply-To: <4FC8DE96.3040102@viagenie.ca> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 01 Jun 2012 16:05:38.0999 (UTC) FILETIME=[631B2470:01CD4010] Subject: Re: [BEHAVE] Unjustified SHOULDs in CGN requirements 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, 01 Jun 2012 16:05:40 -0000 On 6/1/12 11:24 AM, "Simon Perreault" wrote: > Dear BEHAVErs, > > During AD review of draft-ietf-behave-lsn-requirements it was pointed > out that many requirements are at the SHOULD level but do not include > justification for why they are not MUSTs. > > Here's a list of all unjustified SHOULDs (there are 18). I'm asking the > WG for a justification for each of them. If a SHOULD isn't justified, > I'm going to turn it into a MUST. Note that I'm not looking for a > justification for the requirement itself. I'm looking for a reason why > we're saying SHOULD instead of MUST. > > (1) REQ-3: The CGN function SHOULD NOT have any limitations on the size > nor the contiguity of the external address pool. In I would disagree with turning the above SHOULD to a MUST. The reason being that the size of the pool is directly related to the resources in the box memory and saying that the size of the pool MUST NOT be limited is restrictive and makes the device vulnerable. You may want to separate the size and contiguity and make the contiguity argument as a MUST and the size argument as a SHOULD. > (2) particular, the CGN function SHOULD be configurable with > contiguous or non-contiguous external IPv4 address ranges. > This can be changed to a MUST. > (3) REQ-4: A CGN SHOULD support limiting the number of external ports > (or, equivalently, "identifiers" for ICMP) that are assigned > per subscriber. > I agree that this can be changed to a MUST. > (4) A. Limits SHOULD be configurable by the CGN administrator. > > (5) C. Additionally, it is RECOMMENDED that the CGN include > administrator-adjustable thresholds to prevent a single > subscriber from consuming excessive CPU resources from > the CGN (e.g., rate limit the subscriber's creation of > new mappings). > The above is too vague to be called a must, unless the resources are explicitly called out. > > (6) REQ-5: A CGN SHOULD support limiting the amount of state memory > allocated per mapping and per subscriber. This may include > limiting the number of sessions, the number of filters, etc., > depending on the NAT implementation. > > (7) A. Limits SHOULD be configurable by the CGN administrator. > > (8) B. Additionally, it SHOULD be possible to limit the rate at > which memory-consuming state elements are allocated. > I don't see a justification on why the rate is a MUST, if I can limit based on the other parameters like ports and sessions and memory. > (9) REQ-6: It SHOULD be possible to administratively turn off > translation for specific destination addresses and/or ports. > > (10)REQ-7: It is RECOMMENDED that a CGN have an "Endpoint-Independent > Filtering" behavior (as defined in [RFC4787] section 5). > > (11)REQ-8: Once an external port is deallocated, it SHOULD NOT be > reallocated to a new mapping until at least 120 seconds have > passed > > The length of time and the maximum number of ports in this > (12) state SHOULD be configurable by the CGN administrator. > > Note that this requirement also applies to the case when a CGN > loses state (due to a crash, reboot, failover to a cold standby, > etc.). In that case, ports that were in use at the time of state > (13) loss SHOULD NOT be reallocated until at least 120 seconds have > passed. > > (14) REQ-10:CGN implementrers SHOULD make their equipment manageable. > Standards-based management using standards such as > "Definitions of Managed Objects for NAT" [RFC4008] is > (15) RECOMMENDED. > CGN MUST have a MIB implemented? Seems too restrictive to me. > REQ-11: When a CGN is unable to create a mapping due to resource > constraints or administrative restrictions (i.e., quotas): > > (16) C. it SHOULD send a notification (e.g., SNMP trap) towards > a management system (if configured to do so); > (Possible justification: SNMP trap generation rate limiting?) > Any such notification will have to rate limited. > (17) D. and it SHOULD NOT delete existing mappings in order to > "make room" for the new one. (This only applies to > normal CGN behavior, not to manual operator > intervention.) > Agree, this can be a MUST (NOT). > (18) REQ-12: A CGN SHOULD NOT log destination addresses or ports. > I think this should be left upto the implementation, you can say you MUST log the source port, but I don't think you can say you MUST NOT log destination addresses and ports. > Thanks, > Simon From iesg-secretary@ietf.org Fri Jun 1 13:49:07 2012 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 8891711E80E2; Fri, 1 Jun 2012 13:49:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.514 X-Spam-Level: X-Spam-Status: No, score=-102.514 tagged_above=-999 required=5 tests=[AWL=0.085, 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 zYomLcap31DL; Fri, 1 Jun 2012 13:49:07 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D36711E80CE; Fri, 1 Jun 2012 13:49:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IESG Secretary To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120601204907.13933.18289.idtracker@ietfa.amsl.com> Date: Fri, 01 Jun 2012 13:49:07 -0700 Cc: behave@ietf.org Subject: [BEHAVE] BEHAVE WG Virtual Interim Meeting, June 21, 2012 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, 01 Jun 2012 20:49:07 -0000 BEHAVE will have a conference call interim meeting at 7am PDT on Thursday, June 21. Details on the conference call will be posted at http://trac.tools.ietf.org/wg/behave/trac/wiki. We expect the meeting to last 1.5 - 2 hours. If you want to be on the agenda, please send email to behave-chairs@tools.ietf.org. From dthaler@microsoft.com Fri Jun 1 18:07:41 2012 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 106D311E8095 for ; Fri, 1 Jun 2012 18:07:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.515 X-Spam-Level: X-Spam-Status: No, score=-105.515 tagged_above=-999 required=5 tests=[AWL=1.084, 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 k3amoZW53BbL for ; Fri, 1 Jun 2012 18:07:40 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe006.messaging.microsoft.com [216.32.180.16]) by ietfa.amsl.com (Postfix) with ESMTP id 565AE11E8094 for ; Fri, 1 Jun 2012 18:07:40 -0700 (PDT) Received: from mail259-va3-R.bigfish.com (10.7.14.249) by VA3EHSOBE007.bigfish.com (10.7.40.11) with Microsoft SMTP Server id 14.1.225.23; Sat, 2 Jun 2012 01:07:07 +0000 Received: from mail259-va3 (localhost [127.0.0.1]) by mail259-va3-R.bigfish.com (Postfix) with ESMTP id 648A619800E1 for ; Sat, 2 Jun 2012 01:07:07 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: 0 X-BigFish: VS0(zzzz1202hzzz2fh2a8h668h839h944hd25hf0ah) Received-SPF: pass (mail259-va3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14MLTC102.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail259-va3 (localhost.localdomain [127.0.0.1]) by mail259-va3 (MessageSwitch) id 1338599226366896_10079; Sat, 2 Jun 2012 01:07:06 +0000 (UTC) Received: from VA3EHSMHS003.bigfish.com (unknown [10.7.14.243]) by mail259-va3.bigfish.com (Postfix) with ESMTP id 5811B1440048 for ; Sat, 2 Jun 2012 01:07:06 +0000 (UTC) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS003.bigfish.com (10.7.99.13) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sat, 2 Jun 2012 01:07:04 +0000 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) with Microsoft SMTP Server (TLS) id 14.2.298.5; Sat, 2 Jun 2012 01:07:26 +0000 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) with Microsoft SMTP Server (TLS) id 14.2.309.3; Fri, 1 Jun 2012 18:07:25 -0700 Received: from TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.178]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.02.0309.003; Fri, 1 Jun 2012 18:07:25 -0700 From: Dave Thaler To: "behave@ietf.org" Thread-Topic: Last call: draft-ietf-behave-nat64-discovery-heuristic-09 Thread-Index: Ac1AW6tggKyYFn88QeSiVcin492nCQ== Date: Sat, 2 Jun 2012 01:07:24 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B62BDA4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.90] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09 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: Sat, 02 Jun 2012 01:07:41 -0000 This email initiates a two-week Working Group Last Call on=20 draft-ietf-behave-nat64-discovery-heuristic-09, to conclude Friday June 15th. Hopefully that will give some time before our next interim meeting to review the comments and have proposed resolutions ready to discuss at the June 21st interim meeting. We need at least 5 reviewers to comment on the doc=20 (even if just saying "loos good"). -Dave Thaler From wes@mti-systems.com Fri Jun 1 19:13:45 2012 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 097FE11E808C for ; Fri, 1 Jun 2012 19:13:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 Pi4CllPiK4T8 for ; Fri, 1 Jun 2012 19:13:44 -0700 (PDT) Received: from omr15.networksolutionsemail.com (omr15.networksolutionsemail.com [205.178.146.65]) by ietfa.amsl.com (Postfix) with ESMTP id 5A35C11E8081 for ; Fri, 1 Jun 2012 19:13:44 -0700 (PDT) Received: from cm-omr8 (mail.networksolutionsemail.com [205.178.146.50]) by omr15.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q522DdSh011401 for ; Fri, 1 Jun 2012 22:13:40 -0400 Authentication-Results: cm-omr8 smtp.user=wes@mti-systems.com; auth=pass (PLAIN) X-Authenticated-UID: wes@mti-systems.com Received: from [69.81.143.202] ([69.81.143.202:24777] helo=[192.168.1.106]) by cm-omr8 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id AE/56-09498-3D679CF4; Fri, 01 Jun 2012 22:13:39 -0400 Message-ID: <4FC976CC.2040608@mti-systems.com> Date: Fri, 01 Jun 2012 22:13:32 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Dave Thaler References: <9B57C850BB53634CACEC56EF4853FF653B39DF3C@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B39DF3C@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "behave@ietf.org" Subject: Re: [BEHAVE] BEHAVE WG errata review 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: Sat, 02 Jun 2012 02:13:45 -0000 On 1/19/2012 3:10 PM, Dave Thaler wrote: > | RFC6145 | 3060 | 2011-12-23 | Gandhar Gokhale | behave | Technical | > > I believe the filer is correct. The RFC does not contain the right statement with > respect to handling of IPv6 extension headers. It says they're skipped when > filling in the payload but it doesn't say they're skipped when filling in the > length field. > > Propose to move to "Approved" per guideline "Only errors that could cause > implementation or deployment problems or significant confusion should be > Approved." > > However, since the filer proposes what the "corrected" behavior is, I believe > we need WG consensus to approve that statement. I didn't see anyone in the WG pushback on this, and so moved it to "Approved", as recommended, based on the logic that it seems reasonable and that silence must mean consensus from the WG. ;) -- Wes Eddy MTI Systems From wes@mti-systems.com Fri Jun 1 19:35:27 2012 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 A62F611E80BB for ; Fri, 1 Jun 2012 19:35:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 Go5nPB5OaTRZ for ; Fri, 1 Jun 2012 19:35:26 -0700 (PDT) Received: from omr15.networksolutionsemail.com (omr15.networksolutionsemail.com [205.178.146.65]) by ietfa.amsl.com (Postfix) with ESMTP id C20AF11E80B8 for ; Fri, 1 Jun 2012 19:35:26 -0700 (PDT) Received: from cm-omr2 (mail.networksolutionsemail.com [205.178.146.50]) by omr15.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q522ZQF2024243 for ; Fri, 1 Jun 2012 22:35:26 -0400 Authentication-Results: cm-omr2 smtp.user=wes@mti-systems.com; auth=pass (PLAIN) X-Authenticated-UID: wes@mti-systems.com Received: from [69.81.143.202] ([69.81.143.202:41726] helo=[192.168.1.106]) by cm-omr2 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 51/22-11572-DEB79CF4; Fri, 01 Jun 2012 22:35:26 -0400 Message-ID: <4FC97BE6.2040502@mti-systems.com> Date: Fri, 01 Jun 2012 22:35:18 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: behave@ietf.org, marka@isc.org References: <20120531004855.CB703621A0@rfc-editor.org> In-Reply-To: <20120531004855.CB703621A0@rfc-editor.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] [Technical Errata Reported] RFC6147 (3236) 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: Sat, 02 Jun 2012 02:35:27 -0000 While this may be a valid criticism, based on the rules for errata processing, I think the only feasible option we have is to reject it for now. http://www.ietf.org/iesg/statement/errata-processing.html says: Changes that are clearly modifications to the intended consensus, or involve large textual changes, should be Rejected. HOWEVER, it seems to me that if there was consensus around some new text that was simple to plop into that section, then the "Corrected Text" field could be updated with that, and we could make it a "Hold for Document Update" rather than rejecting it. Thoughts? On 5/30/2012 8:48 PM, RFC Errata System wrote: > > The following errata report has been submitted for RFC6147, > "DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=6147&eid=3236 > > -------------------------------------- > Type: Technical > Reported by: Mark Andrews > > Section: 5.5 > > Original Text > ------------- > An application that wants to perform validation on its own should use the CD bit. > > Corrected Text > -------------- > Section 5.5 needs to be completely re analysed, > > Notes > ----- > Section 5.5 is written around the assumption that a validating stub resolver will be setting CD=1 as well as DO=1. There is no such requirement RFC 4035 and in fact setting both CD=1 and DO=1 leaves the stub resolver vulnerable to answers from authoritative servers for the zone that are serving a stale copy of the zone and spoofed answers being sent to the DNS64 server. > > Non CD=1 queries result in the DNS64 server in its recursive roll, filtering out, cryptographically bad answers. > > DO=1 alone should disable synthesis. > > 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. > > -------------------------------------- > RFC6147 (draft-ietf-behave-dns64-11) > -------------------------------------- > Title : DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers > Publication Date : April 2011 > Author(s) : M. Bagnulo, A. Sullivan, P. Matthews, I. van Beijnum > Category : PROPOSED STANDARD > Source : Behavior Engineering for Hindrance Avoidance > Area : Transport > Stream : IETF > Verifying Party : IESG > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > > -- Wes Eddy MTI Systems From Jean-Francois.TremblayING@videotron.com Mon Jun 4 06:05:22 2012 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 71F3D21F86B1; Mon, 4 Jun 2012 06:05:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 HseJ5-YibsEO; Mon, 4 Jun 2012 06:05:21 -0700 (PDT) Received: from mx02.videotron.com (mx02.videotron.com [24.201.243.151]) by ietfa.amsl.com (Postfix) with ESMTP id 422A121F86AD; Mon, 4 Jun 2012 06:05:20 -0700 (PDT) In-Reply-To: To: ssenthil MIME-Version: 1.0 X-KeepSent: 2193F94E:6B8355DD-85257A13:00461534; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 7.0.2 September 26, 2006 Message-ID: From: Jean-Francois.TremblayING@videotron.com Date: Mon, 4 Jun 2012 09:05:08 -0400 X-MIMETrack: Serialize by Router on DOMMSG01/SRV/GVL(Release 8.5.3FP1|March 07, 2012) at 06/04/2012 09:05:09, Serialize complete at 06/04/2012 09:05:09 Content-Type: text/plain; charset="US-ASCII" Received-SPF: none Cc: behave-bounces@ietf.org, "behave@ietf.org" Subject: Re: [BEHAVE] Unjustified SHOULDs in CGN requirements 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, 04 Jun 2012 13:05:22 -0000 Hello Senthil, Simon. Being on the deployment side of the equation, I agree with Senthil on most points, except on the MIB requirement, where the MUST makes sense in my opinion. It doesn't make sense to have such a box deployed without the capacity to monitor it properly. More below (no strong feeling on a point unless noted otherwise). > > Here's a list of all unjustified SHOULDs (there are 18). I'm asking the > > WG for a justification for each of them. If a SHOULD isn't justified, > > I'm going to turn it into a MUST. Note that I'm not looking for a > > justification for the requirement itself. I'm looking for a reason why > > we're saying SHOULD instead of MUST. > > > > (3) REQ-4: A CGN SHOULD support limiting the number of external ports > > (or, equivalently, "identifiers" for ICMP) that are assigned > > per subscriber. > > > > I agree that this can be changed to a MUST. +1 on MUST. This is an important requirement for a deployment. > > (4) A. Limits SHOULD be configurable by the CGN administrator. > > > > (5) C. Additionally, it is RECOMMENDED that the CGN include > > administrator-adjustable thresholds to prevent a single > > subscriber from consuming excessive CPU resources from > > the CGN (e.g., rate limit the subscriber's creation of > > new mappings). > > > The above is too vague to be called a must, unless the resources are > explicitly called out. This could remain a SHOULD. Rate-limiting isn't a huge plus IMHO as long as the port-limit is present. > > (6) REQ-5: A CGN SHOULD support limiting the amount of state memory > > allocated per mapping and per subscriber. This may include > > limiting the number of sessions, the number of filters, etc., > > depending on the NAT implementation. > > > > (7) A. Limits SHOULD be configurable by the CGN administrator. > > > > (8) B. Additionally, it SHOULD be possible to limit the rate at > > which memory-consuming state elements are allocated. > > > I don't see a justification on why the rate is a MUST, if I can limit based > on the other parameters like ports and sessions and memory. This looks implementation dependant. No need for a MUST here IMO. > > (9) REQ-6: It SHOULD be possible to administratively turn off > > translation for specific destination addresses and/or ports. Useful. +1 on a MUST here, but no strong feeling. > > (11)REQ-8: Once an external port is deallocated, it SHOULD NOT be > > reallocated to a new mapping until at least 120 seconds have > > passed -1 on MUST here. I understand that the 120 seconds is there for security reasons, but I'm not sure I want an implementation to be limited with such a static number. In an environment with a very high number of short-lived sessions, this is very limitating. > > The length of time and the maximum number of ports in this > > (12) state SHOULD be configurable by the CGN administrator. +1 on the MUST be configurable. But this somewhat goes against (11). I guess an implementor will understand that the timer must be configurable with a lower limit of 120 seconds. > > (14) REQ-10:CGN implementrers SHOULD make their equipment manageable. > > Standards-based management using standards such as > > "Definitions of Managed Objects for NAT" [RFC4008] is > > (15) RECOMMENDED. > > > CGN MUST have a MIB implemented? Seems too restrictive to me. +1 on a MUST here, as stated above. The MIB is needed for any serious deployment IMHO. > > (17) D. and it SHOULD NOT delete existing mappings in order to > > "make room" for the new one. (This only applies to > > normal CGN behavior, not to manual operator > > intervention.) > > > Agree, this can be a MUST (NOT). +1 on the MUST NOT. > > (18) REQ-12: A CGN SHOULD NOT log destination addresses or ports. > > > I think this should be left upto the implementation, you can say you MUST > log the source port, but I don't think you can say you MUST NOT log > destination addresses and ports. Agreed on the MUST log the source, per Senthil's suggestion. I would leave the destination logging an open matter. /JF From sm@resistor.net Tue Jun 5 15:17:45 2012 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 91BCE11E8086 for ; Tue, 5 Jun 2012 15:17:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.485 X-Spam-Level: X-Spam-Status: No, score=-102.485 tagged_above=-999 required=5 tests=[AWL=0.114, 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 WXaTPJ60xVW0 for ; Tue, 5 Jun 2012 15:17:42 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A15F11E8079 for ; Tue, 5 Jun 2012 15:17:41 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q55MHY5O017514; Tue, 5 Jun 2012 15:17:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1338934660; i=@resistor.net; bh=EqRZmMbdzQqmb7JlH1xQVG5ozqdouDJMV0MQBX6J9zM=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=kCTUjp30BcUF35gLXry/ynS4iW8Fdgc9CN5uCEgq7Xacl2WN8lR8/QPuBT1Bwheu/ fSyuUY02Nso4BSvKIoX2uUJQcYY1PjseIf1p/Z8iMA4D4dnKz02obxVsFmgOmoRCC/ EJzPhxwfVOqiZCLcK7PdYZO/IVZ2nFSL5BBpzqSo= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1338934660; i=@resistor.net; bh=EqRZmMbdzQqmb7JlH1xQVG5ozqdouDJMV0MQBX6J9zM=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=aRDVltBqrGP57TbxSLlZNRECHXHrURanScG+ZDFIL6HcRDF9OsPPD8MrPZUF+PpeG SV5BdQOrbTtGBEGSvcijsbE42mAHC7nRTEF+5XS/7z9+dbL10MeYMiWfE4TeFgjoRt igREX7ef3moV8CQmsHAlvMpmNgFxWfdx4V73A/bA= Message-Id: <6.2.5.6.2.20120605150739.08d484d0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 05 Jun 2012 15:13:03 -0700 To: Wesley Eddy , behave@ietf.org, marka@isc.org From: SM In-Reply-To: <4FC97BE6.2040502@mti-systems.com> References: <20120531004855.CB703621A0@rfc-editor.org> <4FC97BE6.2040502@mti-systems.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [BEHAVE] [Technical Errata Reported] RFC6147 (3236) 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, 05 Jun 2012 22:17:45 -0000 At 19:35 01-06-2012, Wesley Eddy wrote: >HOWEVER, it seems to me that if there was consensus >around some new text that was simple to plop into that >section, then the "Corrected Text" field could be >updated with that, and we could make it a "Hold for >Document Update" rather than rejecting it. > >Thoughts? Erratum #3236 does not reflect the intended consensus when RFC 6147 was approved. "Rejected" may be a better fit as it does not seem like a small change. Regards, -sm From sm@resistor.net Tue Jun 5 15:17:46 2012 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 CCE9811E8088 for ; Tue, 5 Jun 2012 15:17:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.49 X-Spam-Level: X-Spam-Status: No, score=-102.49 tagged_above=-999 required=5 tests=[AWL=0.109, 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 bMDrIu9mZ6a0 for ; Tue, 5 Jun 2012 15:17:46 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 80DF211E807F for ; Tue, 5 Jun 2012 15:17:45 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q55MHY5Q017514; Tue, 5 Jun 2012 15:17:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1338934664; i=@resistor.net; bh=TLCVdm2G94EWIUwMtuPjsjIhYEZBi3fVsGeWLJ5MusU=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=DvBO1IiUnTFO4apY529kd7je2BsRR9KLS6pUlGPo81tF/CS3/ARWUxgm+PMq4f0xz iTI382OUC8kpMgy3mr8td21MjWIMUhGZ4QeQ6TBSvyIr+RY53/ZkFWGpYrFa0AtlKb AKlK/ufh5sNf44auPVN5H0GR76CGJaOeqIgY4irI= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1338934664; i=@resistor.net; bh=TLCVdm2G94EWIUwMtuPjsjIhYEZBi3fVsGeWLJ5MusU=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=fGWyNXBl7z2NsRoAZwkRPcGfHc6UtpvLKa0e7T4E8Zfn7v4BJGHpuu/90h4qP25Q/ zk2gT590KERITO3sRvu2hxpOeoy7W3iLMytw+lg2ETZKPrQY+xVh2NQp19K93i4+sq fRRnjKw7wFdOwbabFVamnTUf4uYW5rWHv+pe+FAE= Message-Id: <6.2.5.6.2.20120605151428.08d47fb0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 05 Jun 2012 15:17:38 -0700 To: Wesley Eddy , Dave Thaler From: SM In-Reply-To: <4FC976CC.2040608@mti-systems.com> References: <9B57C850BB53634CACEC56EF4853FF653B39DF3C@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <4FC976CC.2040608@mti-systems.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: behave@ietf.org Subject: Re: [BEHAVE] BEHAVE WG errata review 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, 05 Jun 2012 22:17:47 -0000 At 19:13 01-06-2012, Wesley Eddy wrote: >On 1/19/2012 3:10 PM, Dave Thaler wrote: > > | RFC6145 | 3060 | 2011-12-23 | Gandhar Gokhale | > behave | Technical | [snip] >I didn't see anyone in the WG pushback on this, and so >moved it to "Approved", as recommended, based on the >logic that it seems reasonable and that silence must >mean consensus from the WG. ;) This erratum is a significant change and it introduces a requirement. I suggest "Rejected". Regards, -sm From dthaler@microsoft.com Tue Jun 5 15:24:05 2012 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 15E4D11E808D for ; Tue, 5 Jun 2012 15:24:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.044 X-Spam-Level: X-Spam-Status: No, score=-104.044 tagged_above=-999 required=5 tests=[AWL=-0.445, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 kmfBw3fhOeVw for ; Tue, 5 Jun 2012 15:24:04 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe004.messaging.microsoft.com [213.199.154.142]) by ietfa.amsl.com (Postfix) with ESMTP id 0633A11E808C for ; Tue, 5 Jun 2012 15:24:03 -0700 (PDT) Received: from mail104-db3-R.bigfish.com (10.3.81.243) by DB3EHSOBE005.bigfish.com (10.3.84.25) with Microsoft SMTP Server id 14.1.225.23; Tue, 5 Jun 2012 22:23:19 +0000 Received: from mail104-db3 (localhost [127.0.0.1]) by mail104-db3-R.bigfish.com (Postfix) with ESMTP id 79D8F8043D; Tue, 5 Jun 2012 22:23:19 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -37 X-BigFish: VS-37(zzbb2dI9371I936eI542M1432N98dKzz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25hf0ah) Received-SPF: pass (mail104-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14MLTC102.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail104-db3 (localhost.localdomain [127.0.0.1]) by mail104-db3 (MessageSwitch) id 1338934997612028_23054; Tue, 5 Jun 2012 22:23:17 +0000 (UTC) Received: from DB3EHSMHS006.bigfish.com (unknown [10.3.81.233]) by mail104-db3.bigfish.com (Postfix) with ESMTP id 895B92E0047; Tue, 5 Jun 2012 22:23:17 +0000 (UTC) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS006.bigfish.com (10.3.87.106) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 5 Jun 2012 22:23:16 +0000 Received: from TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com (157.54.24.14) by TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) with Microsoft SMTP Server (TLS) id 14.2.298.5; Tue, 5 Jun 2012 22:23:45 +0000 Received: from TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.178]) by TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com ([157.54.24.14]) with mapi id 14.02.0309.003; Tue, 5 Jun 2012 15:23:45 -0700 From: Dave Thaler To: SM , Wesley Eddy Thread-Topic: [BEHAVE] BEHAVE WG errata review Thread-Index: AczW5mx+8jtugezTRsyZi0tOD+AmoxpuY6UAAMDtTgAADpV08A== Date: Tue, 5 Jun 2012 22:23:45 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B632798@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> References: <9B57C850BB53634CACEC56EF4853FF653B39DF3C@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <4FC976CC.2040608@mti-systems.com> <6.2.5.6.2.20120605151428.08d47fb0@resistor.net> In-Reply-To: <6.2.5.6.2.20120605151428.08d47fb0@resistor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.90] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "behave@ietf.org" Subject: Re: [BEHAVE] BEHAVE WG errata review 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, 05 Jun 2012 22:24:05 -0000 Rejected implies the original text matches WG intent. It does not, two places in the doc contradict each other. The question is= between=20 Hold for Document Update vs Approved. The argument for Approved is that it's an interoperability issue, so you ne= ed to know which place is right and which place is wrong in the doc. The problem is that the suggested text includes both a correction (which in= my opinion should be approved), and an additional rule, which might be Rejected. That is, the first senten= ce suggested is a correction, and the second sentence is an addition. > Total Length: If the Next Header field of the Fragment Header is not an e= xtension header (except ESP)=20 > then Total Length MUST be set to Payload Length value from IPv6 header, m= inus 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 (e= xcept ESP) then the packet=20 > SHOULD be dropped and logged. -Dave > -----Original Message----- > From: SM [mailto:sm@resistor.net] > Sent: Tuesday, June 5, 2012 3:18 PM > To: Wesley Eddy; Dave Thaler > Cc: behave@ietf.org > Subject: Re: [BEHAVE] BEHAVE WG errata review >=20 > At 19:13 01-06-2012, Wesley Eddy wrote: > >On 1/19/2012 3:10 PM, Dave Thaler wrote: > > > | RFC6145 | 3060 | 2011-12-23 | Gandhar Gokhale | > > behave | Technical | >=20 > [snip] >=20 > >I didn't see anyone in the WG pushback on this, and so moved it to > >"Approved", as recommended, based on the logic that it seems reasonable > >and that silence must mean consensus from the WG. ;) >=20 > This erratum is a significant change and it introduces a requirement. I = suggest > "Rejected". >=20 > Regards, > -sm >=20 From sm@resistor.net Tue Jun 5 15:27:49 2012 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 EAFF111E8096 for ; Tue, 5 Jun 2012 15:27:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.495 X-Spam-Level: X-Spam-Status: No, score=-102.495 tagged_above=-999 required=5 tests=[AWL=0.104, 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 z6YEIuLS0E4Q for ; Tue, 5 Jun 2012 15:27:49 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F53B11E808D for ; Tue, 5 Jun 2012 15:27:48 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q55MRfqH008471; Tue, 5 Jun 2012 15:27:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1338935267; i=@resistor.net; bh=9fdVsHfvP6D6mpyaPEcJC+iiizMiQFFlpC1TsPIgv3c=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=mZHJyX7XBRKqiUdS5Ip749EKFA+yFf8omupxb3I3Wym+HxeidgHXgsHWsb+JVdhw0 XlgWK44wAHWd+6+kIKkxj8mOxujBNdGvS4mPc1JDVCwi6YBCUn1aQnj5xKJIgffZqr MQYcjpm1MFwDNZ5ZguVtjnBUqJ0TAxcpgeme7j8g= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1338935267; i=@resistor.net; bh=9fdVsHfvP6D6mpyaPEcJC+iiizMiQFFlpC1TsPIgv3c=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=KfyxvbMRT8c0qk0XcTdMzLUdLz3Hpw9gMuX3W2lJ64VdtX0Ab/cRAC2HX4xiWbHHI 7NS/OXy/LQ60NKuWiwNOqYqJQoI1JY7PaSGii8X1wMckfhCZrX2rIZ2jZQpv/FAm8j iF5kZwGDiyZcVSIhLBSVWY/JYJ3WRPs5upY6vSTI= Message-Id: <6.2.5.6.2.20120605152327.08d47a90@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 05 Jun 2012 15:25:06 -0700 To: teemu.savolainen@nokia.com, , behave@ietf.org From: SM In-Reply-To: <916CE6CF87173740BC8A2CE44309696204380B57@008-AM1MPN1-052.m gdnok.nokia.com> References: <916CE6CF87173740BC8A2CE44309696204380A2B@008-AM1MPN1-052.mgdnok.nokia.com> <916CE6CF87173740BC8A2CE44309696204380B57@008-AM1MPN1-052.mgdnok.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [BEHAVE] RFC6052, RFC5735, and "non-global IPv4 addresses" with WKP 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, 05 Jun 2012 22:27:50 -0000 At 01:18 22-05-2012, teemu.savolainen@nokia.com wrote: >I hope there are no existing validation codes in DNS64s that would >get headache with A record containing addresses from this 192.0.0.0/24 block? Is 192.0.0.0/24 global or not? I am looking this in terms of whether the /24 should be filtered or not. Regards, -sm From sm@resistor.net Tue Jun 5 15:44:21 2012 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 93E4521F8736 for ; Tue, 5 Jun 2012 15:44:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 cm2bn9GNs0R1 for ; Tue, 5 Jun 2012 15:44:21 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 27EE021F8734 for ; Tue, 5 Jun 2012 15:44:21 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q55MiF9Y019660; Tue, 5 Jun 2012 15:44:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1338936260; i=@resistor.net; bh=iHxNPlRDePpx9lNLqxX/sr8YjB413vW9/hV0flm8c9E=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=BKoLRm4uppnE5or8+vm8XRdNjzYEPaKHRrT5wzXfy+dFiFb2UA/0XzmLve3XNp00y TePRClGbWSsATYxukO5BhCtZ+ixh2/bW/qtf99O7szE6T/oSSEPGKhfpbJSTVCZc2J 83jrafZyl0+S4n2Ey+OQeIRo81rw2JP/WkLqeiPc= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1338936260; i=@resistor.net; bh=iHxNPlRDePpx9lNLqxX/sr8YjB413vW9/hV0flm8c9E=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=cv0gQCdxyKmGiYP+RdJHGwiyJzKGKiYko2co3zvrUWM1pjom3DVufzKRTCK4lJVxA DCULw7lJ/dILWYtbMWlJumQe6q7bIkIz8fepvRvfDrLWfWseRCKjjcDEzaIxiFRLZj BGjQrMbBOw+t63k+O5Z90nPcF9HVrsx9PZQz2gYE= Message-Id: <6.2.5.6.2.20120605152926.0b0f0608@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 05 Jun 2012 15:44:08 -0700 To: Dave Thaler , Wesley Eddy From: SM In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B632798@TK5EX14MBXW601.wi ngroup.windeploy.ntdev.microsoft.com> References: <9B57C850BB53634CACEC56EF4853FF653B39DF3C@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <4FC976CC.2040608@mti-systems.com> <6.2.5.6.2.20120605151428.08d47fb0@resistor.net> <9B57C850BB53634CACEC56EF4853FF653B632798@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "behave@ietf.org" Subject: Re: [BEHAVE] BEHAVE WG errata review 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, 05 Jun 2012 22:44:21 -0000 At 15:23 05-06-2012, Dave Thaler wrote: >Rejected implies the original text matches WG intent. >It does not, two places in the doc contradict each other. The >question is between >Hold for Document Update > vs >Approved. > >The argument for Approved is that it's an interoperability issue, so you need >to know which place is right and which place is wrong in the doc. Yes. >The problem is that the suggested text includes both a correction >(which in my opinion should be approved), >and an additional rule, which might be Rejected. That is, the first >sentence suggested is a correction, >and the second sentence is an addition. The problem is the MUST and the SHOULD. Given that it changes the intended consensus, I would pick "Hold for Document Update". Some people might ignore the erratum unless the issue is serious enough (guideline 1) for the requirement to be followed. Regards, -sm From wes@mti-systems.com Tue Jun 5 16:02:34 2012 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 2F86611E8094 for ; Tue, 5 Jun 2012 16:02:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 7979JKDKh1WM for ; Tue, 5 Jun 2012 16:02:33 -0700 (PDT) Received: from omr14.networksolutionsemail.com (omr14.networksolutionsemail.com [205.178.146.64]) by ietfa.amsl.com (Postfix) with ESMTP id A7F5D11E8086 for ; Tue, 5 Jun 2012 16:02:29 -0700 (PDT) Received: from cm-omr2 (mail.networksolutionsemail.com [205.178.146.50]) by omr14.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q55N2SPX019028 for ; Tue, 5 Jun 2012 19:02:29 -0400 Authentication-Results: cm-omr2 smtp.user=wes@mti-systems.com; auth=pass (PLAIN) X-Authenticated-UID: wes@mti-systems.com Received: from [63.226.32.150] ([63.226.32.150:20208] helo=[172.27.250.8]) by cm-omr2 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 4D/AD-11572-4009ECF4; Tue, 05 Jun 2012 19:02:28 -0400 Message-ID: <4FCE8FFF.8050801@mti-systems.com> Date: Tue, 05 Jun 2012 19:02:23 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Dave Thaler References: <9B57C850BB53634CACEC56EF4853FF653B39DF3C@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <4FC976CC.2040608@mti-systems.com> <6.2.5.6.2.20120605151428.08d47fb0@resistor.net> <9B57C850BB53634CACEC56EF4853FF653B632798@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B632798@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "behave@ietf.org" Subject: Re: [BEHAVE] BEHAVE WG errata review 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, 05 Jun 2012 23:02:34 -0000 On 6/5/2012 6:23 PM, Dave Thaler wrote: > The problem is that the suggested text includes both a correction (which in my opinion should be approved), > and an additional rule, which might be Rejected. That is, the first sentence suggested is a correction, > and the second sentence is an addition. The two sentences cover the two cases of "isn't an extension header" and "is an extension header". If we only retained the first, then there would still be some ambiguity about what to do in the case that the second is covering. In my opinion, the second sentence's "SHOULD" leaves sufficient wiggle room to do something else, if an implementer has some reasonable justification, though it may not be ideal. -- Wes Eddy MTI Systems From dthaler@microsoft.com Tue Jun 5 18:36:52 2012 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 096AD21F861A for ; Tue, 5 Jun 2012 18:36:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.484 X-Spam-Level: X-Spam-Status: No, score=-105.484 tagged_above=-999 required=5 tests=[AWL=1.115, 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 5dNrqXs8Y-am for ; Tue, 5 Jun 2012 18:36:51 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by ietfa.amsl.com (Postfix) with ESMTP id D3BC721F85DF for ; Tue, 5 Jun 2012 18:36:48 -0700 (PDT) Received: from mail120-tx2-R.bigfish.com (10.9.14.254) by TX2EHSOBE005.bigfish.com (10.9.40.25) with Microsoft SMTP Server id 14.1.225.23; Wed, 6 Jun 2012 01:36:04 +0000 Received: from mail120-tx2 (localhost [127.0.0.1]) by mail120-tx2-R.bigfish.com (Postfix) with ESMTP id 80AB82E0396; Wed, 6 Jun 2012 01:36:04 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC106.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -36 X-BigFish: VS-36(zzbb2dI9371I542M1432N98dKzz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25hf0ah) Received-SPF: pass (mail120-tx2: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14HUBC106.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail120-tx2 (localhost.localdomain [127.0.0.1]) by mail120-tx2 (MessageSwitch) id 1338946562266575_6830; Wed, 6 Jun 2012 01:36:02 +0000 (UTC) Received: from TX2EHSMHS038.bigfish.com (unknown [10.9.14.252]) by mail120-tx2.bigfish.com (Postfix) with ESMTP id 3BF55120044; Wed, 6 Jun 2012 01:36:02 +0000 (UTC) Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS038.bigfish.com (10.9.99.138) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 6 Jun 2012 01:36:01 +0000 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC106.redmond.corp.microsoft.com (157.54.80.61) with Microsoft SMTP Server (TLS) id 14.2.298.5; Wed, 6 Jun 2012 01:36:44 +0000 Received: from TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.178]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi id 14.02.0309.003; Tue, 5 Jun 2012 18:36:44 -0700 From: Dave Thaler To: Wesley Eddy Thread-Topic: [BEHAVE] BEHAVE WG errata review Thread-Index: AczW5mx+8jtugezTRsyZi0tOD+AmoxpuY6UAAMDtTgAADpV08P//l9WAgABKZ4A= Date: Wed, 6 Jun 2012 01:36:44 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B632E07@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> References: <9B57C850BB53634CACEC56EF4853FF653B39DF3C@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <4FC976CC.2040608@mti-systems.com> <6.2.5.6.2.20120605151428.08d47fb0@resistor.net> <9B57C850BB53634CACEC56EF4853FF653B632798@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <4FCE8FFF.8050801@mti-systems.com> In-Reply-To: <4FCE8FFF.8050801@mti-systems.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.90] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "behave@ietf.org" Subject: Re: [BEHAVE] BEHAVE WG errata review 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, 06 Jun 2012 01:36:52 -0000 I agree. I'm fine with Approved. -Dave > -----Original Message----- > From: Wesley Eddy [mailto:wes@mti-systems.com] > Sent: Tuesday, June 5, 2012 4:02 PM > To: Dave Thaler > Cc: SM; behave@ietf.org > Subject: Re: [BEHAVE] BEHAVE WG errata review >=20 > On 6/5/2012 6:23 PM, Dave Thaler wrote: > > The problem is that the suggested text includes both a correction > > (which in my opinion should be approved), and an additional rule, > > which might be Rejected. That is, the first sentence suggested is a > correction, and the second sentence is an addition. >=20 > The two sentences cover the two cases of "isn't an extension header" > and "is an extension header". If we only retained the first, then there = would > still be some ambiguity about what to do in the case that the second is > covering. >=20 > In my opinion, the second sentence's "SHOULD" leaves sufficient wiggle > room to do something else, if an implementer has some reasonable > justification, though it may not be ideal. >=20 > -- > Wes Eddy > MTI Systems From dthaler@microsoft.com Tue Jun 5 18:55:44 2012 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 D222F21F8782 for ; Tue, 5 Jun 2012 18:55:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.554 X-Spam-Level: X-Spam-Status: No, score=-105.554 tagged_above=-999 required=5 tests=[AWL=1.045, 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 AWRBbJE0YVUC for ; Tue, 5 Jun 2012 18:55:44 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by ietfa.amsl.com (Postfix) with ESMTP id 4EA5D21F87C0 for ; Tue, 5 Jun 2012 18:55:43 -0700 (PDT) Received: from mail111-tx2-R.bigfish.com (10.9.14.245) by TX2EHSOBE006.bigfish.com (10.9.40.26) with Microsoft SMTP Server id 14.1.225.23; Wed, 6 Jun 2012 01:54:58 +0000 Received: from mail111-tx2 (localhost [127.0.0.1]) by mail111-tx2-R.bigfish.com (Postfix) with ESMTP id E025020037C; Wed, 6 Jun 2012 01:54:57 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC105.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -36 X-BigFish: VS-36(zz9371I936eI542M1432N98dKzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839h944hd25hf0ah) Received-SPF: pass (mail111-tx2: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14HUBC105.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail111-tx2 (localhost.localdomain [127.0.0.1]) by mail111-tx2 (MessageSwitch) id 1338947696132144_14910; Wed, 6 Jun 2012 01:54:56 +0000 (UTC) Received: from TX2EHSMHS019.bigfish.com (unknown [10.9.14.248]) by mail111-tx2.bigfish.com (Postfix) with ESMTP id 0F0284009B; Wed, 6 Jun 2012 01:54:56 +0000 (UTC) Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS019.bigfish.com (10.9.99.119) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 6 Jun 2012 01:54:55 +0000 Received: from TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com (157.54.24.14) by TK5EX14HUBC105.redmond.corp.microsoft.com (157.54.80.48) with Microsoft SMTP Server (TLS) id 14.2.298.5; Wed, 6 Jun 2012 01:55:38 +0000 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com (157.54.24.14) with Microsoft SMTP Server (TLS) id 14.2.309.3; Tue, 5 Jun 2012 18:55:38 -0700 Received: from TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.178]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.02.0309.003; Tue, 5 Jun 2012 18:55:38 -0700 From: Dave Thaler To: SM , "teemu.savolainen@nokia.com" , Christian Huitema , "behave@ietf.org" Thread-Topic: [BEHAVE] RFC6052, RFC5735, and "non-global IPv4 addresses" with WKP Thread-Index: AQHNQ2p1sxnY8Ea6XUCrFNmLYiDwH5bsh2Lw Date: Wed, 6 Jun 2012 01:55:38 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B632EDF@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> References: <916CE6CF87173740BC8A2CE44309696204380A2B@008-AM1MPN1-052.mgdnok.nokia.com> <916CE6CF87173740BC8A2CE44309696204380B57@008-AM1MPN1-052.mgdnok.nokia.com> <6.2.5.6.2.20120605152327.08d47a90@resistor.net> In-Reply-To: <6.2.5.6.2.20120605152327.08d47a90@resistor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.90] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [BEHAVE] RFC6052, RFC5735, and "non-global IPv4 addresses" with WKP 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, 06 Jun 2012 01:55:45 -0000 > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of SM > Sent: Tuesday, June 5, 2012 3:25 PM > To: teemu.savolainen@nokia.com; Christian Huitema; behave@ietf.org > Subject: Re: [BEHAVE] RFC6052, RFC5735, and "non-global IPv4 addresses" > with WKP >=20 > At 01:18 22-05-2012, teemu.savolainen@nokia.com wrote: > >I hope there are no existing validation codes in DNS64s that would get > >headache with A record containing addresses from this 192.0.0.0/24 bloc= k? >=20 > Is 192.0.0.0/24 global or not? RFC 5736 reserves 192.0.0.0/24. It states: 7. The registry will also note, for each designation, the intended routing scope of the address, indicating whether the address is intended to be routable only in scoped, local, or private contexts, or whether the address prefix is intended to be routed globally. So it can be global. Basically you should assume it's global unless there= 's a specific sub-prefix registered that is indicated as being non-global. The current list of things registered is found at http://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-specia= l-registry.xml and the Routing Scope column is particularly relevant. -Dave > I am looking this in terms of whether the /24 should be filtered or not. >=20 > Regards, > -sm >=20 > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From ietf-ipr@ietf.org Wed Jun 6 09:10:29 2012 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 EFCE321F883F; Wed, 6 Jun 2012 09:10:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.443 X-Spam-Level: X-Spam-Status: No, score=-102.443 tagged_above=-999 required=5 tests=[AWL=0.156, 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 RmnPQjDKyn6b; Wed, 6 Jun 2012 09:10:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F55021F8670; Wed, 6 Jun 2012 09:10:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: teemu.savolainen@nokia.com, jouni.nospam@gmail.com, dwing@cisco.com X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120606161028.19339.20627.idtracker@ietfa.amsl.com> Date: Wed, 06 Jun 2012 09:10:28 -0700 Cc: behave@ietf.org, wes@mti-systems.com, dthaler@microsoft.com, dwing@cisco.com, martin.stiemerling@neclab.eu, ipr-announce@ietf.org Subject: [BEHAVE] IPR Disclosure: Nokia Corporation's Statement about IPR related to draft-ietf-behave-nat64-discovery-heuristic-09 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, 06 Jun 2012 16:10:29 -0000 Dear Teemu Savolainen, Jouni Korhonen, Dan Wing: An IPR disclosure that pertains to your Internet-Draft entitled "Discovery= of IPv6 Prefix Used for IPv6 Address Synthesis" (draft-ietf-behave-nat64-disco= very- heuristic) was submitted to the IETF Secretariat on 2012-06-05 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1795/). The title of the IPR disclosure is "Nokia Corporation's Statement about IPR related to draft-ietf-behave-nat64 -discovery-heuristic-09.""); The IETF Secretariat From yding@cs.helsinki.fi Mon Jun 11 06:06:01 2012 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 2DA1821F8559 for ; Mon, 11 Jun 2012 06:06:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 06i8+7h7oB35 for ; Mon, 11 Jun 2012 06:06:00 -0700 (PDT) Received: from mail.cs.helsinki.fi (courier.cs.helsinki.fi [128.214.9.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AB3B21F8567 for ; Mon, 11 Jun 2012 06:05:58 -0700 (PDT) Received: from [128.214.9.154] (wel-33.cs.helsinki.fi [128.214.9.154]) (AUTH: PLAIN yding, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Mon, 11 Jun 2012 16:05:57 +0300 id 000A4062.4FD5ED35.00005FC0 Message-ID: <4FD5ED34.8090703@cs.helsinki.fi> Date: Mon, 11 Jun 2012 16:05:56 +0300 From: Aaron Yi DING Organization: Helsinki University User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: "behave@ietf.org" References: <9B57C850BB53634CACEC56EF4853FF653B62BDA4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B62BDA4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Dave Thaler Subject: Re: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09 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, 11 Jun 2012 13:06:01 -0000 Hello, A few comments on this WG I-D, draft-ietf-behave-nat64-discovery-heuristic-09 1) Section 3 the first paragraph, "The node MAY also need to perform DNS query for the A record of the well-know name in order to learn what is the IPv4 address of the well-known name and if the A record even exists". The phrase MAY is bit unclear to me, because in Section 7, there is such description, "A node SHOULD implement validating DNSSEC resolver for validating the A response of the well-known name query." It is unnecessary to perform redundant A record query for WKP; but for NSP, such query is probably required. So for clarity, would it be good to state as such: "The node MAY also need to perform DNS query for the A record of the well-know name in order to learn what is the IPv4 address of the well-known name and if the A record even exists (in the case of identifying Network-Specific Prefix, the node SHOULD perform a secure DNS A query to validate the A record received". 2) Section 3 the fifth paragraph, "In case another instance of the value is found inside the IPv6, the node shall repeat the search with another IPv4 address, if possible." It's good to add a few words concerning what SHOULD a node do if all of the IPv4 addresses have been tried but failed (some other instances are found in the IPv6). 3) Section 3.1.2, the description is very concise and clear here. However, one simple figure illustrating the message flow and major components involved in such secure learning will improve the overall clarity. 4) Also in Section 3.1.2, I suppose the network Entity responding to step 2 and step 4 could be DNS64 which is controlled by the operator, but in the text, no text referring to this detail. This comment is bond to the previous comment 3, a simple figure might achieve more v.s. awful lots of text. 5) Regarding to multi-interfaced, one short additional section might be helpful to clarify potential issues. As described in Section 1, "if a node is multi-interfaced. In such cases nodes may choose to prefer IPv4 or alternative network interface in order to avoid traversal through protocol translators." for the scenario where multiple NAT64/DNS64 are deployed on different accesses, how to utilize the learned Pref64 selectively and properly is a general problem. Following the ideas in RFC 6418, the synthesized AAAA record and the learned Pref64 are guaranteed to be valid only on the network from which such knowledge is obtained. So the multi-interfaced hosts SHOULD distinguish the learned Pref64 and its usage (e.g. performing local synthesis) from different networks in order to avoid potential conflicts. a brief section like Multi-interfaced Host Considerations In general, this draft is well written. The security and connectivity sections had significant improvement from the previous versions. -- Aaron On 02/06/12 04:07, Dave Thaler wrote: > This email initiates a two-week Working Group Last Call on > draft-ietf-behave-nat64-discovery-heuristic-09, to conclude > Friday June 15th. Hopefully that will give some time before > our next interim meeting to review the comments and > have proposed resolutions ready to discuss at the > June 21st interim meeting. > > We need at least 5 reviewers to comment on the doc > (even if just saying "loos good"). > > -Dave Thaler > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From ajs@anvilwalrusden.com Mon Jun 11 07:51:28 2012 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 9D52B21F8625 for ; Mon, 11 Jun 2012 07:51:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 ntb0bp4uFEvU for ; Mon, 11 Jun 2012 07:51:28 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 010A421F8611 for ; Mon, 11 Jun 2012 07:51:27 -0700 (PDT) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id ECB191ECB41C for ; Mon, 11 Jun 2012 14:51:26 +0000 (UTC) Date: Mon, 11 Jun 2012 10:51:25 -0400 From: Andrew Sullivan To: behave@ietf.org Message-ID: <20120611145125.GC11684@mail.yitter.info> References: <9B57C850BB53634CACEC56EF4853FF653B62BDA4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B62BDA4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09 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, 11 Jun 2012 14:51:28 -0000 Dear colleagues, On Sat, Jun 02, 2012 at 01:07:24AM +0000, Dave Thaler wrote: > This email initiates a two-week Working Group Last Call on > draft-ietf-behave-nat64-discovery-heuristic-09, to conclude I read this draft. First, as I've said before for the record, I think this is a bad way to do all of this. I accept that it's the way people are doing it anyway, so I think it is better to write it down. With that proviso, I think this document is ready to be published. It's still a bad way to do it. At the end of section 3: […]it SHALL repeat the discovery process when one third of the Time-To-Live of the Well-Known Name's synthetic AAAA DNS response is remaining. This should probably say instead "when one third (or less) of the original Time To Live…." The "or less" avoids having to time this precisely and the "original" is to make clear what is being compared against. These are both nits. I think this has been pointed out before: section 3.1.1 depends either on the reverse tree in which the NAT64 exists having a DS at the parent or else a locally-configured trust anchor. Should this be noted? (Maybe it isn't necessary. I probably should, but don't, know whether all RIRs are signing their reverse trees yet. I know ARIN and RIPE do.) I think either section 3.1.2 or the Security Considerations should state explicitly that it is impossible to use this heuristic and DNSSEC in an unknown network, which effectively means that DNSSEC and NAT64 cannot be used in coffee shops. (It just occurred to me this minute that there might be some sort of tricky DLV-style thing one could do, but I haven't thought about it seriously.) Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From teemu.savolainen@nokia.com Tue Jun 12 04:02:33 2012 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 44E4321F8471 for ; Tue, 12 Jun 2012 04:02:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 LXRYZAmjivMD for ; Tue, 12 Jun 2012 04:02:32 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 6049E21F8470 for ; Tue, 12 Jun 2012 04:02:32 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (in-mx.nokia.com [10.160.244.32]) by mgw-da01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q5CB2D2h003225; Tue, 12 Jun 2012 14:02:18 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.26]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 12 Jun 2012 14:02:17 +0300 Received: from 008-AM1MPN1-053.mgdnok.nokia.com ([169.254.3.37]) by 008-AM1MMR1-010.mgdnok.nokia.com ([65.54.30.26]) with mapi id 14.02.0283.004; Tue, 12 Jun 2012 13:02:16 +0200 From: To: , Thread-Topic: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09 Thread-Index: AQHNR+G9CBCjjZ1MSUejEPV+sICjIpb2eW/g Date: Tue, 12 Jun 2012 11:02:15 +0000 Message-ID: <916CE6CF87173740BC8A2CE4430969620439DD7C@008-AM1MPN1-053.mgdnok.nokia.com> References: <9B57C850BB53634CACEC56EF4853FF653B62BDA4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <20120611145125.GC11684@mail.yitter.info> In-Reply-To: <20120611145125.GC11684@mail.yitter.info> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Nokia Internal Use Only;Project=None; x-titus-version: 3.3.8.1 x-headerinfofordlp: None x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7Ili3MCvCLXmrxYjzLlJRY6GRYSEESzssJdyl1KtGXxHbRz0f/N8DTFypsncJtFw5H6dEgLNn6I2DYQI1slWstWQLhts4Ao1Rvb7G9B7pZe+oW16aK60T/IZngo/xmoWZz4wl3U9iTRcWTIqdcQ9m+D6PMygWim2QOfgvTOlhx5yWE5M3n/txRnmqEif0/5bbQ+J8mO2cgxvdGCXg3S53/kMBDEDpT6rEg0W0aLtjGxqfiUPHRHRyqxYxC1TLq7ISAU6PK2jG5Ob6ktz5oQfnmV8= x-originating-ip: [10.163.29.34] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 12 Jun 2012 11:02:17.0106 (UTC) FILETIME=[D479EF20:01CD488A] X-Nokia-AV: Clean Subject: Re: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09 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, 12 Jun 2012 11:02:33 -0000 SGkgQW5kcmV3LA0KDQpUaGFuayB5b3UgZm9yIHlvdXIgY29tbWVudHMsIHJlc3BvbnNlcyBpbmxp bmU6DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogYmVoYXZlLWJvdW5j ZXNAaWV0Zi5vcmcgW21haWx0bzpiZWhhdmUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmDQo+ IE9mIGV4dCBBbmRyZXcgU3VsbGl2YW4NCj4gU2VudDogMTEuIGtlc8Oka3V1dGEgMjAxMiAxNzo1 MQ0KPiBUbzogYmVoYXZlQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbQkVIQVZFXSBMYXN0IGNh bGw6IGRyYWZ0LWlldGYtYmVoYXZlLW5hdDY0LWRpc2NvdmVyeS1oZXVyaXN0aWMtMDkNCj4gDQo+ IERlYXIgY29sbGVhZ3VlcywNCj4gDQo+IE9uIFNhdCwgSnVuIDAyLCAyMDEyIGF0IDAxOjA3OjI0 QU0gKzAwMDAsIERhdmUgVGhhbGVyIHdyb3RlOg0KPiA+IFRoaXMgZW1haWwgaW5pdGlhdGVzIGEg dHdvLXdlZWsgV29ya2luZyBHcm91cCBMYXN0IENhbGwgb24NCj4gPiBkcmFmdC1pZXRmLWJlaGF2 ZS1uYXQ2NC1kaXNjb3ZlcnktaGV1cmlzdGljLTA5LCB0byBjb25jbHVkZQ0KPiANCj4gSSByZWFk IHRoaXMgZHJhZnQuDQo+IA0KPiBGaXJzdCwgYXMgSSd2ZSBzYWlkIGJlZm9yZSBmb3IgdGhlIHJl Y29yZCwgSSB0aGluayB0aGlzIGlzIGEgYmFkIHdheSB0byBkbyBhbGwgb2YgdGhpcy4NCj4gSSBh Y2NlcHQgdGhhdCBpdCdzIHRoZSB3YXkgcGVvcGxlIGFyZSBkb2luZyBpdCBhbnl3YXksIHNvIEkg dGhpbmsgaXQgaXMgYmV0dGVyIHRvDQo+IHdyaXRlIGl0IGRvd24uICBXaXRoIHRoYXQgcHJvdmlz bywgSSB0aGluayB0aGlzIGRvY3VtZW50IGlzIHJlYWR5IHRvIGJlDQo+IHB1Ymxpc2hlZC4gIEl0 J3Mgc3RpbGwgYSBiYWQgd2F5IHRvIGRvIGl0Lg0KPiANCj4gQXQgdGhlIGVuZCBvZiBzZWN0aW9u IDM6DQo+IA0KPiAgICAgICAgIFvigKZdaXQgU0hBTEwgcmVwZWF0IHRoZSBkaXNjb3ZlcnkNCj4g ICAgcHJvY2VzcyB3aGVuIG9uZSB0aGlyZCBvZiB0aGUgVGltZS1Uby1MaXZlIG9mIHRoZSBXZWxs LUtub3duIE5hbWUncw0KPiAgICBzeW50aGV0aWMgQUFBQSBETlMgcmVzcG9uc2UgaXMgcmVtYWlu aW5nLg0KPiANCj4gVGhpcyBzaG91bGQgcHJvYmFibHkgc2F5IGluc3RlYWQgIndoZW4gb25lIHRo aXJkIChvciBsZXNzKSBvZiB0aGUgb3JpZ2luYWwgVGltZQ0KPiBUbyBMaXZl4oCmLiIgIFRoZSAi b3IgbGVzcyIgYXZvaWRzIGhhdmluZyB0byB0aW1lIHRoaXMgcHJlY2lzZWx5IGFuZCB0aGUgIm9y aWdpbmFsIg0KPiBpcyB0byBtYWtlIGNsZWFyIHdoYXQgaXMgYmVpbmcgY29tcGFyZWQgYWdhaW5z dC4gIFRoZXNlIGFyZSBib3RoIG5pdHMuDQoNCkdvb2QgcG9pbnQgYW5kIEkgYWdyZWUsIHdpbGwg Zml4Lg0KDQo+IEkgdGhpbmsgdGhpcyBoYXMgYmVlbiBwb2ludGVkIG91dCBiZWZvcmU6IHNlY3Rp b24gMy4xLjEgZGVwZW5kcyBlaXRoZXIgb24gdGhlDQo+IHJldmVyc2UgdHJlZSBpbiB3aGljaCB0 aGUgTkFUNjQgZXhpc3RzIGhhdmluZyBhIERTIGF0IHRoZSBwYXJlbnQgb3IgZWxzZSBhDQo+IGxv Y2FsbHktY29uZmlndXJlZCB0cnVzdCBhbmNob3IuICBTaG91bGQgdGhpcyBiZSBub3RlZD8gIChN YXliZSBpdCBpc24ndA0KPiBuZWNlc3NhcnkuICBJIHByb2JhYmx5IHNob3VsZCwgYnV0IGRvbid0 LCBrbm93IHdoZXRoZXIgYWxsIFJJUnMgYXJlIHNpZ25pbmcgdGhlaXINCj4gcmV2ZXJzZSB0cmVl cyB5ZXQuICBJIGtub3cgQVJJTiBhbmQgUklQRSBkby4pDQoNCkkgdGhvdWdodCByZXZlcnNlIHRy ZWUgZG9lcyBub3QgcmVxdWlyZSBzaWduaW5nLiBUaGUgbm9kZSBwZXJmb3JtcyByZXZlcnNlIHF1 ZXJ5IGF0IHNlY3Rpb24gMy4xLjIgc3RlcCAyIGFuZCB0aGlzIHNob3VsZCByZXN1bHQgaW4gTkFU NjQgRlFETiB0aGF0IGlzIGluIG5vZGUncyBsaXN0IG9mIHRydXN0ZWQgZG9tYWlucyAoc3RlcCAz KSwgYW5kIGFmdGVyIHRoYXQgbm9kZSBzZW5kcyBBQUFBIHF1ZXJ5IGFuZCB2ZXJpZmllcyByZXNw b25zZSB0byB0aGF0LiBJZiB0aGUgKGF0dGFja2VyJ3MgbWFsaWNpb3VzIHJlc3BvbnNlKSBQVFIg cmVjb3JkIGhhcyBuYW1lIG9mIHNvbWUgbm9uLXRydXN0ZWQgZG9tYWluLCB0aGUgRE5TU0VDIGNh cGFibGUgbm9kZSBjYW4gcmVqZWN0IHRoZSByZXNwb25zZS4NCg0KPiBJIHRoaW5rIGVpdGhlciBz ZWN0aW9uIDMuMS4yIG9yIHRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBzaG91bGQgc3RhdGUg ZXhwbGljaXRseQ0KPiB0aGF0IGl0IGlzIGltcG9zc2libGUgdG8gdXNlIHRoaXMgaGV1cmlzdGlj IGFuZCBETlNTRUMgaW4gYW4gdW5rbm93biBuZXR3b3JrLA0KPiB3aGljaCBlZmZlY3RpdmVseSBt ZWFucyB0aGF0IEROU1NFQyBhbmQNCj4gTkFUNjQgY2Fubm90IGJlIHVzZWQgaW4gY29mZmVlIHNo b3BzLiAgKEl0IGp1c3Qgb2NjdXJyZWQgdG8gbWUgdGhpcyBtaW51dGUgdGhhdA0KPiB0aGVyZSBt aWdodCBiZSBzb21lIHNvcnQgb2YgdHJpY2t5IERMVi1zdHlsZSB0aGluZyBvbmUgY291bGQgZG8s IGJ1dCBJIGhhdmVuJ3QNCj4gdGhvdWdodCBhYm91dCBpdCBzZXJpb3VzbHkuKQ0KDQpXaXRob3V0 IHRoaXMgaGV1cmlzdGljIGluIHBsYXkuLi4NCjEpIElQdjYtb25seSBjb2ZmZWUgc2hvcCBjb3Vs ZCBub3QgdXNlIE5BVDY0IGFuZCBETlNTRUMgdG9nZXRoZXIgd2VsbCwgYXMgYWxsIHN5bnRoZXRp YyBBQUFBIHJlY29yZHMgd291bGQgYmUgZHJvcHBlZCBieSBob3N0ICg9bm8gY29ubmVjdGl2aXR5 IHRvIElQdjQtb25seSBkZXN0aW5hdGlvbnMpDQoyKSBEdWFsLXN0YWNrIGNvZmZlZSBzaG9wIHdv dWxkIHdvcmsgd2l0aCBETlNTRUMgYXMgdGhlIGhvc3Qgd291bGQgZHJvcCBhbGwgc3ludGhldGlj IEFBQUEgcmVjb3JkcyAoaGVuY2UgY29ubmVjdGlvbnMgdG8gSVB2NC1vbmx5IGRlc3RpbmF0aW9u cyB3b3VsZCBnbyB2aWEgSVB2NCkNCg0KTm93LCB3aXRoIHRoZSBoZXVyaXN0aWMuLg0KMSkgSVB2 Ni1vbmx5IGNvZmZlZSBzaG9wIGNvdWxkIG5vdCBzdXBwb3J0IE5BVDY0IGFuZCBETlNTRUMgdG9n ZXRoZXIsIGFzIHRoZSBoZXVyaXN0aWNzIGNvdWxkIG5vdCBkZXRlcm1pbmUgUHJlZjY0OjovbiBy ZWxpYWJseSAoPW5vIGNvbm5lY3Rpdml0eSB0byBJUHY0LW9ubHkgZGVzdGluYXRpb25zIGFzIGxv Y2FsIHN5bnRoZXNpcyBpbXBvc3NpYmxlKQ0KMikgRHVhbC1zdGFjayBjb2ZmZWUgc2hvcCB3b3Vs ZCB3b3JrIHdpdGggRE5TU0VDLCBldmVuIGlmIGhvc3QgY291bGQgbm90IGRldGVybWluZSBQcmVm NjQ6Oi9uIChjb25uZWN0aW9ucyB0byBJUHY0LW9ubHkgZGVzdGluYXRpb25zIHdvdWxkIGdvIHZp YSBJUHY0KQ0KDQpTbyBoZXVyaXN0aWNzIGRvZXMgbm90IHJlYWxseSBjaGFuZ2UgdGhlIHBpY3R1 cmUsIHJpZ2h0PyBPbmx5IHRoaW5nIHRoYXQgY2hhbmdlcyBpcyB0aGF0IGluc3RlYWQgb2YgZmFp bGluZyB0byB2YWxpZGF0ZSBzeW50aGV0aWMgQUFBQSByZWNvcmRzIGZyb20gRE5TNjQsIHRoZSBo b3N0IGZhaWxzIHRvIHN5bnRoZXNpemUgQUFBQSByZWNvcmRzIGJ5IGl0c2VsZj8NCg0KQmVzdCBy ZWdhcmRzLA0KDQoJVGVlbXUNCg== From teemu.savolainen@nokia.com Tue Jun 12 04:34:15 2012 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 5203721F865C for ; Tue, 12 Jun 2012 04:34:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 FFd8PI417Ep8 for ; Tue, 12 Jun 2012 04:34:14 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 6C75121F8657 for ; Tue, 12 Jun 2012 04:34:13 -0700 (PDT) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-da02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q5CBW6VX031621; Tue, 12 Jun 2012 14:32:07 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.57]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 12 Jun 2012 14:32:05 +0300 Received: from 008-AM1MPN1-053.mgdnok.nokia.com ([169.254.3.37]) by 008-AM1MMR1-002.mgdnok.nokia.com ([65.54.30.57]) with mapi id 14.02.0283.004; Tue, 12 Jun 2012 13:32:05 +0200 From: To: , Thread-Topic: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09 Thread-Index: AQHNR9L/M+mV+0EZrUqrWi6anmUdUZb2hgnQ Date: Tue, 12 Jun 2012 11:32:04 +0000 Message-ID: <916CE6CF87173740BC8A2CE4430969620439DF86@008-AM1MPN1-053.mgdnok.nokia.com> References: <9B57C850BB53634CACEC56EF4853FF653B62BDA4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <4FD5ED34.8090703@cs.helsinki.fi> In-Reply-To: <4FD5ED34.8090703@cs.helsinki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Nokia Internal Use Only;Project=None; x-titus-version: 3.3.8.1 x-headerinfofordlp: None x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7Ili3MCvCLXmrxYjzLlJRY6FHY/pHjF6tFjgSe2JwmNBmRPgvRO9PTHSy6iVyvbVrfjFTfBeIiJxDMl435gppXWJM9ioOFyE1MciyhwUjL5O1d0Wu0m9Qw1lMfT4vy6hM/SZnJ5KJXhAZvyzfBr4AM8ngFE8ebkwaL/dXbpJmXNaDKESunn1ijQdKRh8bfHWaAbil8FJSf0e2NjaXTMbFeuhkBshLubOMLW2ouY/855XU/PNE6yW1FNSTPOIiQoSxV9CZ+vYekUdIRYox+7HWMvk= x-originating-ip: [10.163.29.34] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 12 Jun 2012 11:32:06.0009 (UTC) FILETIME=[FEBEDE90:01CD488E] X-Nokia-AV: Clean Cc: dthaler@microsoft.com Subject: Re: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09 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, 12 Jun 2012 11:34:15 -0000 Hi Aaron, Thank you for your review, responses inline: > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf > Of ext Aaron Yi DING > Sent: 11. kes=E4kuuta 2012 16:06 > To: behave@ietf.org > Cc: Dave Thaler > Subject: Re: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuris= tic-09 >=20 > Hello, >=20 > A few comments on this WG I-D, > draft-ietf-behave-nat64-discovery-heuristic-09 >=20 > 1) Section 3 the first paragraph, "The node MAY also need to perform DNS > query for the A record of the well-know name in order to learn what is th= e IPv4 > address of the well-known name and if the A record even exists". >=20 > The phrase MAY is bit unclear to me, because in Section 7, there is such > description, "A node SHOULD implement validating DNSSEC resolver for > validating the A response of the well-known name query." The MAY refers to host making DNS A query at first place (host MAY omit A q= uery as the well-known name will have well-known IPv4 address). But if host= makes DNS A query, it SHOULD verify the response. > It is unnecessary to perform redundant A record query for WKP; but for NS= P, > such query is probably required.=20 I think that for sake of simplicity we do not need to differentiate procedu= re between WKP and NSP (but I ack that a host could first do AAAA query and= in case of non-WKP AAAA reply, then make A query to find out what is the a= ddress host should search for:) >So for clarity, would it be good to state as > such: > > "The node MAY also need to perform DNS query for the A record of the well= - > know name in order to learn what is the IPv4 address of the well-known na= me > and if the A record even exists (in the case of identifying Network-Speci= fic > Prefix, the node SHOULD perform a secure DNS A query to validate the A > record received". This is ok for me - to normatively say SHOULD here in addition (or maybe pe= rhaps instead) of just stating that in Security Considerations. But as said= I'd prefer not differentiate procedures between NSP and WKP, so maybe some= thing like: "The node MAY also need to perform DNS query for the A resource record of t= he well-known name in order to learn what is the IPv4 address of the well-k= nown name and if the A resource record even exists (see also Section 6 Exit= Strategy). The node SHOULD use a secure channel for DNS A resource record = query or validate the DNS A resource record response with DNSSEC." > 2) Section 3 the fifth paragraph, "In case another instance of the value= is found > inside the IPv6, the node shall repeat the search with another IPv4 addre= ss, if > possible." >=20 > It's good to add a few words concerning what SHOULD a node do if all of t= he > IPv4 addresses have been tried but failed (some other instances are found= in > the IPv6). True.. but what that might be?-) Maybe: "The node should ensure a 32-bit IPv4 address value is present only once in= an IPv6 address. In case another instance of the value is found inside th= e IPv6, the node shall repeat the search with another IPv4 address, if poss= ible. In case the Pref64::/n cannot be unambiguously determined from an IPv= 6 address, the node MUST fail the Pref64::/n discovery procedure for that I= Pv6 address." ? > 3) Section 3.1.2, the description is very concise and clear here. > However, one simple figure illustrating the message flow and major > components involved in such secure learning will improve the overall clar= ity. This would perhaps mean new section like "3.1.3 Example message flow"? Let = me consider it - would others wish to see an illustrative figure as well? > 4) Also in Section 3.1.2, I suppose the network Entity responding to step= 2 and > step 4 could be DNS64 which is controlled by the operator, but in the tex= t, no > text referring to this detail. This comment is bond to the previous comme= nt 3, a > simple figure might achieve more v.s. > awful lots of text. It does not have to be the DNS64, in fact. The PTR query should work with a= ny recursive DNS server host has access to (even those from other interface= s) and also the AAAA query for NAT64 FQDN can be sent to any recursive DNS = server. Of course the host can send queries to the DNS64 (and for sake of c= larity I think that would be the entity in the possible future illustrative= figure). > 5) Regarding to multi-interfaced, one short additional section might be h= elpful > to clarify potential issues. >=20 > As described in Section 1, "if a node is multi-interfaced. In such cases = nodes > may choose to prefer IPv4 or alternative network interface in order to av= oid > traversal through protocol translators." > for the scenario where multiple NAT64/DNS64 are deployed on different > accesses, how to utilize the learned Pref64 selectively and properly is a= general > problem. Following the ideas in RFC 6418, the synthesized AAAA record an= d > the learned Pref64 are guaranteed to be valid only on the network from wh= ich > such knowledge is obtained. So the multi-interfaced hosts SHOULD distingu= ish > the learned Pref64 and its usage (e.g. performing local synthesis) from d= ifferent > networks in order to avoid potential conflicts. >=20 > a brief section like Multi-interfaced Host Considerations On this I have to disagree. The multi-interface problems, considerations, a= nd solutions should be taken care by MIF WG, e.g. in documents such as the = RFC6418 you referred and draft-ietf-mif-dns-server-selection-09 (this probl= em is described there in section 2.2).=20 > In general, this draft is well written. The security and connectivity sec= tions had > significant improvement from the previous versions. Thank you, Teemu=20 From ajs@anvilwalrusden.com Tue Jun 12 07:09:09 2012 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 E9A4D21F85DF for ; Tue, 12 Jun 2012 07:09:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 epkfF54Y+iHI for ; Tue, 12 Jun 2012 07:09:09 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 5A0F221F85C7 for ; Tue, 12 Jun 2012 07:09:09 -0700 (PDT) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 5016C1ECB41C for ; Tue, 12 Jun 2012 14:09:08 +0000 (UTC) Date: Tue, 12 Jun 2012 10:06:10 -0400 From: Andrew Sullivan To: behave@ietf.org Message-ID: <20120612140610.GA16548@mail.yitter.info> References: <9B57C850BB53634CACEC56EF4853FF653B62BDA4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <20120611145125.GC11684@mail.yitter.info> <916CE6CF87173740BC8A2CE4430969620439DD7C@008-AM1MPN1-053.mgdnok.nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <916CE6CF87173740BC8A2CE4430969620439DD7C@008-AM1MPN1-053.mgdnok.nokia.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09 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, 12 Jun 2012 14:09:10 -0000 Hi, On Tue, Jun 12, 2012 at 11:02:15AM +0000, teemu.savolainen@nokia.com wrote: > > I thought reverse tree does not require signing. The node performs reverse query at section 3.1.2 step 2 and this should result in NAT64 FQDN that is in node's list of trusted domains (step 3), and after that node sends AAAA query and verifies response to that. If the (attacker's malicious response) PTR record has name of some non-trusted domain, the DNSSEC capable node can reject the response. > That's how it's written just now, yes. The difficulty I see is that the decision tree includes step 2, "RDATA of PTR not on trusted list, ask user." The user has, in that context, absolutely no way of making any safe decision. I'd be surprised if the security directorate didn't complain about this. Also, I just realized that step 2 is written as though the result of the PTR query will always be one RR. That need not be the case. There could be more than one (or there could be a CNAME or DNAME chain there). Therefore, I think step 2 of 3.1.2 should say this: 2. Send DNS PTR query for the IPv6 address of the translator (for "ipv6.arpa"), using the Pref64::/n from the step 1 and zeroes for the elements after the actual prefix length. CNAME and DNAME results should be followed according to the rules in [RFC1034], [RFC1035], and [draft-ietf-dnsext-rfc2672bis-dname]*. The ultimate response will include one or more NAT64 FQDNs. * note that that's in the RFC Ed queue. We're waiting for some response from an AD and then it will come out. Or something similar. I should have caught this before. My apologies. > So heuristics does not really change the picture, right? Right. It's ok with me if it just says, "This does not change the picture for 'coffee shop' ad hoc network use," or something like that too. The point is really just that DNS64/NAT64 is never going to be an option wherever you have a lot of people who don't trust the network trying to use it, and also trying to use DNSSEC. If DANE/TLSA takes off, this will be a problem. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From yding@cs.helsinki.fi Tue Jun 12 10:17:28 2012 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 B6B2621F84A5 for ; Tue, 12 Jun 2012 10:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 IG7VBT+ZmH9X for ; Tue, 12 Jun 2012 10:17:28 -0700 (PDT) Received: from mail.cs.helsinki.fi (courier.cs.helsinki.fi [128.214.9.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11F2C21F8468 for ; Tue, 12 Jun 2012 10:17:26 -0700 (PDT) Received: from [128.214.9.154] (wel-33.cs.helsinki.fi [128.214.9.154]) (AUTH: PLAIN yding, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Tue, 12 Jun 2012 20:17:25 +0300 id 000A40A3.4FD779A5.00006803 Message-ID: <4FD779A4.107@cs.helsinki.fi> Date: Tue, 12 Jun 2012 20:17:24 +0300 From: Aaron Yi DING Organization: Helsinki University User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: teemu.savolainen@nokia.com, behave@ietf.org References: <9B57C850BB53634CACEC56EF4853FF653B62BDA4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <4FD5ED34.8090703@cs.helsinki.fi> <916CE6CF87173740BC8A2CE4430969620439DF86@008-AM1MPN1-053.mgdnok.nokia.com> In-Reply-To: <916CE6CF87173740BC8A2CE4430969620439DF86@008-AM1MPN1-053.mgdnok.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dthaler@microsoft.com Subject: Re: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09 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, 12 Jun 2012 17:17:28 -0000 Hi Teemu, On 12/06/12 14:32, teemu.savolainen@nokia.com wrote: > This is ok for me - to normatively say SHOULD here in addition (or maybe perhaps instead) of just stating that in Security Considerations. But as said I'd prefer not differentiate procedures between NSP and WKP, so maybe something like: > "The node MAY also need to perform DNS query for the A resource record of the well-known name in order to learn what is the IPv4 address of the well-known name and if the A resource record even exists (see also Section 6 Exit Strategy). The node SHOULD use a secure channel for DNS A resource record query or validate the DNS A resource record response with DNSSEC." The description above looks good. > True.. but what that might be?-) Maybe: "The node should ensure a > 32-bit IPv4 address value is present only once in an IPv6 address. In > case another instance of the value is found inside the IPv6, the node > shall repeat the search with another IPv4 address, if possible. In > case the Pref64::/n cannot be unambiguously determined from an IPv6 > address, the node MUST fail the Pref64::/n discovery procedure for > that IPv6 address." ? I'm fine with this one. > This would perhaps mean new section like "3.1.3 Example message flow"? > Let me consider it - would others wish to see an illustrative figure > as well? Such illustrative figure for secure learning is my personal opinion. Let's see how others feel about it. > On this I have to disagree. The multi-interface problems, considerations, and solutions should be taken care by MIF WG, e.g. in documents such as the RFC6418 you referred and draft-ietf-mif-dns-server-selection-09 (this problem is described there in section 2.2). Make sense. I agree with you this mif related discussion isn't suitable for this document. Cheers, Aaron From simon.perreault@viagenie.ca Wed Jun 13 10:10:01 2012 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 5807A21F853D for ; Wed, 13 Jun 2012 10:10:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-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 60J3U8npeAwD for ; Wed, 13 Jun 2012 10:09:55 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 7C0BD21F8540 for ; Wed, 13 Jun 2012 10:09:54 -0700 (PDT) Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c064:21a5:83f7:9628:f64f]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 94D804159E; Wed, 13 Jun 2012 13:09:51 -0400 (EDT) Message-ID: <4FD8C95F.2050007@viagenie.ca> Date: Wed, 13 Jun 2012 13:09:51 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1 MIME-Version: 1.0 To: Jean-Francois.TremblayING@videotron.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "behave@ietf.org" Subject: Re: [BEHAVE] Unjustified SHOULDs in CGN requirements 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, 13 Jun 2012 17:10:01 -0000 Thanks. Added all except this one, where you and Senthil have conflicting opinions: On 2012-06-04 09:05, Jean-Francois.TremblayING@videotron.com wrote: >>> (14) REQ-10:CGN implementrers SHOULD make their equipment manageable. >>> Standards-based management using standards such as >>> "Definitions of Managed Objects for NAT" [RFC4008] is >>> (15) RECOMMENDED. >>> >> CGN MUST have a MIB implemented? Seems too restrictive to me. > > +1 on a MUST here, as stated above. The MIB is needed for any serious > deployment IMHO. My two cents: I tend to agree with Senthil (even if both of us are authoring a CGN MIB draft). Not all CGN deployments need to be "serious". It does makes sense to recommend that implementers add SNMP support but some operators may not care about it, and it won't harm the Internet if they don't. So I added this justification: "This requirement is at the SHOULD level to acocunt for the fact that some CGN operators may not need management functionality." Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From internet-drafts@ietf.org Wed Jun 13 10:16:05 2012 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 AD69A21F8611; Wed, 13 Jun 2012 10:16:05 -0700 (PDT) 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 JM-q4JRCyWKG; Wed, 13 Jun 2012 10:16:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39B0721F85A4; Wed, 13 Jun 2012 10:16:05 -0700 (PDT) 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: 4.20 Message-ID: <20120613171605.23941.81814.idtracker@ietfa.amsl.com> Date: Wed, 13 Jun 2012 10:16:05 -0700 Cc: behave@ietf.org Subject: [BEHAVE] I-D Action: draft-ietf-behave-lsn-requirements-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, 13 Jun 2012 17:16:06 -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 Avoida= nce Working Group of the IETF. Title : Common requirements for Carrier Grade NATs (CGNs) Author(s) : Simon Perreault Ikuhei Yamagata Shin Miyakawa Akira Nakagawa Hiroyuki Ashida Filename : draft-ietf-behave-lsn-requirements-07.txt Pages : 20 Date : 2012-06-13 Abstract: This document defines common requirements for Carrier-Grade NAT (CGN). It updates RFC 4787. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-behave-lsn-requirements There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-behave-lsn-requirements-07 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-behave-lsn-requirements-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From simon.perreault@viagenie.ca Wed Jun 13 10:19:56 2012 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 7433511E8089 for ; Wed, 13 Jun 2012 10:19:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-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 Y-hwtBrIc3hz for ; Wed, 13 Jun 2012 10:19:55 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id BFFD221F864C for ; Wed, 13 Jun 2012 10:19:55 -0700 (PDT) Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c064:21a5:83f7:9628:f64f]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 344A24159E; Wed, 13 Jun 2012 13:19:55 -0400 (EDT) Message-ID: <4FD8CBBA.6040502@viagenie.ca> Date: Wed, 13 Jun 2012 13:19:54 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1 MIME-Version: 1.0 To: behave@ietf.org References: <20120613171605.23941.81814.idtracker@ietfa.amsl.com> In-Reply-To: <20120613171605.23941.81814.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Wesley Eddy Subject: Re: [BEHAVE] I-D Action: draft-ietf-behave-lsn-requirements-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, 13 Jun 2012 17:19:56 -0000 On 2012-06-13 13:16, internet-drafts@ietf.org wrote: > Title : Common requirements for Carrier Grade NATs (CGNs) > Author(s) : Simon Perreault > Ikuhei Yamagata > Shin Miyakawa > Akira Nakagawa > Hiroyuki Ashida > Filename : draft-ietf-behave-lsn-requirements-07.txt > Pages : 20 > Date : 2012-06-13 This new revision addresses comments received during AD evaluation. Here's the change log: o Fixed sub-requirement numbering in REQ-1. o Reference update. o Changed REQ-2 back to MUST (from SHOULD). o Added reference to RFC6264 (incremental CGN). o Be more clear that this is not an endorsement of CGN. o Make it clear that this draft is only about IPv4. o Added justification for a bunch of SHOULDs and turned the remaining ones into MUSTs. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From ssenthil@cisco.com Fri Jun 15 11:52:36 2012 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 4278811E8097 for ; Fri, 15 Jun 2012 11:52:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 0aKmBUut-IZG for ; Fri, 15 Jun 2012 11:52:35 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 50DA511E8091 for ; Fri, 15 Jun 2012 11:52:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ssenthil@cisco.com; l=1867; q=dns/txt; s=iport; t=1339786355; x=1340995955; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=U8fXuscJCkGyTXoooXGDVReEfo3iFV04uHgN7fxjRNU=; b=MLk69tX6NEfNWYYTdTxVhum0sb8u4yzGSYnxhPyqG/GLh+TybBPDwb4Z PCok/AvgmKkM6T9GZGJRJn9A3oOw+Dyse5+Oioh8wWGiXr9n1Ri9j9eHh 2679Ttp58jW+ScAirtoyxpsEw7qJRdlm9xljXk1QwAWVuo9Dw0bT3zKXd 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak0JAMGD20+tJV2d/2dsb2JhbAA7CrQjBIEtgQeCHxIBJwIBKhAVCIEdBhMJGYdpC5gpgSigH4s/By6COIMbA5UkgRKEQohDgWaCfIE6 X-IronPort-AV: E=Sophos;i="4.75,779,1330905600"; d="scan'208";a="92915779" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-4.cisco.com with ESMTP; 15 Jun 2012 18:52:32 +0000 Received: from [10.150.26.7] ([10.150.26.7]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q5FIqT9N018085 for ; Fri, 15 Jun 2012 18:52:30 GMT User-Agent: Microsoft-MacOutlook/14.2.2.120421 Date: Fri, 15 Jun 2012 14:52:28 -0400 From: Senthil Sivakumar To: Message-ID: Thread-Topic: New Version Notification for draft-sivakumar-behave-nat-logging-04.txt In-Reply-To: <20120614154451.20816.50744.idtracker@ietfa.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [BEHAVE] New Version Notification for draft-sivakumar-behave-nat-logging-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: Fri, 15 Jun 2012 18:52:36 -0000 A new version of the logging draft is posted that is focused towards using IPFIX Information Elements for NAT logging. Please review and provide feedback. Senthil On 6/14/12 11:44 AM, "internet-drafts@ietf.org" wrote: > >A new version of I-D, draft-sivakumar-behave-nat-logging-04.txt >has been successfully submitted by Senthil Sivakumar and posted to the >IETF repository. > >Filename: draft-sivakumar-behave-nat-logging >Revision: 04 >Title: IPFIX Information Elements for logging NAT Events >Creation date: 2012-06-14 >WG ID: Individual Submission >Number of pages: 14 >URL: >http://www.ietf.org/internet-drafts/draft-sivakumar-behave-nat-logging-04. >txt >Status: >http://datatracker.ietf.org/doc/draft-sivakumar-behave-nat-logging >Htmlized: >http://tools.ietf.org/html/draft-sivakumar-behave-nat-logging-04 >Diff: >http://tools.ietf.org/rfcdiff?url2=draft-sivakumar-behave-nat-logging-04 > >Abstract: > Carrier grade NAT (CGN) devices are required to log events like > creation and deletion of translations and information about the > resources it is managing. The logs are required in many cases to > identify an attacker or a host that was used to launch malicious > attacks and/or for various other purposes of accounting. Since there > is no standard way of logging this information, different NAT devices > behave differently and hence it is difficult to expect a consistent > behavior. The lack of a consistent way makes it difficult to write > the collector applications that would receive this data and process > it to present useful information. This document describes the > information that is required to be logged by the NAT devices. > > > > > >The IETF Secretariat From Tina.Tsou.Zouting@huawei.com Fri Jun 15 15:19:55 2012 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 3027311E8093 for ; Fri, 15 Jun 2012 15:19:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 4QQduj-r0CQd for ; Fri, 15 Jun 2012 15:19:54 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 560FE11E8088 for ; Fri, 15 Jun 2012 15:19:54 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AGY63886; Fri, 15 Jun 2012 18:19:53 -0400 (EDT) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 15 Jun 2012 15:17:52 -0700 Received: from dfweml513-mbx.china.huawei.com ([169.254.3.80]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.01.0323.003; Fri, 15 Jun 2012 15:17:55 -0700 From: Tina TSOU To: "behave@ietf.org" Thread-Topic: New Version Notification for draft-tsou-behave-ftp46-00.txt Thread-Index: AQHNS0OWe9pUmOSW+0+JVCAV3Fig95b78pVA Date: Fri, 15 Jun 2012 22:17:54 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.34.117] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [BEHAVE] FW: New Version Notification for draft-tsou-behave-ftp46-00.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, 15 Jun 2012 22:19:55 -0000 Rm9yIHlvdXIgY29tbWVudHMuDQoNClRpbmENCjQwOC04NTktNDk5Ng0KDQotLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50 ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANClNlbnQ6IEZyaWRheSwgSnVuZSAxNSwgMjAxMiAzOjEw IFBNDQpUbzogVGluYSBUU09VDQpDYzogc2ltb24ucGVycmVhdWx0QHZpYWdlbmllLmNhOyBIdWFu Z2ppbmcNClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtdHNvdS1i ZWhhdmUtZnRwNDYtMDAudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXRzb3Ut YmVoYXZlLWZ0cDQ2LTAwLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBU aW5hIFRzb3UgYW5kIHBvc3RlZCB0byB0aGUNCklFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6 CSBkcmFmdC10c291LWJlaGF2ZS1mdHA0Ng0KUmV2aXNpb246CSAwMA0KVGl0bGU6CQkgQW4gRlRQ IEFwcGxpY2F0aW9uIExheWVyIEdhdGV3YXkgKEFMRykgZm9yIElQdjQtdG8tSVB2NiBUcmFuc2xh dGlvbg0KQ3JlYXRpb24gZGF0ZToJIDIwMTItMDYtMTUNCldHIElEOgkJIEluZGl2aWR1YWwgU3Vi bWlzc2lvbg0KTnVtYmVyIG9mIHBhZ2VzOiA3DQpVUkw6ICAgICAgICAgICAgIGh0dHA6Ly93d3cu aWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXRzb3UtYmVoYXZlLWZ0cDQ2LTAwLnR4dA0K U3RhdHVzOiAgICAgICAgICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXRz b3UtYmVoYXZlLWZ0cDQ2DQpIdG1saXplZDogICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LXRzb3UtYmVoYXZlLWZ0cDQ2LTAwDQoNCg0KQWJzdHJhY3Q6DQogICBBbiBGVFAg QUxHIGZvciBOQVQ2NCB3YXMgZGVmaW5lZCBpbiBSRkMgNjM4NC4gIEl0cyBzY29wZSB3YXMgbGlt aXRlZA0KICAgdG8gYW4gSVB2NiBjbGllbnQgY29ubmVjdGluZyB0byBhbiBJUHY0IHNlcnZlci4g IFRoaXMgbWVtbyB1cGRhdGVzDQogICBSRkMgNjM4NCB3aXRoIHRoZSBjYXNlIG9mIGFuIElQdjQg Y2xpZW50IGNvbm5lY3RpbmcgdG8gYW4gSVB2Ng0KICAgc2VydmVyLg0KDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgDQoNCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg== From teemu.savolainen@nokia.com Mon Jun 18 11:59:16 2012 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 4675011E8080 for ; Mon, 18 Jun 2012 11:59:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 wid9babwufNN for ; Mon, 18 Jun 2012 11:59:15 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 89FB011E807F for ; Mon, 18 Jun 2012 11:59:15 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (in-mx.nokia.com [10.160.244.31]) by mgw-da01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q5IIx6OL011059; Mon, 18 Jun 2012 21:59:08 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.23]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 18 Jun 2012 21:59:07 +0300 Received: from 008-AM1MPN1-053.mgdnok.nokia.com ([169.254.3.37]) by 008-AM1MMR1-007.mgdnok.nokia.com ([65.54.30.23]) with mapi id 14.02.0283.004; Mon, 18 Jun 2012 20:59:07 +0200 From: To: , Thread-Topic: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09 Thread-Index: AQHNR+G9CBCjjZ1MSUejEPV+sICjIpb2eW/ggAAeTwCACWHxEA== Date: Mon, 18 Jun 2012 18:59:06 +0000 Message-ID: <916CE6CF87173740BC8A2CE443096962043AD0E0@008-AM1MPN1-053.mgdnok.nokia.com> References: <9B57C850BB53634CACEC56EF4853FF653B62BDA4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <20120611145125.GC11684@mail.yitter.info> <916CE6CF87173740BC8A2CE4430969620439DD7C@008-AM1MPN1-053.mgdnok.nokia.com> <20120612140610.GA16548@mail.yitter.info> In-Reply-To: <20120612140610.GA16548@mail.yitter.info> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Nokia Internal Use Only;Project=None; x-titus-version: 3.3.8.1 x-headerinfofordlp: None x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7Ili3MCvCLXmrxYjzLlJRY6GRYSEESzssJdyl1KtGXxHbRz0f/N8DTFypsncJtFw5H6dEgLNn6I2DYQI1slWstWQLhts4Ao1Rvb7G9B7pZe+oW16aK60T/IZngo/xmoWZz4wl3U9iTRcWTIqdcQ9m+D6PMygWim2QOfgvTOlhx5yWE5M3n/txRnmqEif0/5bbQ+J8mO2cgxvdGCXg3S53/kMBDEDpT6rEg0W0aLtjGxqfiUPHRHRyqxYxC1TLq7ISAU6PK2jG5Ob6ktz5oQfnmV8= x-originating-ip: [10.163.24.182] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 18 Jun 2012 18:59:07.0172 (UTC) FILETIME=[6FE20E40:01CD4D84] X-Nokia-AV: Clean Subject: Re: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09 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, 18 Jun 2012 18:59:16 -0000 Hi Andrew, > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf > Of ext Andrew Sullivan > Sent: 12. kes=E4kuuta 2012 17:06 > To: behave@ietf.org > Subject: Re: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuris= tic- > 09 >=20 > Hi, >=20 > On Tue, Jun 12, 2012 at 11:02:15AM +0000, teemu.savolainen@nokia.com > wrote: > > > > I thought reverse tree does not require signing. The node performs reve= rse > query at section 3.1.2 step 2 and this should result in NAT64 FQDN that i= s in > node's list of trusted domains (step 3), and after that node sends AAAA q= uery > and verifies response to that. If the (attacker's malicious response) PTR= record > has name of some non-trusted domain, the DNSSEC capable node can reject > the response. > > >=20 > That's how it's written just now, yes. The difficulty I see is that the = decision > tree includes step 2, "RDATA of PTR not on trusted list, ask user." The = user > has, in that context, absolutely no way of making any safe decision. I'd= be > surprised if the security directorate didn't complain about this. That's something similar to the case with web pages with expired certificat= es.. How can you manage without asking user ok? Unless host just simply fai= ls the prefix discovery... and perhaps display that fact in some "problem s= olving wizard" as cause for prefix discovery failure? =20 > Also, I just realized that step 2 is written as though the result of the = PTR query > will always be one RR. That need not be the case. > There could be more than one (or there could be a CNAME or DNAME chain > there). Therefore, I think step 2 of 3.1.2 should say this: >=20 > 2. Send DNS PTR query for the IPv6 address of the translator (for > "ipv6.arpa"), using the Pref64::/n from the step 1 and zeroes for > the elements after the actual prefix length. CNAME and DNAME > results should be followed according to the rules in [RFC1034], > [RFC1035], and [draft-ietf-dnsext-rfc2672bis-dname]*. The > ultimate response will include one or more NAT64 FQDNs. >=20 > * note that that's in the RFC Ed queue. We're waiting for some response = from > an AD and then it will come out. This is fine, thank you. Tthen in step 3 the node should compare all the NA= T64 FQDNs received to the list of trusted domains (and pick one that has ma= tch). > Or something similar. I should have caught this before. My apologies. No problem, especially as we are still in WG process:) > > So heuristics does not really change the picture, right? >=20 > Right. It's ok with me if it just says, "This does not change the pictur= e for > 'coffee shop' ad hoc network use," or something like that too. The point= is > really just that DNS64/NAT64 is never going to be an option wherever you > have a lot of people who don't trust the network trying to use it, and al= so > trying to use DNSSEC. If DANE/TLSA takes off, this will be a problem. Ok, I'll attempt to write that issue down. Best regards, Teemu From ajs@anvilwalrusden.com Mon Jun 18 13:02:35 2012 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 7193D21F8625 for ; Mon, 18 Jun 2012 13:02:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 jRi7hoFllTlh for ; Mon, 18 Jun 2012 13:02:35 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id DBAFE21F85FD for ; Mon, 18 Jun 2012 13:02:34 -0700 (PDT) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 216E11ECB41D for ; Mon, 18 Jun 2012 20:02:34 +0000 (UTC) Date: Mon, 18 Jun 2012 16:02:32 -0400 From: Andrew Sullivan To: behave@ietf.org Message-ID: <20120618200232.GU32683@mail.yitter.info> References: <9B57C850BB53634CACEC56EF4853FF653B62BDA4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <20120611145125.GC11684@mail.yitter.info> <916CE6CF87173740BC8A2CE4430969620439DD7C@008-AM1MPN1-053.mgdnok.nokia.com> <20120612140610.GA16548@mail.yitter.info> <916CE6CF87173740BC8A2CE443096962043AD0E0@008-AM1MPN1-053.mgdnok.nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <916CE6CF87173740BC8A2CE443096962043AD0E0@008-AM1MPN1-053.mgdnok.nokia.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09 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, 18 Jun 2012 20:02:35 -0000 On Mon, Jun 18, 2012 at 06:59:06PM +0000, teemu.savolainen@nokia.com wrote: > > has, in that context, absolutely no way of making any safe decision. I'd be > > surprised if the security directorate didn't complain about this. > > That's something similar to the case with web pages with expired > certificates. Yep. The security guys, in my experience, jump up and down about this. It might be worth asking someone for an early review. I can't see what you're going to do except ask the user, other than immediately fail; and in that case, of course, you're going to have to give the user an interface anyway. I'd ask for a secdir review specifically of this, though, because it's the sort of thing I know people have strong opinions about. > > [RFC1035], and [draft-ietf-dnsext-rfc2672bis-dname]*. The > > ultimate response will include one or more NAT64 FQDNs. > > > > * note that that's in the RFC Ed queue. We're waiting for some response from > > an AD and then it will come out. > > This is fine, thank you. Tthen in step 3 the node should compare all the NAT64 FQDNs received to the list of trusted domains (and pick one that has match). > Right. And, hurray, http://tools.ietf.org/html/rfc6672 is out. So that's your reference now. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From simon.perreault@viagenie.ca Mon Jun 18 13:35:08 2012 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 F0E1C11E80A3 for ; Mon, 18 Jun 2012 13:35:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-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 ZpgbwpVTEYNN for ; Mon, 18 Jun 2012 13:35:07 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 0A7E011E8095 for ; Mon, 18 Jun 2012 13:35:07 -0700 (PDT) Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c064:ec6c:4066:6efd:d9f4]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 64CEA400AB for ; Mon, 18 Jun 2012 16:35:06 -0400 (EDT) Message-ID: <4FDF90F9.3010704@viagenie.ca> Date: Mon, 18 Jun 2012 16:35:05 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1 MIME-Version: 1.0 To: behave@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] New Version Notification for draft-sivakumar-behave-nat-logging-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: Mon, 18 Jun 2012 20:35:08 -0000 On 2012-06-15 14:52, Senthil Sivakumar wrote: > A new version of the logging draft is posted that is focused towards using > IPFIX Information > Elements for NAT logging. Please review and provide feedback. Looks good! Question: why did you unite vlan ID and VRF ID? Aren't they orthogonal things? Observation: the term BIB is defined in RFC6146 but only in the context of NAT64. Yet this draft uses it in the context of NAT44. I foresee problems. For example, it is not clear how a fully symmetric NAT (which has no BIB) would use this. Would it only log session events and never BIB events? Also, what about NATs that don't track sessions? Would they just log BIB events and never session events? What about NAT46 and NAT66? Are they supported? Lastly, I see feature overlap between this draft and the MIB draft for the addresses exhausted, ports exhausted, and quota exceeded event. Do we really want to provide two ways of doing the same thing? Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From ssenthil@cisco.com Mon Jun 18 14:02:31 2012 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 DAA0111E80BB for ; Mon, 18 Jun 2012 14:02:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 t7yOjdViD7-a for ; Mon, 18 Jun 2012 14:02:31 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 037A711E80C2 for ; Mon, 18 Jun 2012 14:02:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ssenthil@cisco.com; l=2498; q=dns/txt; s=iport; t=1340053351; x=1341262951; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=VrCu920+bBMg6Deg+KfjIX4n70y0WlkmatQYpNfBN2Q=; b=GIjkBV6fl6fZrCLXaSQhEzOkjAV7IVF3LeabXMnClaFnH3Q41z81DE7v 7DOpXY7hOBZ4TWSIscEvz87NmHGP5qWiSnZVO72BMVkeL3Oo9JQ/dOZPW V1drhybmvBRU11WenU9p/K7hBMH3PY3vjhG6sm/Pm2ES3XFm6KZFJ0LvS U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAG2W30+tJV2b/2dsb2JhbAA7CrVxgQeCGAEBAQMBAQEBDwEUFQExCQcOCBhVMAYBEiKHZAULmF+fbItCBQyGHwOID40VgRKEQohDgWaCfIE7 X-IronPort-AV: E=Sophos;i="4.75,793,1330905600"; d="scan'208";a="93561310" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-3.cisco.com with ESMTP; 18 Jun 2012 21:02:30 +0000 Received: from [10.117.198.133] (rtp-sshnmuga-8914.cisco.com [10.117.198.133]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q5IL2RUU013548; Mon, 18 Jun 2012 21:02:29 GMT User-Agent: Microsoft-MacOutlook/14.2.2.120421 Date: Mon, 18 Jun 2012 17:02:25 -0400 From: Senthil Sivakumar To: Simon Perreault , Message-ID: Thread-Topic: [BEHAVE] New Version Notification for draft-sivakumar-behave-nat-logging-04.txt In-Reply-To: <4FDF90F9.3010704@viagenie.ca> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Subject: Re: [BEHAVE] New Version Notification for draft-sivakumar-behave-nat-logging-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: Mon, 18 Jun 2012 21:02:32 -0000 Thanks for the review. On 6/18/12 4:35 PM, "Simon Perreault" wrote: >On 2012-06-15 14:52, Senthil Sivakumar wrote: >> A new version of the logging draft is posted that is focused towards >>using >> IPFIX Information >> Elements for NAT logging. Please review and provide feedback. > >Looks good! > >Question: why did you unite vlan ID and VRF ID? Aren't they orthogonal >things? There are two information elements one for VLAN ID and one for VRF ID, they are listed under Table 1. In the actual events, I mentioned them as one entity as VlanID/VRF ID, the reason being either one of them is used to uniquely identify a private address but not both. > >Observation: the term BIB is defined in RFC6146 but only in the context >of NAT64. Yet this draft uses it in the context of NAT44. I foresee >problems. Ok, would it help if I change it to NAT44 binding instead of NAT44 BIB? > For example, it is not clear how a fully symmetric NAT (which >has no BIB) would use this. Would it only log session events and never >BIB events? Also, what about NATs that don't track sessions? Would they >just log BIB events and never session events? Correct, the NATs that don=B9t track the full 5 tuple sessions wont log the full session. Similarly the NATs that don=B9t have the Binding database but not the session database will not log the session entry. > >What about NAT46 and NAT66? Are they supported? NAT46 can be accomodated in the NAT64 record itself, can it not? Wondering if we need to address NAT66 as it is neither an RFC nor a product. > >Lastly, I see feature overlap between this draft and the MIB draft for >the addresses exhausted, ports exhausted, and quota exceeded event. Do >we really want to provide two ways of doing the same thing? I was going through the same thoughts myself. But I have had people asking these events to be logged. I think this is where logging is not just for tracking individual users but crosses into the management domain. But I also think that people using SNMP wouldn=B9t want to log these events. Thanks Senthil > >Simon >--=20 >DTN made easy, lean, and smart --> http://postellation.viagenie.ca >NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca >STUN/TURN server --> http://numb.viagenie.ca >_______________________________________________ >Behave mailing list >Behave@ietf.org >https://www.ietf.org/mailman/listinfo/behave From dthaler@microsoft.com Mon Jun 18 16:57:23 2012 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 DDD1911E809A for ; Mon, 18 Jun 2012 16:57:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.668 X-Spam-Level: X-Spam-Status: No, score=-103.668 tagged_above=-999 required=5 tests=[AWL=-0.069, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 W5sRi3kErQ3N for ; Mon, 18 Jun 2012 16:57:23 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe004.messaging.microsoft.com [213.199.154.207]) by ietfa.amsl.com (Postfix) with ESMTP id DF2A511E8073 for ; Mon, 18 Jun 2012 16:57:22 -0700 (PDT) Received: from mail125-am1-R.bigfish.com (10.3.201.248) by AM1EHSOBE003.bigfish.com (10.3.204.23) with Microsoft SMTP Server id 14.1.225.23; Mon, 18 Jun 2012 23:56:01 +0000 Received: from mail125-am1 (localhost [127.0.0.1]) by mail125-am1-R.bigfish.com (Postfix) with ESMTP id 6790240464; Mon, 18 Jun 2012 23:56:01 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC107.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -35 X-BigFish: VS-35(zz9371I542M1432Izz1202hzz1033IL8275bh8275dh186M5eeeKz2fh2a8h668h839h944hd25hf0ah) Received-SPF: pass (mail125-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14HUBC107.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail125-am1 (localhost.localdomain [127.0.0.1]) by mail125-am1 (MessageSwitch) id 1340063759636075_28403; Mon, 18 Jun 2012 23:55:59 +0000 (UTC) Received: from AM1EHSMHS010.bigfish.com (unknown [10.3.201.253]) by mail125-am1.bigfish.com (Postfix) with ESMTP id 8F3292A0048; Mon, 18 Jun 2012 23:55:59 +0000 (UTC) Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS010.bigfish.com (10.3.207.110) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 18 Jun 2012 23:55:58 +0000 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC107.redmond.corp.microsoft.com (157.54.80.67) with Microsoft SMTP Server (TLS) id 14.2.309.3; Mon, 18 Jun 2012 23:57:12 +0000 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.28]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi id 14.02.0309.003; Mon, 18 Jun 2012 16:57:12 -0700 From: Dave Thaler To: "draft-ietf-behave-nat64-discovery-heuristic@tools.ietf.org" Thread-Topic: Last call: draft-ietf-behave-nat64-discovery-heuristic-09 Thread-Index: Ac1AW6tggKyYFn88QeSiVcin492nCQNUTNng Date: Mon, 18 Jun 2012 23:57:12 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B664824@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> References: <9B57C850BB53634CACEC56EF4853FF653B62BDA4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B62BDA4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.90] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "behave@ietf.org" Subject: Re: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09 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, 18 Jun 2012 23:57:24 -0000 My full comments and proposed editorial changes are in=20 http://research.microsoft.com/~dthaler/draft-ietf-behave-nat64-discovery-he= uristic-09.pdf A brief summary of the main technical comments: 1) I didn't follow why an A record query is needed or useful. 2) Guidance on TTL is lacking. How long is "long"?=20 3) Need to update text on how often to repeat the check in the success case= . Saying it MUST be one third the TTL seems overly strict and suboptimal give= n that the TTL itself could be short (like 9 seconds) or long (like 9 months)= and no=20 guidance on that is given. Why not a specific number of seconds/minutes b= efore expiry, rather than a fraction of the TTL? 4) The text in 3.1.2 on verifying the address matches seems wrong (or else I'm missing something), since querying for ipv4only.com will give Pref64::W= KA::0 whereas querying for the NAT64 FQDN will give (per 3.1.1 bullet 2) Pref63::= 0. Those won't match. I'm guessing 3.1.1 bullet 2 is probably in error. -Dave > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of Dave Thaler > Sent: Friday, June 1, 2012 6:07 PM > To: behave@ietf.org > Subject: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-= 09 >=20 > This email initiates a two-week Working Group Last Call on draft-ietf-beh= ave- > nat64-discovery-heuristic-09, to conclude > Friday June 15th. Hopefully that will give some time before > our next interim meeting to review the comments and have proposed > resolutions ready to discuss at the June 21st interim meeting. >=20 > We need at least 5 reviewers to comment on the doc (even if just saying > "loos good"). >=20 > -Dave Thaler >=20 >=20 > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From dthaler@microsoft.com Mon Jun 18 17:00:24 2012 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 D4CD311E80EF for ; Mon, 18 Jun 2012 17:00:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.663 X-Spam-Level: X-Spam-Status: No, score=-103.663 tagged_above=-999 required=5 tests=[AWL=-0.064, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 uDbx-CnrY7uN for ; Mon, 18 Jun 2012 17:00:24 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe004.messaging.microsoft.com [216.32.180.14]) by ietfa.amsl.com (Postfix) with ESMTP id 3547711E8073 for ; Mon, 18 Jun 2012 17:00:24 -0700 (PDT) Received: from mail1-va3-R.bigfish.com (10.7.14.248) by VA3EHSOBE010.bigfish.com (10.7.40.12) with Microsoft SMTP Server id 14.1.225.22; Mon, 18 Jun 2012 23:59:04 +0000 Received: from mail1-va3 (localhost [127.0.0.1]) by mail1-va3-R.bigfish.com (Postfix) with ESMTP id 9F7B8180125 for ; Mon, 18 Jun 2012 23:59:03 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC101.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -27 X-BigFish: VS-27(zz9371I542M1432Izz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25hf0ah) Received-SPF: pass (mail1-va3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14HUBC101.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail1-va3 (localhost.localdomain [127.0.0.1]) by mail1-va3 (MessageSwitch) id 1340063941903588_18969; Mon, 18 Jun 2012 23:59:01 +0000 (UTC) Received: from VA3EHSMHS002.bigfish.com (unknown [10.7.14.248]) by mail1-va3.bigfish.com (Postfix) with ESMTP id D9AE220004C for ; Mon, 18 Jun 2012 23:59:01 +0000 (UTC) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS002.bigfish.com (10.7.99.12) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 18 Jun 2012 23:59:01 +0000 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) with Microsoft SMTP Server (TLS) id 14.2.309.3; Tue, 19 Jun 2012 00:00:10 +0000 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.28]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi id 14.02.0309.003; Mon, 18 Jun 2012 17:00:10 -0700 From: Dave Thaler To: "behave@ietf.org" Thread-Topic: Last call: draft-ietf-behave-nat64-discovery-heuristic-09 Thread-Index: Ac1AW6tggKyYFn88QeSiVcin492nCQNUnPZg Date: Tue, 19 Jun 2012 00:00:09 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B66483D@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> References: <9B57C850BB53634CACEC56EF4853FF653B62BDA4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B62BDA4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.90] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09 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, 19 Jun 2012 00:00:24 -0000 So far I've seen 3 reviews: * Andrew Sullivan * Aaron Yi DING * Dave Thaler We need at least 5 reviews on this document. Can we get two more voluntee= rs? Maybe Simon and/or Marc P.-H.? Anyone else? -Dave > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of Dave Thaler > Sent: Friday, June 1, 2012 6:07 PM > To: behave@ietf.org > Subject: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-= 09 >=20 > This email initiates a two-week Working Group Last Call on draft-ietf-beh= ave- > nat64-discovery-heuristic-09, to conclude > Friday June 15th. Hopefully that will give some time before > our next interim meeting to review the comments and have proposed > resolutions ready to discuss at the June 21st interim meeting. >=20 > We need at least 5 reviewers to comment on the doc (even if just saying > "loos good"). >=20 > -Dave Thaler >=20 >=20 > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From dwing@cisco.com Mon Jun 18 18:51:26 2012 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 A45FC11E80CC for ; Mon, 18 Jun 2012 18:51:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 fOAu0RptqIHG for ; Mon, 18 Jun 2012 18:51:25 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 6316F11E80BB for ; Mon, 18 Jun 2012 18:51:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=3302; q=dns/txt; s=iport; t=1340070684; x=1341280284; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=RjmxSWZ3ykdy+E0qfKo45tCKXJKMuljDCTe5/g47vSg=; b=ImjaVk3Qhmcio+X/RRgUXzI9faUfj1lWXPrYIXvyX74YPEa70vN4XPGn hSMVKMd0DK3aZmYpUBNgZNLgxuzDfWC3dZunhYbDzZ8g2GPH1YcrRd45R ljVTFcLOrUBbm1oCxLLc6jAX7B+TBSJdv8rD7p6/nWveGkmvGJ2c+yH97 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAC7a30+rRDoH/2dsb2JhbABCA6ZrjwWBB4IYAQEBAwEBAQEFCgEXEDQJBwcBAwIJDwIEAQEoBxkOFQoIAQgCBAESCQIXh2QEDJh2n3mLKRSCZYMgA4hChQGIc40FgWaDAIE2 X-IronPort-AV: E=Sophos;i="4.75,795,1330905600"; d="scan'208";a="46858427" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 19 Jun 2012 01:51:24 +0000 Received: from dwingWS ([10.154.162.34]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q5J1pOie025555; Tue, 19 Jun 2012 01:51:24 GMT From: "Dan Wing" To: "'Tina TSOU'" , References: In-Reply-To: Date: Mon, 18 Jun 2012 18:51:23 -0700 Message-ID: <068301cd4dbe$083071d0$18915570$@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: AQHNS0OWe9pUmOSW+0+JVCAV3Fig95b78pVAgATwZXA= Content-Language: en-us Subject: Re: [BEHAVE] FW: New Version Notification for draft-tsou-behave-ftp46-00.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, 19 Jun 2012 01:51:26 -0000 > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of Tina TSOU > Sent: Friday, June 15, 2012 3:18 PM > To: behave@ietf.org > Subject: [BEHAVE] FW: New Version Notification for draft-tsou-behave- > ftp46-00.txt > > For your comments. Why use "EPSV 2", instead of just "EPSV"? Using "EPSV 2" will force another ALG, should there be another NAT64 or NAT46 along the path (to convert it to "EPSV 1"). Draft should clearly say that active mode FTP is not intended to work (or say it works only with passive FTP -- whichever wording feels better). Introduction: When the FTP server is behind NAT, it can publish its service address via a redirect server located in the internet, or via modified DDNS .........^^^^^^^^^^^^^^^ what is a 'redirect server'? A TCP redirector? SOCKS?? FTP proxy?? system, or other possible methods. It is out of the scope of this memo. Why is a _modified_ DDNS needed, and a normal Dynamic DNS inadequate? Basically, I'm not seeing a need for all that uniqueness -- the IPv4-only FTP server just needs to know its port number (hopefully, 21) and IPv6 address, and publish its URL (ftp://ftp.example.com:PORT). That seems the easiest example of how to make such an FTP server work, anyway. Section 3, the Scenarios diagrams should more clearly show which devices are IPv4 and which are IPv6 -- right now it just shows "NAT" and doesn't show if the FTP client or FTP server are IPv6 or IPv4. IPv4 addresses should probably be in the IPv4 example range, rather than 100.1.1.10. The FTP64 ALG document included a command to disable the FTP64 ALG. Should FTP46 have a similar command? A security issue does exist with FTP passive mode -- connection theft. I believe there is an FTP document or two that explain that vulnerability. Or see http://cr.yp.to/ftp/security.html -d > Tina > 408-859-4996 > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Friday, June 15, 2012 3:10 PM > To: Tina TSOU > Cc: simon.perreault@viagenie.ca; Huangjing > Subject: New Version Notification for draft-tsou-behave-ftp46-00.txt > > > A new version of I-D, draft-tsou-behave-ftp46-00.txt > has been successfully submitted by Tina Tsou and posted to the > IETF repository. > > Filename: draft-tsou-behave-ftp46 > Revision: 00 > Title: An FTP Application Layer Gateway (ALG) for IPv4-to- > IPv6 Translation > Creation date: 2012-06-15 > WG ID: Individual Submission > Number of pages: 7 > URL: http://www.ietf.org/internet-drafts/draft-tsou-behave- > ftp46-00.txt > Status: http://datatracker.ietf.org/doc/draft-tsou-behave- > ftp46 > Htmlized: http://tools.ietf.org/html/draft-tsou-behave-ftp46-00 > > > Abstract: > An FTP ALG for NAT64 was defined in RFC 6384. Its scope was limited > to an IPv6 client connecting to an IPv4 server. This memo updates > RFC 6384 with the case of an IPv4 client connecting to an IPv6 > server. > > > > > The IETF Secretariat > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From teemu.savolainen@nokia.com Tue Jun 19 01:57:07 2012 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 D84E321F858D for ; Tue, 19 Jun 2012 01:57:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 a2IeN3lzrVwj for ; Tue, 19 Jun 2012 01:57:07 -0700 (PDT) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id D2F1021F8540 for ; Tue, 19 Jun 2012 01:57:06 -0700 (PDT) Received: from vaebh102.NOE.Nokia.com (in-mx.nokia.com [10.160.244.23]) by mgw-sa02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q5J8uN0Y009198; Tue, 19 Jun 2012 11:56:59 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.57]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 19 Jun 2012 11:56:53 +0300 Received: from 008-AM1MPN1-053.mgdnok.nokia.com ([169.254.3.37]) by 008-AM1MMR1-002.mgdnok.nokia.com ([65.54.30.57]) with mapi id 14.02.0283.004; Tue, 19 Jun 2012 10:56:52 +0200 From: To: , Thread-Topic: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09 Thread-Index: Ac1AW6tggKyYFn88QeSiVcin492nCQNUTNngABJ72YA= Date: Tue, 19 Jun 2012 08:56:52 +0000 Message-ID: <916CE6CF87173740BC8A2CE443096962043AD71A@008-AM1MPN1-053.mgdnok.nokia.com> References: <9B57C850BB53634CACEC56EF4853FF653B62BDA4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B664824@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B664824@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Nokia Internal Use Only;Project=None; x-titus-version: 3.3.8.1 x-headerinfofordlp: None x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7Ili3MCvCLXmrxYjzLlJRY6FHY/pHjF6tFjgSe2JwmNBmRPgvRO9PTHSy6iVyvbVrfjFTfBeIiJxDMl435gppXWJM9ioOFyE1MciyhwUjL5O1d0Wu0m9Qw1lMfT4vy6hM/SZnJ5KJXhAZvyzfBr4AM8ngFE8ebkwaL/dXbpJmXNaDKESunn1ijQdKRh8bfHWaAbil8FJSf0e2NjaXTMbFeuhkBshLubOMLW2ouY/855XU/PNE6yW1FNSTPOIiQoSxV9CZ+vYekUdIRYox+7HWMvk= x-originating-ip: [10.163.24.212] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 19 Jun 2012 08:56:53.0314 (UTC) FILETIME=[78D6A220:01CD4DF9] X-Nokia-AV: Clean Cc: behave@ietf.org Subject: Re: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09 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, 19 Jun 2012 08:57:08 -0000 Hi Dave, Thank you for your review. The proposed changes in PDF look fine and will b= e incorporated. Responses inline for your questions: > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf > Of ext Dave Thaler > Sent: 19. kes=E4kuuta 2012 02:57 > To: draft-ietf-behave-nat64-discovery-heuristic@tools.ietf.org > Cc: behave@ietf.org > Subject: Re: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuris= tic- > 09 >=20 > My full comments and proposed editorial changes are in > http://research.microsoft.com/~dthaler/draft-ietf-behave-nat64-discovery- > heuristic-09.pdf >=20 > A brief summary of the main technical comments: >=20 > 1) I didn't follow why an A record query is needed or useful. If a host needs to know whether the well-known name service is up and runni= ng (no A record would explain lack of synthetic AAAA record).=20 If a host has not hard-coded the well-known IPv4 address and the host wants= to learn it on the go. > 2) Guidance on TTL is lacking. How long is "long"? In the past the document said "a year", but the feedback was that recursive= DNS servers will cap it anyway to something shorter. Hence I do not have b= etter idea of what would be exact value. A month? I also noticed now that t= he section 4 is not updated according to latest idea of permanent IANA allo= cation for well-known IPv4 address. Hence maybe this would be better section 4: -- 4. Operational Considerations for Hosting the IPv4-Only Well-Known Name The authoritative name server for the well-known name shall have DNS record Time-To-Live (TTL) set to at least 60 minutes in order to improve effectiveness of DNS caching. The exact TTL value will be determined and tuned based on operational experiences.=20 The domain serving the well-known name must be signed with DNSSEC. See also Security Considerations section. -- > 3) Need to update text on how often to repeat the check in the success ca= se. > Saying it MUST be one third the TTL seems overly strict and suboptimal gi= ven > that the TTL itself could be short (like 9 seconds) or long (like 9 month= s) and > no > guidance on that is given. Why not a specific number of seconds/minutes > before > expiry, rather than a fraction of the TTL? We could say 10 minutes before expiry, and then on the TTL place requiremen= t for minimum TTL (I drew minimum TTL of 60 minutes out from thin air). Wo= uld it be better? > 4) The text in 3.1.2 on verifying the address matches seems wrong (or els= e I'm > missing something), since querying for ipv4only.com will give Pref64::WKA= ::0 > whereas querying for the NAT64 FQDN will give (per 3.1.1 bullet 2) Pref63= ::0. > Those won't match. I'm guessing 3.1.1 bullet 2 is probably in error. Hm.. The idea is that in the step 1 host indeed gets synthetic address like= Pref64::WKA::0, but in the step 2 the host omits the WKA from the address = it queries and just asks for Pref64::0 (i.e. just prefix).=20 The intent of this has been to allow changing WKA; NAT64 operator would nee= d to just configure entry for Pref64::0 and whatever the WKA happens to be,= the name would be found this way.=20 Of course as we now seem to be heading for eternally fixed WKA, we could ma= ndate step 2 of 3.1.1 to be like: -- 2. Each NAT64 FQDN MUST have one or more DNS AAAA resource records with each IPv6 address consisting of Pref64::/n and WKA. -- Best regards, Teemu From teemu.savolainen@nokia.com Tue Jun 19 04:30:40 2012 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 702E621F859A for ; Tue, 19 Jun 2012 04:30:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 SJxSxO5muud8 for ; Tue, 19 Jun 2012 04:30:40 -0700 (PDT) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id 923C321F858A for ; Tue, 19 Jun 2012 04:30:39 -0700 (PDT) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-sa02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q5JBU8Zb017703; Tue, 19 Jun 2012 14:30:27 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.59]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 19 Jun 2012 14:30:08 +0300 Received: from 008-AM1MPN1-053.mgdnok.nokia.com ([169.254.3.37]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi id 14.02.0283.004; Tue, 19 Jun 2012 13:30:08 +0200 From: To: , Thread-Topic: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09 Thread-Index: AQHNR+G9CBCjjZ1MSUejEPV+sICjIpb2eW/ggAAeTwCACWHxEIAAb50AgAEjqiA= Date: Tue, 19 Jun 2012 11:30:07 +0000 Message-ID: <916CE6CF87173740BC8A2CE443096962043ADB0B@008-AM1MPN1-053.mgdnok.nokia.com> References: <9B57C850BB53634CACEC56EF4853FF653B62BDA4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <20120611145125.GC11684@mail.yitter.info> <916CE6CF87173740BC8A2CE4430969620439DD7C@008-AM1MPN1-053.mgdnok.nokia.com> <20120612140610.GA16548@mail.yitter.info> <916CE6CF87173740BC8A2CE443096962043AD0E0@008-AM1MPN1-053.mgdnok.nokia.com> <20120618200232.GU32683@mail.yitter.info> In-Reply-To: <20120618200232.GU32683@mail.yitter.info> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Nokia Internal Use Only;Project=None; x-titus-version: 3.3.8.1 x-headerinfofordlp: None x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7Ili3MCvCLXmrxYjzLlJRY6GRYSEESzssJdyl1KtGXxHbRz0f/N8DTFypsncJtFw5H6dEgLNn6I2DYQI1slWstWQLhts4Ao1Rvb7G9B7pZe+oW16aK60T/IZngo/xmoWZz4wl3U9iTRcWTIqdcQ9m+D6PMygWim2QOfgvTOlhx5yWE5M3n/txRnmqEif0/5bbQ+J8mO2cgxvdGCXg3S53/kMBDEDpT6rEg0W0aLtjGxqfiUPHRHRyqxYxC1TLq7ISAU6PK2jG5Ob6ktz5oQfnmV8= x-originating-ip: [10.163.27.56] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 19 Jun 2012 11:30:08.0278 (UTC) FILETIME=[E176CB60:01CD4E0E] X-Nokia-AV: Clean Subject: Re: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09 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, 19 Jun 2012 11:30:40 -0000 Hi Andrew, > Yep. The security guys, in my experience, jump up and down about this. = It > might be worth asking someone for an early review. I can't see what you'= re > going to do except ask the user, other than immediately fail; and in that= case, > of course, you're going to have to give the user an interface anyway. I'= d ask > for a secdir review specifically of this, though, because it's the sort o= f thing I > know people have strong opinions about. In silent fail case the user can still access all destinations that do not = require going through NAT64.. Any idea of who to ask? I don't personally kn= ow any currently active IETF security area expert.. =20 > Right. And, hurray, http://tools.ietf.org/html/rfc6672 is out. So that'= s your > reference now. Will refer:) Teemu From simon.perreault@viagenie.ca Tue Jun 19 06:05:04 2012 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 9B15E21F85BB for ; Tue, 19 Jun 2012 06:05:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-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 QME7EumO+BF6 for ; Tue, 19 Jun 2012 06:05:03 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 9E6D421F85A5 for ; Tue, 19 Jun 2012 06:05:03 -0700 (PDT) Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c064:8055:8e79:d19d:5713]) by jazz.viagenie.ca (Postfix) with ESMTPSA id D1F204005E; Tue, 19 Jun 2012 09:05:02 -0400 (EDT) Message-ID: <4FE078FE.8060605@viagenie.ca> Date: Tue, 19 Jun 2012 09:05:02 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1 MIME-Version: 1.0 To: Dan Wing References: <068301cd4dbe$083071d0$18915570$@com> In-Reply-To: <068301cd4dbe$083071d0$18915570$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: behave@ietf.org, 'Tina TSOU' Subject: Re: [BEHAVE] FW: New Version Notification for draft-tsou-behave-ftp46-00.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, 19 Jun 2012 13:05:04 -0000 Dan, Thanks for the review. I'm skipping some of your comments (that are IMHO valid and will need to be addressed in the next revision). On 2012-06-18 21:51, Dan Wing wrote: > Basically, I'm not seeing a need for all that uniqueness -- the IPv4-only > FTP server Our use case is IPv6-only servers talking to IPv4-only clients through a NAT64. I'll shortly send slides for the interim meeting with diagrams that will hopefully make this clear. > just needs to know its port number (hopefully, 21) and IPv6 > address, and publish its URL (ftp://ftp.example.com:PORT). That seems > the easiest example of how to make such an FTP server work, anyway. The whole point of RFC 6384 was to allow unmodified FTP servers to work. Some servers work without an ALG, some don't. In the "v6 network to v4 Internet" use case, the NAT64 operator has no control over the IPv4 servers and cannot modify them. So the only thing it can do is use an ALG. The same reasoning applies to our draft. An ISP deploying NAT64 has no control over the FTP server software that subscribers will be running. Some software will work fine without an ALG, but some won't. So the only thing that the ISP can do is run an ALG on the NAT64. > The FTP64 ALG document included a command to disable the FTP64 ALG. > Should FTP46 have a similar command? Since we're proposing that our draft update RFC 6384, the ALGS command will also apply. Maybe we need to extend it. At the very least we need text saying that it still applies. We'll look into it for the next revision. > A security issue does exist with FTP passive mode -- connection > theft. I believe there is an FTP document or two that explain > that vulnerability. Or see http://cr.yp.to/ftp/security.html Isn't that already covered by RFC 6384's security considerations section? Thanks, Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From ajs@anvilwalrusden.com Tue Jun 19 06:16:47 2012 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 49FFE21F8534 for ; Tue, 19 Jun 2012 06:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 UK8aILPbyQk9 for ; Tue, 19 Jun 2012 06:16:46 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id CC78721F847A for ; Tue, 19 Jun 2012 06:16:46 -0700 (PDT) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 1AF2D1ECB41D for ; Tue, 19 Jun 2012 13:16:46 +0000 (UTC) Date: Tue, 19 Jun 2012 09:16:46 -0400 From: Andrew Sullivan To: behave@ietf.org Message-ID: <20120619131646.GD34114@mail.yitter.info> References: <9B57C850BB53634CACEC56EF4853FF653B62BDA4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <20120611145125.GC11684@mail.yitter.info> <916CE6CF87173740BC8A2CE4430969620439DD7C@008-AM1MPN1-053.mgdnok.nokia.com> <20120612140610.GA16548@mail.yitter.info> <916CE6CF87173740BC8A2CE443096962043AD0E0@008-AM1MPN1-053.mgdnok.nokia.com> <20120618200232.GU32683@mail.yitter.info> <916CE6CF87173740BC8A2CE443096962043ADB0B@008-AM1MPN1-053.mgdnok.nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <916CE6CF87173740BC8A2CE443096962043ADB0B@008-AM1MPN1-053.mgdnok.nokia.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09 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, 19 Jun 2012 13:16:47 -0000 On Tue, Jun 19, 2012 at 11:30:07AM +0000, teemu.savolainen@nokia.com wrote: > > In silent fail case the user can still access all destinations that do not require going through NAT64.. Any idea of who to ask? I don't personally know any currently active IETF security area expert.. > Probably best just to ask the relevant ADs for a pointer. sec-ads@tools.ietf.org oughta work, I think? Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From petithug@acm.org Tue Jun 19 06:59:12 2012 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 4647521F851A for ; Tue, 19 Jun 2012 06:59:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.038, 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 fVIj-bhPzrVw for ; Tue, 19 Jun 2012 06:59:11 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 716A421F8510 for ; Tue, 19 Jun 2012 06:59:11 -0700 (PDT) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 3B04120440; Tue, 19 Jun 2012 13:59:09 +0000 (UTC) Message-ID: <4FE085AB.3080406@acm.org> Date: Tue, 19 Jun 2012 06:59:07 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.4) Gecko/20120510 Icedove/10.0.4 MIME-Version: 1.0 To: Dave Thaler References: <9B57C850BB53634CACEC56EF4853FF653B62BDA4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B66483D@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B66483D@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "behave@ietf.org" Subject: Re: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09 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, 19 Jun 2012 13:59:12 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 06/18/2012 05:00 PM, Dave Thaler wrote: > So far I've seen 3 reviews: * Andrew Sullivan * Aaron Yi DING * Dave > Thaler > > We need at least 5 reviews on this document. Can we get two more > volunteers? Maybe Simon and/or Marc P.-H.? Anyone else? I am not a DNS or IPv6 specialist, but I'll do my best. Expect my review before the 21st. > > -Dave > >> -----Original Message----- From: behave-bounces@ietf.org >> [mailto:behave-bounces@ietf.org] On Behalf Of Dave Thaler Sent: Friday, >> June 1, 2012 6:07 PM To: behave@ietf.org Subject: [BEHAVE] Last call: >> draft-ietf-behave-nat64-discovery-heuristic-09 >> >> This email initiates a two-week Working Group Last Call on >> draft-ietf-behave- nat64-discovery-heuristic-09, to conclude Friday June >> 15th. Hopefully that will give some time before our next interim >> meeting to review the comments and have proposed resolutions ready to >> discuss at the June 21st interim meeting. >> >> We need at least 5 reviewers to comment on the doc (even if just saying >> "loos good"). >> - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJP4IWpAAoJECnERZXWan7EHucQAOj0/VWgCJNuSkQi6jBmvMbl 7Ki6vzQpHoCF1f5NwlxPnvkrz0MObGcejxCcF6/znt+WgZnk1XhudnVM1RtG9wTG KUSqnCdeKQbnz1o8GTHWRHWHF84n9DnGHIZCRDSkOTqoqHtdH3sUZy03PadwMJ+L 4rkp7K+1xSeZANi9DvJ6IRVcvNwqoJQ5oHrDckwZ4Ev2YDXD2sh8k+5OPl5WT41k 9TmHgCYBXF6wkduIKTt2lKevV2BqyUa1u+hWnQrZNaJg/Il27K1PUHoWEOHdXP4s 3PCeS9nfm6at4h7eXXvgYTRK8RfRtAxB4wvl6mpP2LodDpRgYtLdAtZn1MruCBnN 1hX5u2SNLFA60rNEP6buHjKznnsnYU0XVAQq6NvaYgRebZdpHJ7h7yU9LZbOlPUA SOLJebs1cAhH03IARSv8d9/I3wzWeCSO/VP0QvOaC/24L4NulvANjCIXGoalXdq7 xK0D+6QqdgNSOspx2RDBZOTBrx5sGYUshsd7PNS0YIbDDGerYzC2QdKUzw6DK24j xgrSnQ9QQDRWAwR8xwBj0kKjGEtUZ0WO8iVkTqsvWL2hdviZrN0QSlXkNft4vjeW sBCd969L1bsidPgkkiA2HEnmw2WjYq/RV83Mr0aWEikp7iPt+S1jvurBfYD9FUHs BPEjPidcx3es2hqknTAT =xN6a -----END PGP SIGNATURE----- From dwing@cisco.com Tue Jun 19 07:06:28 2012 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 C0F3721F85F3 for ; Tue, 19 Jun 2012 07:06:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 X+yF0WJEtPjT for ; Tue, 19 Jun 2012 07:06:28 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id F04F121F85F2 for ; Tue, 19 Jun 2012 07:06:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=3107; q=dns/txt; s=iport; t=1340114788; x=1341324388; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=qOrkWpCXNH1WnwMT2R0j2evI1m1jPkwHqeZIMsSmXYQ=; b=cOgmi9uteLY3MhXPrvUo/Tb0zrhXBP5SMh4ufP4HLYZ6tvbsnQWhieOL j1e82Kk3DIw4xxN1H52mdBh0Yt4rS85RrLF9GnMs8NkDrYEAVFNOTEOut OL0IvHIosxbzJms1q3tqahQNdWPgWcfs3K4FCp3NmHdXtKxjCrStURIfb o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAAmG4E+rRDoH/2dsb2JhbABFpmSOcIEHghgBAQEDAQgKARQDED0CBQcBAwIJDwIEAQEBJwcZIwoIAQgBAQQTCxeHZAQMmQOgP4svhhkDiEOFAYhzjQWBZoMA X-IronPort-AV: E=Sophos;i="4.75,798,1330905600"; d="scan'208";a="49495396" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 19 Jun 2012 14:06:27 +0000 Received: from dwingWS ([10.32.240.197]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q5JE6RfQ025240; Tue, 19 Jun 2012 14:06:27 GMT From: "Dan Wing" To: "'Simon Perreault'" References: <068301cd4dbe$083071d0$18915570$@com> <4FE078FE.8060605@viagenie.ca> In-Reply-To: <4FE078FE.8060605@viagenie.ca> Date: Tue, 19 Jun 2012 07:06:27 -0700 Message-ID: <07dd01cd4e24$b7e94640$27bbd2c0$@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: Ac1OHCT5zXgftvqfS06DCtqybY+rIgAB/N+w Content-Language: en-us Cc: behave@ietf.org, 'Tina TSOU' Subject: Re: [BEHAVE] FW: New Version Notification for draft-tsou-behave-ftp46-00.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, 19 Jun 2012 14:06:29 -0000 > -----Original Message----- > From: Simon Perreault [mailto:simon.perreault@viagenie.ca] > Sent: Tuesday, June 19, 2012 6:05 AM > To: Dan Wing > Cc: 'Tina TSOU'; behave@ietf.org > Subject: Re: [BEHAVE] FW: New Version Notification for draft-tsou- > behave-ftp46-00.txt > > Dan, > > Thanks for the review. I'm skipping some of your comments (that are > IMHO > valid and will need to be addressed in the next revision). > > On 2012-06-18 21:51, Dan Wing wrote: > > Basically, I'm not seeing a need for all that uniqueness -- the IPv4- > only > > FTP server > > Our use case is IPv6-only servers talking to IPv4-only clients through > a > NAT64. I'll shortly send slides for the interim meeting with diagrams > that will hopefully make this clear. > > > just needs to know its port number (hopefully, 21) and IPv6 > > address, and publish its URL (ftp://ftp.example.com:PORT). That > seems > > the easiest example of how to make such an FTP server work, anyway. > > The whole point of RFC 6384 was to allow unmodified FTP servers to > work. > Some servers work without an ALG, some don't. In the "v6 network to v4 > Internet" use case, the NAT64 operator has no control over the IPv4 > servers and cannot modify them. So the only thing it can do is use an > ALG. Yes, because there is significant existing deployment of IPv4 FTP servers. But there is no significant existing deployment of IPv6 FTP servers. So I'm not sure the same logic needs to apply. And in 2012 an FTP URI is not unreasonable. > The same reasoning applies to our draft. An ISP deploying NAT64 has no > control over the FTP server software that subscribers will be running. > Some software will work fine without an ALG, but some won't. So the > only > thing that the ISP can do is run an ALG on the NAT64. So, are you saying the IPv4 host will have to listen on port 21? Are you saying the ISP -- as part of their ALG -- will have to listen on port 21, or will have to listen on some alternate port? > > The FTP64 ALG document included a command to disable the FTP64 ALG. > > Should FTP46 have a similar command? > > Since we're proposing that our draft update RFC 6384, the ALGS command > will also apply. Maybe we need to extend it. At the very least we need > text saying that it still applies. We'll look into it for the next > revision. By extending RFC6384, is there an expectation that every FTP64 ALG also implement the FTP46 ALG? > > A security issue does exist with FTP passive mode -- connection > > theft. I believe there is an FTP document or two that explain > > that vulnerability. Or see http://cr.yp.to/ftp/security.html > > Isn't that already covered by RFC 6384's security considerations > section? I dunno. But a 'RFC6384's security considerations applies to this document' doesn't hurt. -d > Thanks, > Simon > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca From simon.perreault@viagenie.ca Tue Jun 19 07:41:21 2012 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 7F0F921F864D for ; Tue, 19 Jun 2012 07:41:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-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 NtS6A6KYuJuU for ; Tue, 19 Jun 2012 07:41:20 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 8EECB21F8649 for ; Tue, 19 Jun 2012 07:41:20 -0700 (PDT) Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c064:8055:8e79:d19d:5713]) by jazz.viagenie.ca (Postfix) with ESMTPSA id ED255400AB; Tue, 19 Jun 2012 10:41:19 -0400 (EDT) Message-ID: <4FE08F8F.3090908@viagenie.ca> Date: Tue, 19 Jun 2012 10:41:19 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1 MIME-Version: 1.0 To: Dan Wing References: <068301cd4dbe$083071d0$18915570$@com> <4FE078FE.8060605@viagenie.ca> <07dd01cd4e24$b7e94640$27bbd2c0$@com> In-Reply-To: <07dd01cd4e24$b7e94640$27bbd2c0$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: behave@ietf.org, 'Tina TSOU' Subject: Re: [BEHAVE] FW: New Version Notification for draft-tsou-behave-ftp46-00.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, 19 Jun 2012 14:41:21 -0000 On 2012-06-19 10:06, Dan Wing wrote: >> The whole point of RFC 6384 was to allow unmodified FTP servers to >> work. >> Some servers work without an ALG, some don't. In the "v6 network to v4 >> Internet" use case, the NAT64 operator has no control over the IPv4 >> servers and cannot modify them. So the only thing it can do is use an >> ALG. > > Yes, because there is significant existing deployment of IPv4 FTP > servers. But there is no significant existing deployment of IPv6 > FTP servers. So I'm not sure the same logic needs to apply. Deployment base doesn't matter in our case. As soon as an ISP puts subscribers behind a NAT64, their FTP servers will go from IPv4 to IPv6. And given that current FTP server software generally includes IPv6 support, they will just continue using the same software. Just the act of turning on a NAT64 will create IPv6-only FTP servers. > And in 2012 an FTP URI is not unreasonable. I'm not sure what you're getting at. >> The same reasoning applies to our draft. An ISP deploying NAT64 has no >> control over the FTP server software that subscribers will be running. >> Some software will work fine without an ALG, but some won't. So the >> only thing that the ISP can do is run an ALG on the NAT64. > > So, are you saying the IPv4 host will have to listen on port 21? The FTP server is IPv6, not IPv4. > Are you saying the ISP -- as part of their ALG -- will have to listen on > port 21, or will have to listen on some alternate port? No. We assume that not all subscribers can get port 21. They will need to use another port. They can use PCP or whatever else to open a port on the NAT64. Users are already trained to open a port in their home NAT, with UPnP-enabled FTP server software or statically-configured port redirection. Furthermore, this is a generic problem that happens whenever you mix well-known port numbers with NAT. It is not specific to our draft, FTP, or even to NAT64. So we do not try to address it in our draft. > By extending RFC6384, is there an expectation that every FTP64 ALG > also implement the FTP46 ALG? No. >>> A security issue does exist with FTP passive mode -- connection >>> theft. I believe there is an FTP document or two that explain >>> that vulnerability. Or see http://cr.yp.to/ftp/security.html >> >> Isn't that already covered by RFC 6384's security considerations >> section? > > I dunno. But a 'RFC6384's security considerations applies to > this document' doesn't hurt. We will definitely add that. Thanks, Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From dwing@cisco.com Tue Jun 19 07:57:15 2012 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 3004621F856D for ; Tue, 19 Jun 2012 07:57:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 B45IQjt1SbgR for ; Tue, 19 Jun 2012 07:57:13 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id A600E21F856C for ; Tue, 19 Jun 2012 07:57:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=3875; q=dns/txt; s=iport; t=1340117833; x=1341327433; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=rsur1UMtbCYrpjpjJHp8yQ4CbO1hQfW0sfD3ttSRkn0=; b=YZYO2CbyZ3F93vSRn9nr5gAG5Eb/oae6OHR/PexLS7rCctlQr4MAXhfJ kKgaZfp4a18/4z1Reblhpm1kYJhcTPMDl9BYnNXWPNEEq1DDcPU0QHZfN uA/o+1VA6mYCk3aGphC5WC2fn1f+Gzmmt+nwm+EJxyHtn9eZ4dpWBSLue 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAOWS4E+rRDoG/2dsb2JhbABFpmSOcIEHghgBAQEDAQgKARQDED0CDAEDAgkPAgQBAQEnBxkjCggBCAEBBBMLF4dkBAyZA6A+iy+GGQOIQ4UBiHONBYFmgwA X-IronPort-AV: E=Sophos;i="4.75,798,1330905600"; d="scan'208";a="46927514" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 19 Jun 2012 14:57:08 +0000 Received: from dwingWS ([10.32.240.197]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q5JEv8eZ012952; Tue, 19 Jun 2012 14:57:08 GMT From: "Dan Wing" To: "'Simon Perreault'" References: <068301cd4dbe$083071d0$18915570$@com> <4FE078FE.8060605@viagenie.ca> <07dd01cd4e24$b7e94640$27bbd2c0$@com> <4FE08F8F.3090908@viagenie.ca> In-Reply-To: <4FE08F8F.3090908@viagenie.ca> Date: Tue, 19 Jun 2012 07:57:08 -0700 Message-ID: <083501cd4e2b$cc64c9d0$652e5d70$@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: Ac1OKZhVR7Zp7sJ0S6yen6821h/FNgAAbEoQ Content-Language: en-us Cc: behave@ietf.org, 'Tina TSOU' Subject: Re: [BEHAVE] FW: New Version Notification for draft-tsou-behave-ftp46-00.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, 19 Jun 2012 14:57:15 -0000 > -----Original Message----- > From: Simon Perreault [mailto:simon.perreault@viagenie.ca] > Sent: Tuesday, June 19, 2012 7:41 AM > To: Dan Wing > Cc: 'Tina TSOU'; behave@ietf.org > Subject: Re: [BEHAVE] FW: New Version Notification for draft-tsou- > behave-ftp46-00.txt > > On 2012-06-19 10:06, Dan Wing wrote: > >> The whole point of RFC 6384 was to allow unmodified FTP servers to > >> work. > >> Some servers work without an ALG, some don't. In the "v6 network to > v4 > >> Internet" use case, the NAT64 operator has no control over the IPv4 > >> servers and cannot modify them. So the only thing it can do is use > an > >> ALG. > > > > Yes, because there is significant existing deployment of IPv4 FTP > > servers. But there is no significant existing deployment of IPv6 > > FTP servers. So I'm not sure the same logic needs to apply. > > Deployment base doesn't matter in our case. As soon as an ISP puts > subscribers behind a NAT64, their FTP servers will go from IPv4 to > IPv6. > And given that current FTP server software generally includes IPv6 > support, they will just continue using the same software. Just the act > of turning on a NAT64 will create IPv6-only FTP servers. Your I-D provides no guidance on how the incoming TCP/21 connection is expected to work with the NAT64. But I do now understand why your document explains the ALG has to create a mapping; I previously did not understand that. Thanks. > > And in 2012 an FTP URI is not unreasonable. > > I'm not sure what you're getting at. The difficulty in everyone running an FTP server getting port 21, which seemed tied to your statement that FTP clients and FTP servers need to remain un-changed. > >> The same reasoning applies to our draft. An ISP deploying NAT64 has > no > >> control over the FTP server software that subscribers will be > running. > >> Some software will work fine without an ALG, but some won't. So the > >> only thing that the ISP can do is run an ALG on the NAT64. > > > > So, are you saying the IPv4 host will have to listen on port 21? > > The FTP server is IPv6, not IPv4. Sorry for my confusion. Pretend I asked, So, are you saying the IPv6 host will have to listen on port 21? > > Are you saying the ISP -- as part of their ALG -- will have to listen > on > > port 21, or will have to listen on some alternate port? > > No. > > We assume that not all subscribers can get port 21. They will need to > use another port. They can use PCP or whatever else to open a port on > the NAT64. Users are already trained to open a port in their home NAT, > with UPnP-enabled FTP server software or statically-configured port > redirection. > > Furthermore, this is a generic problem that happens whenever you mix > well-known port numbers with NAT. It is not specific to our draft, FTP, > or even to NAT64. So we do not try to address it in our draft. > > > By extending RFC6384, is there an expectation that every FTP64 ALG > > also implement the FTP46 ALG? > > No. I'm puzzled by the extension (I presume, "Update:" in the header), then. But that's a small nit in the scheme of things. -d > >>> A security issue does exist with FTP passive mode -- connection > >>> theft. I believe there is an FTP document or two that explain > >>> that vulnerability. Or see http://cr.yp.to/ftp/security.html > >> > >> Isn't that already covered by RFC 6384's security considerations > >> section? > > > > I dunno. But a 'RFC6384's security considerations applies to > > this document' doesn't hurt. > > We will definitely add that. > > Thanks, > Simon > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca From simon.perreault@viagenie.ca Tue Jun 19 08:13:46 2012 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 E3BAA11E8072 for ; Tue, 19 Jun 2012 08:13:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-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 JVIpVNoliOzs for ; Tue, 19 Jun 2012 08:13:46 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 203A221F852D for ; Tue, 19 Jun 2012 08:13:46 -0700 (PDT) Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c064:8055:8e79:d19d:5713]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 6EB40400AB; Tue, 19 Jun 2012 11:13:45 -0400 (EDT) Message-ID: <4FE09728.5030805@viagenie.ca> Date: Tue, 19 Jun 2012 11:13:44 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1 MIME-Version: 1.0 To: Dan Wing References: <068301cd4dbe$083071d0$18915570$@com> <4FE078FE.8060605@viagenie.ca> <07dd01cd4e24$b7e94640$27bbd2c0$@com> <4FE08F8F.3090908@viagenie.ca> <083501cd4e2b$cc64c9d0$652e5d70$@com> In-Reply-To: <083501cd4e2b$cc64c9d0$652e5d70$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: behave@ietf.org, 'Tina TSOU' Subject: Re: [BEHAVE] FW: New Version Notification for draft-tsou-behave-ftp46-00.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, 19 Jun 2012 15:13:47 -0000 On 2012-06-19 10:57, Dan Wing wrote: >> Deployment base doesn't matter in our case. As soon as an ISP puts >> subscribers behind a NAT64, their FTP servers will go from IPv4 to >> IPv6. >> And given that current FTP server software generally includes IPv6 >> support, they will just continue using the same software. Just the act >> of turning on a NAT64 will create IPv6-only FTP servers. > > Your I-D provides no guidance on how the incoming TCP/21 connection > is expected to work with the NAT64. This paragraph was intended to provide such guidance: When the FTP server is behind NAT, it can publish its service address via a redirect server located in the internet, or via modified DDNS system, or other possible methods. It is out of the scope of this memo. It goes without saying that this will be much improved in the next revision. :) >>> So, are you saying the IPv4 host will have to listen on port 21? >> >> The FTP server is IPv6, not IPv4. > > Sorry for my confusion. > > Pretend I asked, > > So, are you saying the IPv6 host will have to listen on port 21? That's what I did in my answer below. :) >>> Are you saying the ISP -- as part of their ALG -- will have to listen >> on >>> port 21, or will have to listen on some alternate port? >> >> No. >> >> We assume that not all subscribers can get port 21. They will need to >> use another port. They can use PCP or whatever else to open a port on >> the NAT64. Users are already trained to open a port in their home NAT, >> with UPnP-enabled FTP server software or statically-configured port >> redirection. >> >> Furthermore, this is a generic problem that happens whenever you mix >> well-known port numbers with NAT. It is not specific to our draft, FTP, >> or even to NAT64. So we do not try to address it in our draft. >>> By extending RFC6384, is there an expectation that every FTP64 ALG >>> also implement the FTP46 ALG? >> >> No. > > I'm puzzled by the extension (I presume, "Update:" in the header), then. > But that's a small nit in the scheme of things. Maybe my understanding of what "Update:" means is broken. Let's look at RFC2223... To be used as a reference from a new item that cannot be used alone (i.e., one that supplements a previous document), to refer to the previous document. The newer publication is a part that will supplement or be added on to the existing document; e.g., an addendum, or separate, extra information that is to be added to the original document. Well, that's exactly what we mean! Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From internet-drafts@ietf.org Tue Jun 19 10:09:40 2012 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 0B4D211E80CD; Tue, 19 Jun 2012 10:09:40 -0700 (PDT) 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 IEGV66c3lKUz; Tue, 19 Jun 2012 10:09:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40D3811E8088; Tue, 19 Jun 2012 10:09:39 -0700 (PDT) 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: 4.20 Message-ID: <20120619170939.1843.63007.idtracker@ietfa.amsl.com> Date: Tue, 19 Jun 2012 10:09:39 -0700 Cc: behave@ietf.org Subject: [BEHAVE] I-D Action: draft-ietf-behave-nat-mib-01.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, 19 Jun 2012 17:09: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 Avoida= nce Working Group of the IETF. Title : Additional Managed Objects for Network Address Translato= rs (NAT) Author(s) : Simon Perreault Tina Tsou Senthil Sivakumar Filename : draft-ietf-behave-nat-mib-01.txt Pages : 28 Date : 2012-06-19 Abstract: This memo defines a portion of the Management Information Base (MIB) for devices implementing Network Address Translator (NAT) function. This MIB module may be used for monitoring of a device capable of NAT function. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-behave-nat-mib There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-behave-nat-mib-01 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-behave-nat-mib-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From simon.perreault@viagenie.ca Tue Jun 19 10:15:09 2012 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 56FF111E80B7 for ; Tue, 19 Jun 2012 10:15:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-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 Jw3I3YrZwuM7 for ; Tue, 19 Jun 2012 10:15:08 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 322E911E8095 for ; Tue, 19 Jun 2012 10:15:08 -0700 (PDT) Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c064:8055:8e79:d19d:5713]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 9D329415BB for ; Tue, 19 Jun 2012 13:15:07 -0400 (EDT) Message-ID: <4FE0B39B.3080501@viagenie.ca> Date: Tue, 19 Jun 2012 13:15:07 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1 MIME-Version: 1.0 To: behave@ietf.org References: <20120619170939.1843.63007.idtracker@ietfa.amsl.com> In-Reply-To: <20120619170939.1843.63007.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] I-D Action: draft-ietf-behave-nat-mib-01.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, 19 Jun 2012 17:15:09 -0000 On 2012-06-19 13:09, internet-drafts@ietf.org wrote: > Title : Additional Managed Objects for Network Address Translators (NAT) > Author(s) : Simon Perreault > Tina Tsou > Senthil Sivakumar > Filename : draft-ietf-behave-nat-mib-01.txt This revision adds a number of features. Here's the change log: o Added CGN stuff (per-subscriber quotas, counters, notifications). o Added conformance groups and compliance statements. o Added mapping table indexed by external 3-tuple. Any feedback is very welcome, as usual. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From dthaler@microsoft.com Tue Jun 19 12:19:49 2012 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 9F1C911E8159 for ; Tue, 19 Jun 2012 12:19:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.659 X-Spam-Level: X-Spam-Status: No, score=-103.659 tagged_above=-999 required=5 tests=[AWL=-0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 a+vq2fn9wYuC for ; Tue, 19 Jun 2012 12:19:49 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe005.messaging.microsoft.com [216.32.181.185]) by ietfa.amsl.com (Postfix) with ESMTP id BCDBB11E8134 for ; Tue, 19 Jun 2012 12:19:48 -0700 (PDT) Received: from mail134-ch1-R.bigfish.com (10.43.68.254) by CH1EHSOBE018.bigfish.com (10.43.70.68) with Microsoft SMTP Server id 14.1.225.23; Tue, 19 Jun 2012 19:18:26 +0000 Received: from mail134-ch1 (localhost [127.0.0.1]) by mail134-ch1-R.bigfish.com (Postfix) with ESMTP id 5832CE0183; Tue, 19 Jun 2012 19:18:26 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -32 X-BigFish: VS-32(zz9371Ic89bh542M1432Izz1202hzz1033IL8275bh8275dh186Mz2fh2a8h668h839hd25hf0ah) Received-SPF: pass (mail134-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14MLTC103.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail134-ch1 (localhost.localdomain [127.0.0.1]) by mail134-ch1 (MessageSwitch) id 1340133504771277_1896; Tue, 19 Jun 2012 19:18:24 +0000 (UTC) Received: from CH1EHSMHS012.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.242]) by mail134-ch1.bigfish.com (Postfix) with ESMTP id B0C7B3C0046; Tue, 19 Jun 2012 19:18:24 +0000 (UTC) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS012.bigfish.com (10.43.70.12) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 19 Jun 2012 19:18:22 +0000 Received: from TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com (157.54.24.14) by TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) with Microsoft SMTP Server (TLS) id 14.2.298.5; Tue, 19 Jun 2012 19:19:40 +0000 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com (157.54.24.14) with Microsoft SMTP Server (TLS) id 14.2.309.3; Tue, 19 Jun 2012 12:19:39 -0700 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.28]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.02.0309.003; Tue, 19 Jun 2012 12:19:39 -0700 From: Dave Thaler To: "teemu.savolainen@nokia.com" , "draft-ietf-behave-nat64-discovery-heuristic@tools.ietf.org" Thread-Topic: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09 Thread-Index: AQHNTfmB9mTp5FPZLUe/4H32jWpltpcCBAPw Date: Tue, 19 Jun 2012 19:19:39 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B666DF6@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> References: <9B57C850BB53634CACEC56EF4853FF653B62BDA4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B664824@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <916CE6CF87173740BC8A2CE443096962043AD71A@008-AM1MPN1-053.mgdnok.nokia.com> In-Reply-To: <916CE6CF87173740BC8A2CE443096962043AD71A@008-AM1MPN1-053.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.90] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "behave@ietf.org" Subject: Re: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09 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, 19 Jun 2012 19:19:49 -0000 > -----Original Message----- > From: teemu.savolainen@nokia.com [mailto:teemu.savolainen@nokia.com] > Sent: Tuesday, June 19, 2012 1:57 AM > To: Dave Thaler; draft-ietf-behave-nat64-discovery-heuristic@tools.ietf.o= rg > Cc: behave@ietf.org > Subject: RE: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuris= tic- > 09 >=20 > Hi Dave, >=20 > Thank you for your review. The proposed changes in PDF look fine and will= be > incorporated. >=20 > Responses inline for your questions: >=20 > > -----Original Message----- > > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > > Behalf Of ext Dave Thaler > > Sent: 19. kes=E4kuuta 2012 02:57 > > To: draft-ietf-behave-nat64-discovery-heuristic@tools.ietf.org > > Cc: behave@ietf.org > > Subject: Re: [BEHAVE] Last call: > > draft-ietf-behave-nat64-discovery-heuristic- > > 09 > > > > My full comments and proposed editorial changes are in > > http://research.microsoft.com/~dthaler/draft-ietf-behave-nat64-discove > > ry- > > heuristic-09.pdf > > > > A brief summary of the main technical comments: > > > > 1) I didn't follow why an A record query is needed or useful. >=20 > If a host needs to know whether the well-known name service is up and > running (no A record would explain lack of synthetic AAAA record). I don't see any discussion of this in the doc. Either the A record query should be removed or else it should be explained how it's used as part of the algorithm. =20 > If a host has not hard-coded the well-known IPv4 address and the host wan= ts > to learn it on the go. Why would a host not hard-code it/them? =20 > > 2) Guidance on TTL is lacking. How long is "long"? >=20 > In the past the document said "a year", but the feedback was that recursi= ve > DNS servers will cap it anyway to something shorter. Hence I do not have > better idea of what would be exact value. A month? I also noticed now tha= t > the section 4 is not updated according to latest idea of permanent IANA > allocation for well-known IPv4 address. >=20 > Hence maybe this would be better section 4: > -- > 4. Operational Considerations for Hosting the IPv4-Only Well-Known Name >=20 > The authoritative name server for the well-known name shall have DNS > record Time-To-Live (TTL) set to at least 60 minutes in order to impro= ve > effectiveness of DNS caching. The exact TTL value will be determined > and tuned based on operational experiences. That's much better yes. =20 > The domain serving the well-known name must be signed with DNSSEC. > See also Security Considerations section. > -- >=20 > > 3) Need to update text on how often to repeat the check in the success > case. > > Saying it MUST be one third the TTL seems overly strict and suboptimal > > given that the TTL itself could be short (like 9 seconds) or long > > (like 9 months) and no > > guidance on that is given. Why not a specific number of seconds/minut= es > > before > > expiry, rather than a fraction of the TTL? >=20 > We could say 10 minutes before expiry, and then on the TTL place > requirement for minimum TTL (I drew minimum TTL of 60 minutes out from > thin air). Would it be better? Much better. Though 10 minutes seems long. It just has to be long enough to have a very high probability of succeeding before expiry (taking into account, loss, retries, etc.). > > 4) The text in 3.1.2 on verifying the address matches seems wrong (or > > else I'm missing something), since querying for ipv4only.com will give > > Pref64::WKA::0 whereas querying for the NAT64 FQDN will give (per 3.1.1 > bullet 2) Pref63::0. > > Those won't match. I'm guessing 3.1.1 bullet 2 is probably in error. >=20 > Hm.. The idea is that in the step 1 host indeed gets synthetic address li= ke > Pref64::WKA::0, but in the step 2 the host omits the WKA from the address= it > queries and just asks for Pref64::0 (i.e. just prefix). >=20 > The intent of this has been to allow changing WKA; NAT64 operator would > need to just configure entry for Pref64::0 and whatever the WKA happens t= o > be, the name would be found this way. >=20 > Of course as we now seem to be heading for eternally fixed WKA, we could > mandate step 2 of 3.1.1 to be like: > -- > 2. Each NAT64 FQDN MUST have one or more DNS AAAA resource records > with each IPv6 address consisting of Pref64::/n and WKA. > -- >=20 > Best regards, >=20 > Teemu From dthaler@microsoft.com Tue Jun 19 12:29:50 2012 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 CD69B11E816E for ; Tue, 19 Jun 2012 12:29:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.655 X-Spam-Level: X-Spam-Status: No, score=-103.655 tagged_above=-999 required=5 tests=[AWL=-0.056, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 RC25Q+Pq1cO7 for ; Tue, 19 Jun 2012 12:29:49 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe004.messaging.microsoft.com [213.199.154.142]) by ietfa.amsl.com (Postfix) with ESMTP id 64A8411E8144 for ; Tue, 19 Jun 2012 12:29:45 -0700 (PDT) Received: from mail87-db3-R.bigfish.com (10.3.81.226) by DB3EHSOBE005.bigfish.com (10.3.84.25) with Microsoft SMTP Server id 14.1.225.23; Tue, 19 Jun 2012 19:28:22 +0000 Received: from mail87-db3 (localhost [127.0.0.1]) by mail87-db3-R.bigfish.com (Postfix) with ESMTP id 1AF532601E4; Tue, 19 Jun 2012 19:28:22 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -1 X-BigFish: VS-1(zz1432Izz1202hzzz2fh2a8h668h839h944hd25hf0ah) Received-SPF: pass (mail87-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14MLTC103.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail87-db3 (localhost.localdomain [127.0.0.1]) by mail87-db3 (MessageSwitch) id 1340134099291058_27002; Tue, 19 Jun 2012 19:28:19 +0000 (UTC) Received: from DB3EHSMHS002.bigfish.com (unknown [10.3.81.246]) by mail87-db3.bigfish.com (Postfix) with ESMTP id 450032A0053; Tue, 19 Jun 2012 19:28:19 +0000 (UTC) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS002.bigfish.com (10.3.87.102) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 19 Jun 2012 19:28:17 +0000 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) with Microsoft SMTP Server (TLS) id 14.2.298.5; Tue, 19 Jun 2012 19:29:38 +0000 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) with Microsoft SMTP Server (TLS) id 14.2.309.3; Tue, 19 Jun 2012 12:29:38 -0700 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.28]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.02.0309.003; Tue, 19 Jun 2012 12:29:37 -0700 From: Dave Thaler To: Simon Perreault , Dan Wing Thread-Topic: [BEHAVE] FW: New Version Notification for draft-tsou-behave-ftp46-00.txt Thread-Index: AQHNTb4P+jc7wqQf30KAjVZ2EPgRaZcCEiIAgAARKYCAAAm+gIAABGwAgAAEowD//9F1MA== Date: Tue, 19 Jun 2012 19:29:37 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B666E9A@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> References: <068301cd4dbe$083071d0$18915570$@com> <4FE078FE.8060605@viagenie.ca> <07dd01cd4e24$b7e94640$27bbd2c0$@com> <4FE08F8F.3090908@viagenie.ca> <083501cd4e2b$cc64c9d0$652e5d70$@com> <4FE09728.5030805@viagenie.ca> In-Reply-To: <4FE09728.5030805@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.90] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "behave@ietf.org" , 'Tina TSOU' Subject: Re: [BEHAVE] FW: New Version Notification for draft-tsou-behave-ftp46-00.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, 19 Jun 2012 19:29:50 -0000 > > I'm puzzled by the extension (I presume, "Update:" in the header), then= . > > But that's a small nit in the scheme of things. >=20 > Maybe my understanding of what "Update:" means is broken. Let's look at > RFC2223... >=20 > To be used as a reference from a new item that cannot be used > alone (i.e., one that supplements a previous document), to refer > to the previous document. The newer publication is a part that > will supplement or be added on to the existing document; e.g., an > addendum, or separate, extra information that is to be added to > the original document. >=20 > Well, that's exactly what we mean! A normative reference is one that you depend on. Updates is used only when you are actually changing something in that docum= ent, rather than just layering over or reusing a piece of it. -Dave From j.schoenwaelder@jacobs-university.de Tue Jun 19 12:38:31 2012 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 6F20E11E816A for ; Tue, 19 Jun 2012 12:38:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.168 X-Spam-Level: X-Spam-Status: No, score=-103.168 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, 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 9iXsMcT0iqsZ for ; Tue, 19 Jun 2012 12:38:30 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 8E6C211E8134 for ; Tue, 19 Jun 2012 12:38:30 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8C23B20BEF; Tue, 19 Jun 2012 21:38:29 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 7l43_BVFmjOy; Tue, 19 Jun 2012 21:38:29 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2983720BEE; Tue, 19 Jun 2012 21:38:29 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id F27D11FEFE34; Tue, 19 Jun 2012 21:38:27 +0200 (CEST) Date: Tue, 19 Jun 2012 21:38:26 +0200 From: Juergen Schoenwaelder To: behave@ietf.org Message-ID: <20120619193826.GA23555@elstar.local> Mail-Followup-To: behave@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [BEHAVE] new nat mib question X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2012 19:38:31 -0000 Hi, I have come across the new NAT MIB and I am not sure I understand the scope of this effort and how the result will relate to the existing NAT-MIB in RFC 4008. The behave I-D says: [RFC4008] defines some objects for managing network address translators (NATs). Current operational practice often requires additional objects, in particular for enterprise and Internet service provider (ISP) deployments. This document defines those additional objects. This module is designed to be completely independent from [RFC4008]. A NAT implementation could be managed using this module, the one from [RFC4008], or both The first paragraph sounds like the goal is to define additional objects relative to the RFC 4008 NAT-MIB while the second paragraph says quite clearly that this is going to a competing MIB module. If so, this is, as far as I know, the first time we have two standards-track MIB modules for managing a single technology. Can someone explain what the goal of this effort is or point me somewhere into the archives so I can inform myself? Note, it might very well be that the RFC 4008 NAT-MIB is seriously broken but then the proper approach would be to write a new MIB replacing the old MIB, sending RFC 4008 to historic. Otherwise, it should be explained somewhere how the new MIB plays together with the NAT-MIB. (My background on this is essentially written down in draft-schoenw-behave-nat-mib-bis-00.) I also think NEW-NAT-MIB is not a good name. What is new today is going to be old tomorrow. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From dthaler@microsoft.com Tue Jun 19 12:48:01 2012 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 E0C6311E8091 for ; Tue, 19 Jun 2012 12:48:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.152 X-Spam-Level: X-Spam-Status: No, score=-105.152 tagged_above=-999 required=5 tests=[AWL=1.447, 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 o-VhKEN1Kf+1 for ; Tue, 19 Jun 2012 12:48:01 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe006.messaging.microsoft.com [216.32.180.16]) by ietfa.amsl.com (Postfix) with ESMTP id E4BDE21F8606 for ; Tue, 19 Jun 2012 12:48:00 -0700 (PDT) Received: from mail83-va3-R.bigfish.com (10.7.14.245) by VA3EHSOBE013.bigfish.com (10.7.40.63) with Microsoft SMTP Server id 14.1.225.23; Tue, 19 Jun 2012 19:46:38 +0000 Received: from mail83-va3 (localhost [127.0.0.1]) by mail83-va3-R.bigfish.com (Postfix) with ESMTP id CF0B31E01A0; Tue, 19 Jun 2012 19:46:37 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC105.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -27 X-BigFish: VS-27(zz9371I542M1432Izz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25hf0ah) Received-SPF: pass (mail83-va3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14HUBC105.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail83-va3 (localhost.localdomain [127.0.0.1]) by mail83-va3 (MessageSwitch) id 1340135195241687_9772; Tue, 19 Jun 2012 19:46:35 +0000 (UTC) Received: from VA3EHSMHS024.bigfish.com (unknown [10.7.14.254]) by mail83-va3.bigfish.com (Postfix) with ESMTP id 2D5E0360049; Tue, 19 Jun 2012 19:46:35 +0000 (UTC) Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS024.bigfish.com (10.7.99.34) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 19 Jun 2012 19:46:34 +0000 Received: from TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com (157.54.24.14) by TK5EX14HUBC105.redmond.corp.microsoft.com (157.54.80.48) with Microsoft SMTP Server (TLS) id 14.2.309.3; Tue, 19 Jun 2012 19:47:54 +0000 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com (157.54.24.14) with Microsoft SMTP Server (TLS) id 14.2.309.3; Tue, 19 Jun 2012 12:47:54 -0700 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.28]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.02.0309.003; Tue, 19 Jun 2012 12:47:54 -0700 From: Dave Thaler To: Juergen Schoenwaelder , "behave@ietf.org" Thread-Topic: [BEHAVE] new nat mib question Thread-Index: AQHNTlMgTR076JfJpUq2sfVt43d84pcCCjEw Date: Tue, 19 Jun 2012 19:47:53 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B666FE0@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> References: <20120619193826.GA23555@elstar.local> In-Reply-To: <20120619193826.GA23555@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.90] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [BEHAVE] new nat mib question 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, 19 Jun 2012 19:48:02 -0000 > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of Juergen Schoenwaelder > Sent: Tuesday, June 19, 2012 12:38 PM > To: behave@ietf.org > Subject: [BEHAVE] new nat mib question >=20 > Hi, >=20 > I have come across the new NAT MIB and I > am not sure I understand the scope of this effort and how the result will > relate to the existing NAT-MIB in RFC 4008.=20 My expectation was that it would either extend it by simply adding addition= al objects that don't duplicate any functionality, or else obsolete it. The draft is new and hasn't really had any significant review yet. > The behave I-D says: >=20 > [RFC4008] defines some objects for managing network address > translators (NATs). Current operational practice often requires > additional objects, in particular for enterprise and Internet service > provider (ISP) deployments. This document defines those additional > objects. >=20 > This module is designed to be completely independent from [RFC4008]. > A NAT implementation could be managed using this module, the one from > [RFC4008], or both >=20 > The first paragraph sounds like the goal is to define additional objects = relative > to the RFC 4008 NAT-MIB while the second paragraph says quite clearly tha= t > this is going to a competing MIB module. If so, this is, as far as I know= , the > first time we have two standards-track MIB modules for managing a single > technology. That should definitely not be the case, and like you do it seems, I object = to the second paragraph. > Can someone explain what the goal of this effort is or point me > somewhere into the archives so I can inform myself? Note, it might very w= ell > be that the RFC 4008 NAT-MIB is seriously broken but then the proper > approach would be to write a new MIB replacing the old MIB, sending RFC > 4008 to historic. Otherwise, it should be explained somewhere how the ne= w > MIB plays together with the NAT-MIB. (My background on this is essentiall= y > written down in draft-schoenw-behave-nat-mib-bis-00.) Your expectations are correct. > I also think NEW-NAT-MIB is not a good name. What is new today is going t= o > be old tomorrow. Absolutely agree. -Dave >=20 > /js >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From simon.perreault@viagenie.ca Tue Jun 19 13:01:19 2012 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 9052D11E811C for ; Tue, 19 Jun 2012 13:01:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-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 jIqIiJTRS5NO for ; Tue, 19 Jun 2012 13:01:18 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id BE78211E8095 for ; Tue, 19 Jun 2012 13:01:18 -0700 (PDT) Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c064:8055:8e79:d19d:5713]) by jazz.viagenie.ca (Postfix) with ESMTPSA id DD2D4415BB for ; Tue, 19 Jun 2012 16:01:17 -0400 (EDT) Message-ID: <4FE0DA8D.8010709@viagenie.ca> Date: Tue, 19 Jun 2012 16:01:17 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1 MIME-Version: 1.0 To: behave@ietf.org References: <20120619193826.GA23555@elstar.local> <9B57C850BB53634CACEC56EF4853FF653B666FE0@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B666FE0@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] new nat mib question 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, 19 Jun 2012 20:01:19 -0000 On 2012-06-19 15:47, Dave Thaler wrote: >> I have come across the new NAT MIB and I >> am not sure I understand the scope of this effort and how the result will >> relate to the existing NAT-MIB in RFC 4008. > > My expectation was that it would either extend it by simply adding additional > objects that don't duplicate any functionality, or else obsolete it. Our draft defines new objects that don't duplicate any functionality of 4008. It also doesn't build on top of 4008 in any way. I suppose we could obsolete 4008. But it feels strange obsoleting an RFC with something completely different. I'm fully open to guidance. > The draft is new and hasn't really had any significant review yet. True. We need reviews. We'll keep asking. >> The behave I-D says: >> >> [RFC4008] defines some objects for managing network address >> translators (NATs). Current operational practice often requires >> additional objects, in particular for enterprise and Internet service >> provider (ISP) deployments. This document defines those additional >> objects. >> >> This module is designed to be completely independent from [RFC4008]. >> A NAT implementation could be managed using this module, the one from >> [RFC4008], or both >> >> The first paragraph sounds like the goal is to define additional objects relative >> to the RFC 4008 NAT-MIB while the second paragraph says quite clearly that >> this is going to a competing MIB module. If so, this is, as far as I know, the >> first time we have two standards-track MIB modules for managing a single >> technology. > > That should definitely not be the case, and like you do it seems, I object to > the second paragraph. If our draft did build on top of 4008, the second paragraph would vanish. But we haven't found a need to do that so far. Nothing in 4008 is of any use to us. >> I also think NEW-NAT-MIB is not a good name. What is new today is going to >> be old tomorrow. > > Absolutely agree. Definitely. Do you have a better name to suggest? THE-MIB-FORMERLY-KNOWN-AS-THE-NEW-NAT-MIB Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From j.schoenwaelder@jacobs-university.de Tue Jun 19 14:26:09 2012 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 3E73D11E8134 for ; Tue, 19 Jun 2012 14:26:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.173 X-Spam-Level: X-Spam-Status: No, score=-103.173 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, 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 pX8u92PQw193 for ; Tue, 19 Jun 2012 14:26:08 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 5CC4611E80F6 for ; Tue, 19 Jun 2012 14:26:08 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id ACBF620C44; Tue, 19 Jun 2012 23:26:07 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Da9oon-AWzym; Tue, 19 Jun 2012 23:26:07 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id AD40520C35; Tue, 19 Jun 2012 23:26:06 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id BCEEB2013595; Tue, 19 Jun 2012 23:26:05 +0200 (CEST) Date: Tue, 19 Jun 2012 23:26:05 +0200 From: Juergen Schoenwaelder To: Simon Perreault Message-ID: <20120619212604.GA72638@elstar.local> Mail-Followup-To: Simon Perreault , behave@ietf.org References: <20120619193826.GA23555@elstar.local> <9B57C850BB53634CACEC56EF4853FF653B666FE0@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <4FE0DA8D.8010709@viagenie.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4FE0DA8D.8010709@viagenie.ca> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: behave@ietf.org Subject: Re: [BEHAVE] new nat mib question X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2012 21:26:09 -0000 On Tue, Jun 19, 2012 at 04:01:17PM -0400, Simon Perreault wrote: > > Our draft defines new objects that don't duplicate any functionality > of 4008. It also doesn't build on top of 4008 in any way. > > I suppose we could obsolete 4008. But it feels strange obsoleting an > RFC with something completely different. > > I'm fully open to guidance. I can't provide the guidance. I think the document must explain how it relates to the NAT-MIB. The name NEW-NAT-MIB kind of suggests that this is a replacement of the NAT-MIB. But apparently this is not the case. I am likely just heavily confused and hence I ask for clarification how things relate. The I-D abstract says: This memo defines a portion of the Management Information Base (MIB) for devices implementing Network Address Translator (NAT) function. This MIB module may be used for monitoring of a device capable of NAT function. The abstract in RFC 4008 says: This memo defines a portion of the Management Information Base (MIB) for devices implementing Network Address Translator (NAT) function. This MIB module may be used for configuration as well as monitoring of a device capable of NAT function. This seems pretty much the same (except that the I-D leaves out configuration). Hence the question I am asking I think needs to be asked and answered (eventually in the document). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From simon.perreault@viagenie.ca Wed Jun 20 07:20:31 2012 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 6698C21F8775 for ; Wed, 20 Jun 2012 07:20:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-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 3xMXZ8srnpss for ; Wed, 20 Jun 2012 07:20:30 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id CF60B21F876E for ; Wed, 20 Jun 2012 07:20:29 -0700 (PDT) Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c064:415f:5dee:c87f:84f]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 525024036B for ; Wed, 20 Jun 2012 10:20:29 -0400 (EDT) Message-ID: <4FE1DC2C.1010002@viagenie.ca> Date: Wed, 20 Jun 2012 10:20:28 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1 MIME-Version: 1.0 To: behave@ietf.org References: <9B57C850BB53634CACEC56EF4853FF653B62BDA4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B66483D@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B66483D@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09 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, 20 Jun 2012 14:20:31 -0000 On 2012-06-18 20:00, Dave Thaler wrote: > We need at least 5 reviews on this document. Can we get two more volunteers? > Maybe Simon and/or Marc P.-H.? Anyone else? Here's my review... Major ----- > A node requiring information about presence of NAT64 and the > Pref64::/n used for protocol translation SHALL send a DNS query for > AAAA records of a well-known IPv4-only fully qualified domain name: > "ipv4only.arpa". Why is there a need for a well-known IPv4-only domain name with a well-known IPv4 address? Why can't this stuff be implementation-specific, as suggested in section 3.3? > The well-known name needs to map to at least two different global > IPv4 addresses. The addresses are to be taken from 192.0.0.0/24 > address block. Same preoccupation here. Why not leave this up to implementations? > In the case of more than one Pref64::/n were present in the DNS > response: a node SHOULD use all of them when determining whether > other received IPv6 addresses are synthetic. However, for selecting > Pref64::/n for the local IPv6 address synthesis node MUST use the > following prioritization order, of which purpose is to avoid use of > Pref64::/n containing suffixes reserved for the future [RFC6052]: > > 1. Use NSP having /96 prefix > > 2. Use WKP prefix > > 3. Use longest available NSP prefix I would assume that the reason for the ISP's use of multiple DNS64 prefixes would be DNS-based NAT64 load balancing. The above prioritization breaks that. In any case, it would be best if the host would try to mimic the DNS64 behaviour as much as possible so that the resulting NAT64 traffic patterns are not affected. That is, instead of picking one prefix and synthesizing a single AAAA record, synthesize a full AAAA RRset using all prefixes, and randomize the order of records. > 3. Each Pref64::/n MUST HAVE PTR record that points to corresponding > NAT64 FQDN. > > 4. Sign the NAT64 FQDNs' AAAA and A records with DNSSEC. Wouldn't it be better to sign the PTR record and have the host verify that signature instead of checking against a list of trusted domains? > The connectivity check protocol used with connectivity check servers > pointed by NAT64 FQDN's A records is ICMPv6 [RFC4443]. I understand that vendor checks are preferred over ICMPv6, but I still think recommending ICMPv6 at all is wrong. ICMP can fail for a myriad of reasons, including ICMP echo reply rate limiting. It is just not a good protocol to recommend as a connectivity check. If you do want to recommend one, I would suggest STUN. I would also be fine with not recommending one and only discussing vendor-specific checks. Minor ----- > The knowledge of IPv6 address synthesis taking place may also be > useful if DNS64 and NAT64 are present in dual-stack enabled access > networks or if a node is multi-interfaced [RFC6418]. In such cases > nodes may choose to prefer IPv4 or alternative network interface in > order to avoid traversal through protocol translators. I would s/in order to avoid traversal through protocol translators// since there's no guarantee that IPv4 will not be NATed. > It is important to notice that use of this approach will not result > in as robust, secure, and good behaving system as an all-IPv6 system > would be. Hence it is highly recommended to upgrade nodes' > destinations to IPv6 and utilize the described method only as a > short-term solution. Suggestion: s/short-term/transition/ > A DNS reply with one or more non-empty AAAA records indicates that > the access network is utilizing IPv6 address synthesis. It would be nice to note that DNS services that do NXRRSET hijacking will break this assumption. > The node should ensure a 32-bit IPv4 address value is present only > once in an IPv6 address. In case another instance of the value is > found inside the IPv6, the node shall repeat the search with another > IPv4 address, if possible. s/should/SHOULD/ ? s/shall/SHALL/ ? Why not MUST? What other IPv4 address? Isn't there a single well-known IPv4 address? > 3. Each Pref64::/n MUST HAVE PTR record that points to corresponding > NAT64 FQDN. This needs to be made more precise. Prefixes can't have PTR records (yet, there's a draft about that). Actually, I should be even more precise, since any domain name can "have" a PTR record. So, something like "For each Pref64::/n, there MUST be a PTR record for the domain name in the ip6.arpa tree corresponding to the Pref64:: address. That PTR record's value MUST be the corresponding NAT64 FQDN." > The node SHOULD use vendor specific connectivity check server and a > protocol of vendor's choice, but if that is not possible a node MAY > do a PTR query of the Pref64::/n that may return a hostname. Again, prefixes do not have associated PTR records. Addresses do. This text needs to be made more precise. > A node SHOULD implement configuration knob for disabling the > Pref64::/n discovery feature. Why not s/SHOULD/MUST/ ? Nits ---- > Abstract > > This document describes a method for detecting presence of DNS64 and > for learning IPv6 prefix used for protocol translation on an access ^the > network. The method depends on existence of a well-known IPv4-only ^the > domain name "ipv4only.arpa". The information learned enables nodes > to perform local IPv6 address synthesis and to potentially avoid > traversal through NAT64 on dual-stack accesses and multi-interface s/traversal through// > deployments. > The node SHOULD use vendor specific connectivity check server and a > protocol of vendor's choice Here and in other spots in the document, s/vendor/implementation/. Implementations don't necessarily involve a "vendor", particularly open-source ones. > The domain serving the well-known name must be signed with DNSSEC. s/must/MUST/ > The IPv4 addresses for the well-known name must not be non-global s/must not be non-global/MUST be global/ Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From ajs@anvilwalrusden.com Wed Jun 20 07:38:30 2012 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 4E66021F8742 for ; Wed, 20 Jun 2012 07:38:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 TGGEi96EPrZQ for ; Wed, 20 Jun 2012 07:38:29 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id C0B3821F86B4 for ; Wed, 20 Jun 2012 07:38:29 -0700 (PDT) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id D340E1ECB41D for ; Wed, 20 Jun 2012 14:38:28 +0000 (UTC) Date: Wed, 20 Jun 2012 10:38:26 -0400 From: Andrew Sullivan To: behave@ietf.org Message-ID: <20120620143826.GE41079@mail.yitter.info> References: <9B57C850BB53634CACEC56EF4853FF653B62BDA4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B66483D@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <4FE1DC2C.1010002@viagenie.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4FE1DC2C.1010002@viagenie.ca> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09 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, 20 Jun 2012 14:38:30 -0000 On Wed, Jun 20, 2012 at 10:20:28AM -0400, Simon Perreault wrote: > > A node requiring information about presence of NAT64 and the > > Pref64::/n used for protocol translation SHALL send a DNS query for > > AAAA records of a well-known IPv4-only fully qualified domain name: > > "ipv4only.arpa". > > Why is there a need for a well-known IPv4-only domain name with a > well-known IPv4 address? Why can't this stuff be > implementation-specific, as suggested in section 3.3? The reason I suppose the well-known name is because it will make caches more efficient. If it's a well-known name and everyone uses it, then every application is looking for the same name, meaning that for a host doing multiple things behind a DNS64 the answer will most of the time be cached. Otherwise, every application generates a bunch of housekeeping queries, and the global DNS has to do more work. > > 4. Sign the NAT64 FQDNs' AAAA and A records with DNSSEC. > > Wouldn't it be better to sign the PTR record and have the host > verify that signature instead of checking against a list of trusted > domains? Yes, but it won't work, because the delegation from the reverse tree won't be able to be signed because the response is always local. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From simon.perreault@viagenie.ca Wed Jun 20 08:32:15 2012 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 BF3E421F864D for ; Wed, 20 Jun 2012 08:32:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-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 KATwFJa5Jbuu for ; Wed, 20 Jun 2012 08:32:15 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 17AD021F864C for ; Wed, 20 Jun 2012 08:32:15 -0700 (PDT) Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c064:415f:5dee:c87f:84f]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 5C7A5415B9 for ; Wed, 20 Jun 2012 11:32:14 -0400 (EDT) Message-ID: <4FE1ECFD.3070102@viagenie.ca> Date: Wed, 20 Jun 2012 11:32:13 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1 MIME-Version: 1.0 To: behave@ietf.org References: <9B57C850BB53634CACEC56EF4853FF653B62BDA4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B66483D@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <4FE1DC2C.1010002@viagenie.ca> <20120620143826.GE41079@mail.yitter.info> In-Reply-To: <20120620143826.GE41079@mail.yitter.info> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09 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, 20 Jun 2012 15:32:15 -0000 On 2012-06-20 10:38, Andrew Sullivan wrote: > On Wed, Jun 20, 2012 at 10:20:28AM -0400, Simon Perreault wrote: >>> A node requiring information about presence of NAT64 and the >>> Pref64::/n used for protocol translation SHALL send a DNS query for >>> AAAA records of a well-known IPv4-only fully qualified domain name: >>> "ipv4only.arpa". >> >> Why is there a need for a well-known IPv4-only domain name with a >> well-known IPv4 address? Why can't this stuff be >> implementation-specific, as suggested in section 3.3? > > The reason I suppose the well-known name is because it will make > caches more efficient. If it's a well-known name and everyone uses > it, then every application is looking for the same name, meaning that > for a host doing multiple things behind a DNS64 the answer will most > of the time be cached. Otherwise, every application generates a bunch > of housekeeping queries, and the global DNS has to do more work. I really doubt it would make a difference in the grand scheme of things. >>> 4. Sign the NAT64 FQDNs' AAAA and A records with DNSSEC. >> >> Wouldn't it be better to sign the PTR record and have the host >> verify that signature instead of checking against a list of trusted >> domains? > > Yes, but it won't work, because the delegation from the reverse tree > won't be able to be signed because the response is always local. ...for the well-known name, which has addresses in 192.0.0.0. Implementation-specific names would not have this problem. Anyway, wouldn't this be a good reason not to use 192.0.0.0 and instead use a "regular" address that would be looked up normally? I mean, using DNSSEC all the way seems much better than the "list of trusted domains" hack. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From teemu.savolainen@nokia.com Wed Jun 20 09:44:06 2012 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 4984321F877B for ; Wed, 20 Jun 2012 09:44:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 636cLCUUHFyF for ; Wed, 20 Jun 2012 09:44:05 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id E86CA21F877E for ; Wed, 20 Jun 2012 09:44:04 -0700 (PDT) Received: from vaebh101.NOE.Nokia.com (in-mx.nokia.com [10.160.244.22]) by mgw-da02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q5KGi29q013356; Wed, 20 Jun 2012 19:44:02 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.26]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 20 Jun 2012 19:44:02 +0300 Received: from 008-AM1MPN1-053.mgdnok.nokia.com ([169.254.3.37]) by 008-AM1MMR1-010.mgdnok.nokia.com ([65.54.30.26]) with mapi id 14.02.0283.004; Wed, 20 Jun 2012 18:44:00 +0200 From: To: , Thread-Topic: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09 Thread-Index: AQHNTvnmHCkXE9jVm0GCoK+qK7SR8JcDaJTM Date: Wed, 20 Jun 2012 16:44:00 +0000 Message-ID: <916CE6CF87173740BC8A2CE443096962043AEA77@008-AM1MPN1-053.mgdnok.nokia.com> References: <9B57C850BB53634CACEC56EF4853FF653B62BDA4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B66483D@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <4FE1DC2C.1010002@viagenie.ca> <20120620143826.GE41079@mail.yitter.info>, <4FE1ECFD.3070102@viagenie.ca> In-Reply-To: <4FE1ECFD.3070102@viagenie.ca> 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 20 Jun 2012 16:44:02.0619 (UTC) FILETIME=[E604E8B0:01CD4F03] X-Nokia-AV: Clean Subject: Re: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09 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, 20 Jun 2012 16:44:06 -0000 Simon,=0A= =0A= A host implementation could very well use vendor specific well-known name a= s well and ignore this draft - it would work perfectly. However, for cases = where vendor specific name is not available (maybe not all application writ= ers, for example, do not have facilities to host their own names), the well= -known name is useful.=0A= =0A= I don't see how DNSSEC protecting PTR query would help in the "trusted doma= ins" question. All that host could learn is that PTR query can be verified = to be owned by badguys.hotspot.example.com, right?=0A= =0A= Best regards,=0A= =0A= Teemu=0A= =0A= ________________________________________=0A= From: behave-bounces@ietf.org [behave-bounces@ietf.org] on behalf of ext Si= mon Perreault [simon.perreault@viagenie.ca]=0A= Sent: Wednesday, June 20, 2012 6:32 PM=0A= To: behave@ietf.org=0A= Subject: Re: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-h= euristic-09=0A= =0A= On 2012-06-20 10:38, Andrew Sullivan wrote:=0A= > On Wed, Jun 20, 2012 at 10:20:28AM -0400, Simon Perreault wrote:=0A= >>> A node requiring information about presence of NAT64 and the=0A= >>> Pref64::/n used for protocol translation SHALL send a DNS query for= =0A= >>> AAAA records of a well-known IPv4-only fully qualified domain name:= =0A= >>> "ipv4only.arpa".=0A= >>=0A= >> Why is there a need for a well-known IPv4-only domain name with a=0A= >> well-known IPv4 address? Why can't this stuff be=0A= >> implementation-specific, as suggested in section 3.3?=0A= >=0A= > The reason I suppose the well-known name is because it will make=0A= > caches more efficient. If it's a well-known name and everyone uses=0A= > it, then every application is looking for the same name, meaning that=0A= > for a host doing multiple things behind a DNS64 the answer will most=0A= > of the time be cached. Otherwise, every application generates a bunch=0A= > of housekeeping queries, and the global DNS has to do more work.=0A= =0A= I really doubt it would make a difference in the grand scheme of things.=0A= =0A= >>> 4. Sign the NAT64 FQDNs' AAAA and A records with DNSSEC.=0A= >>=0A= >> Wouldn't it be better to sign the PTR record and have the host=0A= >> verify that signature instead of checking against a list of trusted=0A= >> domains?=0A= >=0A= > Yes, but it won't work, because the delegation from the reverse tree=0A= > won't be able to be signed because the response is always local.=0A= =0A= ...for the well-known name, which has addresses in 192.0.0.0.=0A= Implementation-specific names would not have this problem.=0A= =0A= Anyway, wouldn't this be a good reason not to use 192.0.0.0 and instead=0A= use a "regular" address that would be looked up normally? I mean, using=0A= DNSSEC all the way seems much better than the "list of trusted domains"=0A= hack.=0A= =0A= Simon=0A= --=0A= DTN made easy, lean, and smart --> http://postellation.viagenie.ca=0A= NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca=0A= STUN/TURN server --> http://numb.viagenie.ca=0A= _______________________________________________=0A= Behave mailing list=0A= Behave@ietf.org=0A= https://www.ietf.org/mailman/listinfo/behave=0A= From teemu.savolainen@nokia.com Wed Jun 20 10:18:03 2012 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 ACBAD21F879D for ; Wed, 20 Jun 2012 10:18:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 yRK2sxugZ6I8 for ; Wed, 20 Jun 2012 10:18:03 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id D86D821F879C for ; Wed, 20 Jun 2012 10:18:02 -0700 (PDT) Received: from vaebh104.NOE.Nokia.com (in-mx.nokia.com [10.160.244.30]) by mgw-da02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q5KHI1Hj007326; Wed, 20 Jun 2012 20:18:01 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.60]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 20 Jun 2012 20:18:01 +0300 Received: from 008-AM1MPN1-053.mgdnok.nokia.com ([169.254.3.37]) by 008-AM1MMR1-005.mgdnok.nokia.com ([65.54.30.60]) with mapi id 14.02.0283.004; Wed, 20 Jun 2012 19:17:59 +0200 From: To: , Thread-Topic: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09 Thread-Index: Ac1AW6tggKyYFn88QeSiVcin492nCQNUTNngABJ72YAAEjm1gAAxzLeQ Date: Wed, 20 Jun 2012 17:17:59 +0000 Message-ID: <916CE6CF87173740BC8A2CE443096962043AEADD@008-AM1MPN1-053.mgdnok.nokia.com> References: <9B57C850BB53634CACEC56EF4853FF653B62BDA4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B664824@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <916CE6CF87173740BC8A2CE443096962043AD71A@008-AM1MPN1-053.mgdnok.nokia.com> <9B57C850BB53634CACEC56EF4853FF653B666DF6@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B666DF6@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Nokia Internal Use Only;Project=None; x-titus-version: 3.3.8.1 x-headerinfofordlp: None x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7Ili3MCvCLXmrxYjzLlJRY6FHY/pHjF6tFjgSe2JwmNBmRPgvRO9PTHSy6iVyvbVrfjFTfBeIiJxDMl435gppXWJM9ioOFyE1MciyhwUjL5O1d0Wu0m9Qw1lMfT4vy6hM/SZnJ5KJXhAZvyzfBr4AM8ngFE8ebkwaL/dXbpJmXNaDKESunn1ijQdKRh8bfHWaAbil8FJSf0e2NjaXTMbFeuhkBshLubOMLW2ouY/855XU/PNE6yW1FNSTPOIiQoSxV9CZ+vYekUdIRYox+7HWMvk= x-originating-ip: [10.163.16.207] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 20 Jun 2012 17:18:01.0629 (UTC) FILETIME=[A55D24D0:01CD4F08] X-Nokia-AV: Clean Cc: behave@ietf.org Subject: Re: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09 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, 20 Jun 2012 17:18:03 -0000 Inline, again: > -----Original Message----- > From: ext Dave Thaler [mailto:dthaler@microsoft.com] > Sent: 19. kes=E4kuuta 2012 22:20 > To: Savolainen Teemu (Nokia-NRC/Tampere); draft-ietf-behave-nat64- > discovery-heuristic@tools.ietf.org > Cc: behave@ietf.org > Subject: RE: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuris= tic- > 09 > > > 1) I didn't follow why an A record query is needed or useful. > > > > If a host needs to know whether the well-known name service is up and > > running (no A record would explain lack of synthetic AAAA record). >=20 > I don't see any discussion of this in the doc. Either the A record quer= y > should be removed or else it should be explained how it's used as part of= the > algorithm. The beginning of section 3 tries to say this: -- The node MAY also need to perform DNS query for the A record of the well-known name in order to learn what is the IPv4 address of the well-known name and if the A record even exists -- but I admit this is weak text. We wanted to avoid A queries all the time... Let me think: If a node gets a positive response to an AAAA query for the well-known name= , the host learns presence of DNS64. Lack of AAAA response could mean eithe= r no DNS64 or no A record for the well-known name. Perhaps we could say that, lacking positive response to AAAA query, node co= uld do at a new 3.1.2 step "1.5" an A query to see if the A record exist. I= f A record is there, then network does not have DNS64 (and in case of IPv6-= only network, does not provide translation services). > > If a host has not hard-coded the well-known IPv4 address and the host > > wants to learn it on the go. >=20 > Why would a host not hard-code it/them? To allow flexibility for the future:) But perhaps this flexibility could be= a problem.. and we could state that hosts can hard code the address. > > We could say 10 minutes before expiry, and then on the TTL place > > requirement for minimum TTL (I drew minimum TTL of 60 minutes out > > from thin air). Would it be better? >=20 > Much better. Though 10 minutes seems long. It just has to be long > enough to have a very high probability of succeeding before expiry (takin= g > into account, loss, retries, etc.). Usually DNS is fast.. 10 seconds? Or define PREF64_DISCOVERY_THRESHOLD to b= e 10 secs by default. Best regards, Teemu From teemu.savolainen@nokia.com Wed Jun 20 10:31:59 2012 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 BF45621F842B for ; Wed, 20 Jun 2012 10:31:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 8AmFuszFR+LN for ; Wed, 20 Jun 2012 10:31:58 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 946A421F8427 for ; Wed, 20 Jun 2012 10:31:58 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (in-mx.nokia.com [10.160.244.32]) by mgw-da02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q5KHVuvt017110; Wed, 20 Jun 2012 20:31:57 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.25]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 20 Jun 2012 20:31:57 +0300 Received: from 008-AM1MPN1-053.mgdnok.nokia.com ([169.254.3.37]) by 008-AM1MMR1-009.mgdnok.nokia.com ([65.54.30.25]) with mapi id 14.02.0283.004; Wed, 20 Jun 2012 19:31:55 +0200 From: To: , Thread-Topic: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09 Thread-Index: AQHNTu/XgKyYFn88QeSiVcin492nCZcDc6vw Date: Wed, 20 Jun 2012 17:31:55 +0000 Message-ID: <916CE6CF87173740BC8A2CE443096962043AEAFE@008-AM1MPN1-053.mgdnok.nokia.com> References: <9B57C850BB53634CACEC56EF4853FF653B62BDA4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B66483D@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <4FE1DC2C.1010002@viagenie.ca> In-Reply-To: <4FE1DC2C.1010002@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Nokia Internal Use Only;Project=None; x-titus-version: 3.3.8.1 x-headerinfofordlp: None x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7Ili3MCvCLXmrxYjzLlJRY6FHY/pHjF6tFjgSe2JwmNBmRPgvRO9PTHSy6iVyvbVrfjFTfBeIiJxDMl435gppXWJM9ioOFyE1MciyhwUjL5O1d0Wu0m9Qw1lMfT4vy6hM/SZnJ5KJXhAZvyzfBr4AM8ngFE8ebkwaL/dXbpJmXNaDKESunn1ijQdKRh8bfHWaAbil8FJSf0e2NjaXTMbFeuhkBshLubOMLW2ouY/855XU/PNE6yW1FNSTPOIiQoSxV9CZ+vYekUdIRYox+7HWMvk= x-originating-ip: [10.163.16.207] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 20 Jun 2012 17:31:57.0121 (UTC) FILETIME=[975B1B10:01CD4F0A] X-Nokia-AV: Clean Subject: Re: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09 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, 20 Jun 2012 17:31:59 -0000 Hi Simon, Thank you for your review. On some of these I replied in another email, her= e for the rest: > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf > Of ext Simon Perreault > Sent: 20. kes=E4kuuta 2012 17:20 > To: behave@ietf.org > Subject: Re: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuris= tic- > 09 > > > following prioritization order, of which purpose is to avoid use of > > Pref64::/n containing suffixes reserved for the future [RFC6052]: > > > > 1. Use NSP having /96 prefix > > > > 2. Use WKP prefix > > > > 3. Use longest available NSP prefix > > I would assume that the reason for the ISP's use of multiple DNS64 prefix= es > would be DNS-based NAT64 load balancing. The above prioritization breaks > that. In any case, it would be best if the host would try to mimic the DN= S64 > behaviour as much as possible so that the resulting NAT64 traffic pattern= s are > not affected. That is, instead of picking one prefix and synthesizing a s= ingle > AAAA record, synthesize a full AAAA RRset using all prefixes, and randomi= ze > the order of records. The intent of the prioritization is to attempt avoiding possible issues if = in future some meaning is encoded into suffix-fields of Figure 1 of RFC6052= . The host cannot know what to put in suffixes of synthetized addresses, he= nce the host could try to avoid using Pref64::/n that has suffix-field. We = could say that if there are multiple Pref64::/n of same priority available,= a host SHOULD use them all in local synthesis process e.g. in round-robin = manner? Would that suffice? > I understand that vendor checks are preferred over ICMPv6, but I still th= ink > recommending ICMPv6 at all is wrong. ICMP can fail for a myriad of reason= s, > including ICMP echo reply rate limiting. It is just not a good protocol t= o > recommend as a connectivity check. If you do want to recommend one, I > would suggest STUN. I would also be fine with not recommending one and > only discussing vendor-specific checks. We recommend hosts to use vendor specific connectivity check servers with v= endor specific protocols (which may be STUN). But for this operator hosted = service... well, I guess STUN could be there as well (although it requires = then STUN implementation for the host / application + STUN hosting. I'm not= sure that is fair to require). After all, connectivity check is not that m= andatory - host can just synthetize and see whether connections succeed or = not. > > The knowledge of IPv6 address synthesis taking place may also be > > useful if DNS64 and NAT64 are present in dual-stack enabled access > > networks or if a node is multi-interfaced [RFC6418]. In such cases > > nodes may choose to prefer IPv4 or alternative network interface in > > order to avoid traversal through protocol translators. > > I would s/in order to avoid traversal through protocol translators// sinc= e > there's no guarantee that IPv4 will not be NATed. I didn't understand your comment.. The intent is to avoid IPv6->IPv4 protoc= ol translation - not to avoid address translation.. > > It is important to notice that use of this approach will not result > > in as robust, secure, and good behaving system as an all-IPv6 system > > would be. Hence it is highly recommended to upgrade nodes' > > destinations to IPv6 and utilize the described method only as a > > short-term solution. > > Suggestion: s/short-term/transition/ Ok > > A DNS reply with one or more non-empty AAAA records indicates that > > the access network is utilizing IPv6 address synthesis. > > It would be nice to note that DNS services that do NXRRSET hijacking will > break this assumption. You mean captive portals? Hmh.. do they return something even if the domain= name is not in use? If so, we can add this and note that hijacking will no= t result in Pref64::/n discovery (unless the returned address actually cont= ains well-known address:) > > The node should ensure a 32-bit IPv4 address value is present only > > once in an IPv6 address. In case another instance of the value is > > found inside the IPv6, the node shall repeat the search with another > > IPv4 address, if possible. > > s/should/SHOULD/ ? Yes > s/shall/SHALL/ ? Yes > Why not MUST? Right.. Let's use MUST. > What other IPv4 address? Isn't there a single well-known IPv4 address? The intent is to define at least two well-known IPv4 addresses. Maybe two i= s enough, as three probably gives marginal benefit. > > 3. Each Pref64::/n MUST HAVE PTR record that points to correspondin= g > > NAT64 FQDN. > > This needs to be made more precise. Prefixes can't have PTR records (yet, > there's a draft about that). Actually, I should be even more precise, sin= ce any > domain name can "have" a PTR record. So, something like "For each > Pref64::/n, there MUST be a PTR record for the domain name in the ip6.arp= a > tree corresponding to the Pref64:: address. That PTR record's value MUST = be > the corresponding NAT64 FQDN." We explain what the PTR record should look like elsewhere in the document, = but this can be clarified further. > > A node SHOULD implement configuration knob for disabling the > > Pref64::/n discovery feature. > > Why not s/SHOULD/MUST/ ? I do not believe any configurability requirement can be MUST in reality, as= many kinds of devices and applications come with little to none configurat= ion possibilities... Best regards, Teemu From simon.perreault@viagenie.ca Wed Jun 20 11:23:44 2012 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 90CAF21F8793 for ; Wed, 20 Jun 2012 11:23:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-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 1PDq2lMsaIQn for ; Wed, 20 Jun 2012 11:23:43 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 9DABA21F8724 for ; Wed, 20 Jun 2012 11:23:43 -0700 (PDT) Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c064:415f:5dee:c87f:84f]) by jazz.viagenie.ca (Postfix) with ESMTPSA id C1F59415B9; Wed, 20 Jun 2012 14:23:42 -0400 (EDT) Message-ID: <4FE2152D.7040402@viagenie.ca> Date: Wed, 20 Jun 2012 14:23:41 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1 MIME-Version: 1.0 To: teemu.savolainen@nokia.com References: <9B57C850BB53634CACEC56EF4853FF653B62BDA4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B66483D@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <4FE1DC2C.1010002@viagenie.ca> <20120620143826.GE41079@mail.yitter.info>, <4FE1ECFD.3070102@viagenie.ca> <916CE6CF87173740BC8A2CE443096962043AEA77@008-AM1MPN1-053.mgdnok.nokia.com> In-Reply-To: <916CE6CF87173740BC8A2CE443096962043AEA77@008-AM1MPN1-053.mgdnok.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: behave@ietf.org Subject: Re: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09 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, 20 Jun 2012 18:23:44 -0000 On 2012-06-20 12:44, teemu.savolainen@nokia.com wrote: > A host implementation could very well use vendor specific well-known > name as well and ignore this draft - it would work perfectly. > However, for cases where vendor specific name is not available (maybe > not all application writers, for example, do not have facilities to > host their own names), the well-known name is useful. Makes sense, thanks. > I don't see how DNSSEC protecting PTR query would help in the > "trusted domains" question. All that host could learn is that PTR > query can be verified to be owned by badguys.hotspot.example.com, > right? I see. I have two concerns with the trusted domains list. My first concern is that it doesn't really add any security. If you come visit me to my office, where we run a NAT64, and I really want you to discover our prefix securely without you having to click through a scary dialog box, I will just squat the prefix of someone else who is probably already on the list (e.g., nokia.com), and route it to our NAT64 box. I didn't add any security, but somehow your client thinks this is secure. I just picked a different prefix, one that is in your client's "secure" set. My second concern is that it allows the people who control domains that are on the list to do evil things. Here's an example attack: the owner of nokia.com, which is on the list, turns evil. He goes in any public NAT64 hotspot and starts a rogue DNS64 server with a Pref64::/n that belongs to nokia.com. That prefix is routed to a NAT64 that belongs to Nokia, somewhere in the Internet. The prefix will be "securely discovered" because all the appropriate DNS records are present and signed, the NAT64 works, and nokia.com is on the list, yet Nokia would be hijacking traffic. In a nutshell, the proposed secure method of Pref64::/n discovery ensures that the DNS64 is controlled by an entity that also controls a domain name that is on a trusted list. That's not what "secure discovery" should be, IMHO. I would expect secure discovery to ensure that the DNS64 is controlled by the same entity that controls the network on which the client is. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From simon.perreault@viagenie.ca Wed Jun 20 11:43:35 2012 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 22C6A21F8667 for ; Wed, 20 Jun 2012 11:43:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-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 e0pyX1sr3EIv for ; Wed, 20 Jun 2012 11:43:34 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id E734421F8645 for ; Wed, 20 Jun 2012 11:43:33 -0700 (PDT) Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c064:415f:5dee:c87f:84f]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 28BB2415B9; Wed, 20 Jun 2012 14:43:33 -0400 (EDT) Message-ID: <4FE219D4.5060002@viagenie.ca> Date: Wed, 20 Jun 2012 14:43:32 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1 MIME-Version: 1.0 To: teemu.savolainen@nokia.com References: <9B57C850BB53634CACEC56EF4853FF653B62BDA4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B66483D@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <4FE1DC2C.1010002@viagenie.ca> <916CE6CF87173740BC8A2CE443096962043AEAFE@008-AM1MPN1-053.mgdnok.nokia.com> In-Reply-To: <916CE6CF87173740BC8A2CE443096962043AEAFE@008-AM1MPN1-053.mgdnok.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: behave@ietf.org Subject: Re: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09 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, 20 Jun 2012 18:43:35 -0000 On 2012-06-20 13:31, teemu.savolainen@nokia.com wrote: > The intent of the prioritization is to attempt avoiding possible > issues if in future some meaning is encoded into suffix-fields of > Figure 1 of RFC6052. The host cannot know what to put in suffixes of > synthetized addresses, hence the host could try to avoid using > Pref64::/n that has suffix-field. We could say that if there are > multiple Pref64::/n of same priority available, a host SHOULD use > them all in local synthesis process e.g. in round-robin manner? Would > that suffice? I think that would be fine if you only define two priority levels: 1. (highest priority) Prefix without suffix-field. 2. (lowest priority) Prefix with suffix-field. > We recommend hosts to use vendor specific connectivity check servers > with vendor specific protocols (which may be STUN). But for this > operator hosted service... well, I guess STUN could be there as well > (although it requires then STUN implementation for the host / > application + STUN hosting. I'm not sure that is fair to require). On the client side STUN is arguably easier than ICMP because you don't need access to raw sockets, it's just really simple UDP. On the server side ICMP has issues too because operating systems usually rate limit echo replies. > After all, connectivity check is not that mandatory - host can just > synthetize and see whether connections succeed or not. Absolutely. I wouldn't mind if you just removed all references to ICMP without replacing them with STUN. My point is that recommending ICMP, even as an operator hosted service, really isn't a good idea because ICMP is really bad at this for a number of operational reasons. >>> The knowledge of IPv6 address synthesis taking place may also be >>> useful if DNS64 and NAT64 are present in dual-stack enabled >>> access networks or if a node is multi-interfaced [RFC6418]. In >>> such cases nodes may choose to prefer IPv4 or alternative network >>> interface in order to avoid traversal through protocol >>> translators. >> >> I would s/in order to avoid traversal through protocol >> translators// since there's no guarantee that IPv4 will not be >> NATed. > > I didn't understand your comment.. The intent is to avoid IPv6->IPv4 > protocol translation - not to avoid address translation.. You're right. >>> A DNS reply with one or more non-empty AAAA records indicates >>> that the access network is utilizing IPv6 address synthesis. >> >> It would be nice to note that DNS services that do NXRRSET >> hijacking will break this assumption. > > You mean captive portals? I was thinking of something like OpenDNS, but I guess some captive portals do it too. > Hmh.. do they return something even if the > domain name is not in use? OpenDNS synthesizes an A RRset for domain names that don't exist (NXDOMAIN hijacking) as well as for domain names that do exist but don't have an A RRset (NXRRSET hijacking). They don't do it for AAAA, but I guess it's just a matter of time. > If so, we can add this and note that > hijacking will not result in Pref64::/n discovery (unless the > returned address actually contains well-known address:) Yes, that would be fine. >>> The node should ensure a 32-bit IPv4 address value is present >>> only once in an IPv6 address. In case another instance of the >>> value is found inside the IPv6, the node shall repeat the search >>> with another IPv4 address, if possible. >> >> What other IPv4 address? Isn't there a single well-known IPv4 >> address? > > The intent is to define at least two well-known IPv4 addresses. Maybe > two is enough, as three probably gives marginal benefit. Ok, it wasn't clear to me from the text. Maybe rephrase somehow... >>> A node SHOULD implement configuration knob for disabling the >>> Pref64::/n discovery feature. >> >> Why not s/SHOULD/MUST/ ? > > I do not believe any configurability requirement can be MUST in > reality, as many kinds of devices and applications come with little > to none configuration possibilities... Ok. Thanks, Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From dwing@cisco.com Wed Jun 20 14:51:02 2012 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 86FCC21F8606 for ; Wed, 20 Jun 2012 14:51:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 cPAdxhAuDnfi for ; Wed, 20 Jun 2012 14:51:01 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 2CFEF21F8604 for ; Wed, 20 Jun 2012 14:51:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1015; q=dns/txt; s=iport; t=1340229061; x=1341438661; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=jbOsSBanVTa78+oA75dHtUFVwygrpFVxjqypl8WMnOU=; b=cDxRJxj/YId+SWD6u2u6XHDgIHVUx0rhtkU+h+2dje9YdgD6nbG2pF3g qAqq+xg03yPOQ0uDOHoTLwUBw8xC0hFb6jA/ri1HOBH5squfw/lhwVxum P6pO56Y/8W+ZudCAfQ441uel4pn2LCW4QN8XB9EEYVQgAkawLLGXFZCuk Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAI1E4k+rRDoH/2dsb2JhbABFplyOdoEHghgBAQEDAQgKARcQPw0DAgkPNxkjGwEBBAEbAheHZAQMmGqgQ5FJA4hGhQKVfYFmgn8 X-IronPort-AV: E=Sophos;i="4.77,447,1336348800"; d="scan'208";a="49564915" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 20 Jun 2012 21:51:01 +0000 Received: from dwingWS ([10.32.240.198]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q5KLp0gK022569; Wed, 20 Jun 2012 21:51:00 GMT From: "Dan Wing" To: "'Simon Perreault'" , References: <9B57C850BB53634CACEC56EF4853FF653B62BDA4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B66483D@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <4FE1DC2C.1010002@viagenie.ca> <916CE6CF87173740BC8A2CE443096962043AEAFE@008-AM1MPN1-053.mgdnok.nokia.com> <4FE219D4.5060002@viagenie.ca> In-Reply-To: <4FE219D4.5060002@viagenie.ca> Date: Wed, 20 Jun 2012 14:51:00 -0700 Message-ID: <023b01cd4f2e$c8294450$587bccf0$@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: Ac1PFJt5SkSZi7lvQa2chc9dZpC7SQAGWLJQ Content-Language: en-us Cc: behave@ietf.org Subject: Re: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09 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, 20 Jun 2012 21:51:02 -0000 ... > > Hmh.. do they return something even if the > > domain name is not in use? > > OpenDNS synthesizes an A RRset for domain names that don't exist > (NXDOMAIN hijacking) as well as for domain names that do exist but > don't > have an A RRset (NXRRSET hijacking). They don't do it for AAAA, but I > guess it's just a matter of time. Chrome, and possibly other software, tests for such functionality by looking up known-bogus FQDNs, http://www.forensicswiki.org/wiki/Google_Chrome#Start-up_DNS_queries > > If so, we can add this and note that > > hijacking will not result in Pref64::/n discovery (unless the > > returned address actually contains well-known address:) > > Yes, that would be fine. I suggest, NXDOMAIN and NXRRSET hijacking may result in a false positive. One method to detect such hijacking is to query a FQDN that is known to be invalid (and normally return an empty response or an error response) and see if it returns a valid resource record. -d From petithug@acm.org Wed Jun 20 15:39:10 2012 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 A1F3F11E80C6 for ; Wed, 20 Jun 2012 15:39:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.028, 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 MaTWUu8EnC6N for ; Wed, 20 Jun 2012 15:39:09 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id CAD3D11E80A5 for ; Wed, 20 Jun 2012 15:39:09 -0700 (PDT) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (unknown [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id B130020447; Wed, 20 Jun 2012 22:39:07 +0000 (UTC) Message-ID: <4FE250F5.5010505@acm.org> Date: Wed, 20 Jun 2012 15:38:45 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.4) Gecko/20120510 Icedove/10.0.4 MIME-Version: 1.0 To: Dave Thaler References: <9B57C850BB53634CACEC56EF4853FF653B62BDA4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B66483D@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B66483D@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "behave@ietf.org" Subject: Re: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09 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, 20 Jun 2012 22:39:11 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 06/18/2012 05:00 PM, Dave Thaler wrote: > So far I've seen 3 reviews: * Andrew Sullivan * Aaron Yi DING * Dave > Thaler > > We need at least 5 reviews on this document. Can we get two more > volunteers? Maybe Simon and/or Marc P.-H.? Anyone else? > 1. Section 3.2 It seems to me that using ICMP connectivity checks cannot be done with the Well-Known Prefix, as it is not possible to register a PTR RR for each domain using it. This should be said somewhere as this is a good reason to prefer a Network Specific Prefix if connectivity check are to be deployed in the future. 2. Section 3.3 "...to perform a function similar to ipv4-only.arpa, ..." It should be "ipv4only.arpa" Which bring another question: Was the intent to use specifically ipv4-only. (or ipv4only.), i.e. is the leftmost component fixed, or is the whole domain name provisionable? 3. Appendix A "nat64.example.org IN AAAA..." Why is that RR in the example? I cannot find in the normative text how this is used. Besides it seems malformed (IP address is 14 bytes long, and the "nat64.example.com." at the end of the line should be at the beginning of the the next line). Nits ==== - - Section 3.1.1, third bullet s/MUST HAVE/MUST have/ - - Section 3.2 last paragraph s/mode/node/ - - Section 3.3: s/. DNS For example/. For example/ - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJP4lDzAAoJECnERZXWan7EBuoP/RiXlQhpavcLhEjZwAofDYUW R/q9dIgu4XQU6IiJoXwDeDFVPhe73OpI7oOmf4k58GsgUQMRAp0hyFQQybrt+God 6ioLDJWui4u/kstRQnWRgUDUacW8GUMXpiQZribEqaBNhMfm3Y4VCs6HFcp6HuHW QzmRWlddtILU4IhWL4sDzFwkPDQk8uPxilit+OHi0ty89teP6AHtKBVYaPeQLl6+ Wp9uSte260gmd2OyntBVmXEi/DnMs3fv1TbZUjAcU/bRjj2MIIWHSk8wmfPE9r0I uiHdYisOnN/ganydQ4zIK5yYGdlEVXEk5wclighSOeTQo10DCREifOEUURgGCaIv nS6hCQtFIJ/UW0hT4fdr34qTi8eJTfl3cza71TSRSXrYOMVAs5tR/ChX1cKZDJWv yNmk08xQfvulAjqdCRjExnUPqrZueLAy0dmlN9MMtgtXmELTanIYhHFLmVL1YK7n XlbRCDblI0RliI3M7Jtp0k/suFaSPor4l+XauNKgM2RhuVUjuPWum3oY49gevAYM rg+8EoD4sKz3tTo/kb9+z+goHCeARap0EL5x5fFUuYHBxMTTK+uCJhJBC/31D9kN aQUouZq2Rf6yKTGRjOHRts+iz3KZYF5U31rMBbR/Y0R2NSs/3OOP3haWQdJLF7g3 8VPnEZ9LgF6dRFpaEkxa =/C5v -----END PGP SIGNATURE----- From marka@isc.org Wed Jun 20 19:28:10 2012 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 DC2E111E808D for ; Wed, 20 Jun 2012 19:28:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.374 X-Spam-Level: X-Spam-Status: No, score=-2.374 tagged_above=-999 required=5 tests=[AWL=0.225, 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 9MKqDkz8sRnV for ; Wed, 20 Jun 2012 19:28:10 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 2FFA511E8079 for ; Wed, 20 Jun 2012 19:28:10 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS id 8BE70C9505; Thu, 21 Jun 2012 02:27:58 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:c9d9:2292:9e76:c82d]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id E306A216C33; Thu, 21 Jun 2012 02:27:43 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id A5FA021C825E; Thu, 21 Jun 2012 12:27:36 +1000 (EST) To: Dave Thaler , "behave@ietf.org" From: Mark Andrews References: <9B57C850BB53634CACEC56EF4853FF653B62BDA4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B66483D@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <4FE250F5.5010505@acm.org> In-reply-to: Your message of "Wed, 20 Jun 2012 15:38:45 MST." <4FE250F5.5010505@acm.org> Date: Thu, 21 Jun 2012 12:27:36 +1000 Message-Id: <20120621022736.A5FA021C825E@drugs.dv.isc.org> Subject: Re: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09 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, 21 Jun 2012 02:28:11 -0000 Firstly this draft will not work with a non DNS64 aware intermediate name servers as it will not understand the CD signaling. This goup needs to accept that intermediate name servers will need to be DNS64 aware and go back and redo RFC 6147 accepting that. DNSSEC made the same mistake of trying to make a change work through non DNSSEC aware servers. We gave up trying to do that and accepted that intermediate servers needed to be DNSSEC aware. This working group has continually failed to understand how DNSSEC works. It wanted DNS64 to work with existing DNSSEC aware infrustucture which was specifically designed to defeat what DNS64 does. Instead of saying "We need to make intermediate resolvers DNS64 aware" and accept that DNS64 won't work until those servers are upgraded the same way as dnsext said "We need to make intermediate resolvers DNSSEC aware" it tried to do the impossible. Sending a synthesised response to a DO=1 query is *insane* if the NO DATA response is signed but that is what RFC 6147 says to do. A sane thing to do would have been to add a EDNS extension which returned the synthesised addresses along with the NO DATA response to DNS64 aware clients (signalled by the presence of the option in the query). For non DNS64 aware clients you synthesis unless the synthesis can be detected (DO=1 + a signed NODATA response) in which case you send the signed NO DATA response. The intermediate DNS64 aware recursive server would cache both the NO DATA response and the synthesised addresses from the returned option data. For non DNS64 aware clients the synthesised responses would be returned to clients that can't detect the synthesis and NO DATA would be returned to those that can. For DNS64 aware client the full response would be sent. The EDNS option could also be used to discover prefix information if in addition to the addresses to also sent prefix length data. Query: Response: or []+ If the client has a trust relationship with its recursive server to can trust the answer returned and use that to set AD as appropriate to down stream clients. EDNS support is manditory for IPv6 nodes. There is no reason to avoid using it. Go back and fix RFC 6147 to work properly with DNSSEC. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From marka@isc.org Wed Jun 20 21:07:33 2012 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 DC3BE11E809C for ; Wed, 20 Jun 2012 21:07:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.803 X-Spam-Level: X-Spam-Status: No, score=-1.803 tagged_above=-999 required=5 tests=[AWL=-0.496, BAYES_00=-2.599, MISSING_HEADERS=1.292] 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 AUuTML0KALEP for ; Wed, 20 Jun 2012 21:07:33 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 7CB5511E8079 for ; Wed, 20 Jun 2012 21:07:33 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS id 6562EC953D; Thu, 21 Jun 2012 04:07:22 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:c9d9:2292:9e76:c82d]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 7D900216C36; Thu, 21 Jun 2012 04:07:20 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 628E221C9471; Thu, 21 Jun 2012 14:07:14 +1000 (EST) From: Mark Andrews References: <9B57C850BB53634CACEC56EF4853FF653B62BDA4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B66483D@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <4FE250F5.5010505@acm.org> <20120621022736.A5FA021C825E@drugs.dv.isc.org> In-reply-to: Your message of "Thu, 21 Jun 2012 12:27:36 +1000." <20120621022736.A5FA021C825E@drugs.dv.isc.org> Date: Thu, 21 Jun 2012 14:07:13 +1000 Message-Id: <20120621040714.628E221C9471@drugs.dv.isc.org> Cc: "behave@ietf.org" , Dave Thaler Subject: Re: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09 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, 21 Jun 2012 04:07:34 -0000 In message <20120621022736.A5FA021C825E@drugs.dv.isc.org>, Mark Andrews writes: > > Firstly this draft will not work with a non DNS64 aware intermediate > name servers as it will not understand the CD signaling. This goup > needs to accept that intermediate name servers will need to be DNS64 > aware and go back and redo RFC 6147 accepting that. I suppose I should explain breakage. CD=1 queries can be cached after validation so you can't depend on CD=0 returning synthesised records. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From teemu.savolainen@nokia.com Thu Jun 21 00:12:17 2012 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 59A5611E8083 for ; Thu, 21 Jun 2012 00:12:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 U+EZ6wAAjwiA for ; Thu, 21 Jun 2012 00:12:16 -0700 (PDT) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id A807821F8523 for ; Thu, 21 Jun 2012 00:12:15 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-sa02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q5L7BurA024125; Thu, 21 Jun 2012 10:12:04 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.60]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 21 Jun 2012 10:12:00 +0300 Received: from 008-AM1MPN1-053.mgdnok.nokia.com ([169.254.3.37]) by 008-AM1MMR1-005.mgdnok.nokia.com ([65.54.30.60]) with mapi id 14.02.0283.004; Thu, 21 Jun 2012 09:11:58 +0200 From: To: Thread-Topic: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09 Thread-Index: AQHNT30ldLiJvmyt7UWhmN4ulcOpfw== Date: Thu, 21 Jun 2012 07:11:58 +0000 Message-ID: <916CE6CF87173740BC8A2CE443096962043AEEBF@008-AM1MPN1-053.mgdnok.nokia.com> References: <9B57C850BB53634CACEC56EF4853FF653B62BDA4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B66483D@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <4FE1DC2C.1010002@viagenie.ca> <20120620143826.GE41079@mail.yitter.info>, <4FE1ECFD.3070102@viagenie.ca> <916CE6CF87173740BC8A2CE443096962043AEA77@008-AM1MPN1-053.mgdnok.nokia.com> <4FE2152D.7040402@viagenie.ca> In-Reply-To: <4FE2152D.7040402@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Nokia Internal Use Only;Project=None; x-titus-version: 3.3.8.1 x-headerinfofordlp: None x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7Ili3MCvCLXmrxYjzLlJRY6GRYSEESzssJdyl1KtGXxHbRz0f/N8DTFypsncJtFw5H6dEgLNn6I2DYQI1slWstWQLhts4Ao1Rvb7G9B7pZe+oW16aK60T/IZngo/xmoWZz4wl3U9iTRcWTIqdcQ9m+D6PMygWim2QOfgvTOlhx5yWE5M3n/txRnmqEif0/5bbQ+J8mO2cgxvdGCXg3S53/kMBDEDpT6rEg0W0aLtjGxqfiUPHRHRyqxYxC1TLq7ISAU6PK2jG5Ob6ktz5oQfnmV8= x-originating-ip: [10.163.16.207] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 21 Jun 2012 07:12:00.0880 (UTC) FILETIME=[2714E700:01CD4F7D] X-Nokia-AV: Clean Cc: behave@ietf.org Subject: Re: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09 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, 21 Jun 2012 07:12:17 -0000 Simon, > > I don't see how DNSSEC protecting PTR query would help in the "trusted > > domains" question. All that host could learn is that PTR query can be > > verified to be owned by badguys.hotspot.example.com, right? >=20 > I see. >=20 > I have two concerns with the trusted domains list. >=20 > My first concern is that it doesn't really add any security. If you come = visit me > to my office, where we run a NAT64, and I really want you to discover our > prefix securely without you having to click through a scary dialog box, I= will > just squat the prefix of someone else who is probably already on the list= (e.g., > nokia.com), and route it to our NAT64 box. I didn't add any security, but > somehow your client thinks this is secure. > I just picked a different prefix, one that is in your client's "secure" s= et. The client must always use network/transport/application layer security to = be secure. But I do know this "problem". I tried to tackle this in the previous I-D ve= rsions by writing that NAT64 FQDN should be served using split DNS and "nok= ia.com"'s authoritative name server should respond to queries for NAT64 FQ= DN coming only from the "correct" access network (e.g. via whitelisted RDNS= S). Hence if my host in your network would ask for NAT64 FQDN, it would not= get positive response. That time people did not agree this is actually a r= eal problem, and hence I ceased to think about solutions.=20 Definitely the host can only trust the Pref64::/n is valid as such, but hos= t cannot trust that it is used in correct network:-)=20 Maybe when host is provisioned with trusted domains it is also provisioned = with list of access networks where the domains are allowed to be used. Henc= e your "SSID" would not be found on the access network list and hence your = service (or attack) would fail. The attacks I can imagine you can launch with this are similar you can caus= e if you can send RAs to host (i.e. redirection, DoS). I'm not sure we can solve this in easy manner - best is to start using end-= to-end IPv6. And I do not agree these problems are caused by heuristic draft, but effect= ively are present in NAT64/DNS64 framework already. Hence I don't see why t= hese issues would be showstoppers for heuristic discovery. See below: > My second concern is that it allows the people who control domains that a= re > on the list to do evil things. Here's an example attack: the owner of nok= ia.com, > which is on the list, turns evil. He goes in any public > NAT64 hotspot and starts a rogue DNS64 server with a Pref64::/n that > belongs to nokia.com. That prefix is routed to a NAT64 that belongs to No= kia, > somewhere in the Internet. The prefix will be "securely discovered" becau= se > all the appropriate DNS records are present and signed, the NAT64 works, = and > nokia.com is on the list, yet Nokia would be hijacking traffic. Right, but when compared to today's state the number of possible attackers = actually decreases: only owners who control trusted domains can attack with= "malicious" Pref64::/n. Today anyone who can inject a hostile DNS64 address to a host's RDNSS list = can launch the same hijacking attack. So isn't this draft actually an improvement?-) The beef again here I that the "secure discovery" does not mean the traffic= sent using the securely discovered Pref64::/n goes to the right place, onl= y that the destination address is securely formed. That is similar to DNSSE= C anyway: with DNSSEC you can only be sure the destination address is valid= - DNSSEC does not ensure the packets sent to valid address are delivered w= here they should.=20 > In a nutshell, the proposed secure method of Pref64::/n discovery ensures > that the DNS64 is controlled by an entity that also controls a domain nam= e > that is on a trusted list. That's not what "secure discovery" should be, = IMHO. I > would expect secure discovery to ensure that the DNS64 is controlled by t= he > same entity that controls the network on which the client is. So we agree on this, but do you agree this is a general problem, not heuris= tic-specific problem? I mean even today when I talk to DNS64 in IPv6-only access network, I have = no real means to tell I'm talking to legitimate DNS64. Maybe I can trust th= e DNS64 is legitimate if I learned it via pretty trusted channel, like 3GPP= network L2 signaling. So... host should have means to learn the DNS64 address first via secure me= ans. SEND?-) Best regards, Teemu From teemu.savolainen@nokia.com Thu Jun 21 01:37:55 2012 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 1C50621F852E for ; Thu, 21 Jun 2012 01:37:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 Wg3I+CUPCRgT for ; Thu, 21 Jun 2012 01:37:54 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id D7A7721F8522 for ; Thu, 21 Jun 2012 01:37:53 -0700 (PDT) Received: from vaebh104.NOE.Nokia.com (in-mx.nokia.com [10.160.244.30]) by mgw-da02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q5L8bjpY009394; Thu, 21 Jun 2012 11:37:47 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.58]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 21 Jun 2012 11:37:46 +0300 Received: from 008-AM1MPN1-053.mgdnok.nokia.com ([169.254.3.37]) by 008-AM1MMR1-003.mgdnok.nokia.com ([65.54.30.58]) with mapi id 14.02.0283.004; Thu, 21 Jun 2012 10:37:41 +0200 From: To: Thread-Topic: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09 Thread-Index: AQHNT4kfaxsRm0qAo06JHN2+FgSumA== Date: Thu, 21 Jun 2012 08:37:41 +0000 Message-ID: <916CE6CF87173740BC8A2CE443096962043AF006@008-AM1MPN1-053.mgdnok.nokia.com> References: <9B57C850BB53634CACEC56EF4853FF653B62BDA4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B66483D@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <4FE1DC2C.1010002@viagenie.ca> <916CE6CF87173740BC8A2CE443096962043AEAFE@008-AM1MPN1-053.mgdnok.nokia.com> <4FE219D4.5060002@viagenie.ca> In-Reply-To: <4FE219D4.5060002@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Nokia Internal Use Only;Project=None; x-titus-version: 3.3.8.1 x-headerinfofordlp: None x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7Ili3MCvCLXmrxYjzLlJRY6GRYSEESzssJdyl1KtGXxHbRz0f/N8DTFypsncJtFw5H6dEgLNn6I2DYQI1slWstWQLhts4Ao1Rvb7G9B7pZe+oW16aK60T/IZngo/xmoWZz4wl3U9iTRcWTIqdcQ9m+D6PMygWim2QOfgvTOlhx5yWE5M3n/txRnmqEif0/5bbQ+J8mO2cgxvdGCXg3S53/kMBDEDpT6rEg0W0aLtjGxqfiUPHRHRyqxYxC1TLq7ISAU6PK2jG5Ob6ktz5oQfnmV8= x-originating-ip: [10.163.16.207] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 21 Jun 2012 08:37:46.0499 (UTC) FILETIME=[221C0D30:01CD4F89] X-Nokia-AV: Clean Cc: behave@ietf.org Subject: Re: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09 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, 21 Jun 2012 08:37:55 -0000 Hi Simon > On 2012-06-20 13:31, teemu.savolainen@nokia.com wrote: > > The intent of the prioritization is to attempt avoiding possible > > issues if in future some meaning is encoded into suffix-fields of > > Figure 1 of RFC6052. The host cannot know what to put in suffixes of > > synthetized addresses, hence the host could try to avoid using > > Pref64::/n that has suffix-field. We could say that if there are > > multiple Pref64::/n of same priority available, a host SHOULD use them > > all in local synthesis process e.g. in round-robin manner? Would that > > suffice? > > I think that would be fine if you only define two priority levels: > 1. (highest priority) Prefix without suffix-field. > 2. (lowest priority) Prefix with suffix-field. So how does network-side NAT64 load balancing actually work? Does it work s= o that a single Pref64::/n is used for a host, and different hosts see diff= erent Pref64::/n, or does a single host see multiple Pref64::/n? If both are used in the field, then it would be ok for a node to stick usin= g just one, right? (Picked e.g. pseudo-randomly from the learned Pref64::/n= list)? > On the client side STUN is arguably easier than ICMP because you don't ne= ed > access to raw sockets, it's just really simple UDP. On the server side IC= MP has > issues too because operating systems usually rate limit echo replies. Good points, let's discuss today. > Absolutely. I wouldn't mind if you just removed all references to ICMP wi= thout > replacing them with STUN. My point is that recommending ICMP, even as an > operator hosted service, really isn't a good idea because ICMP is really = bad at > this for a number of operational reasons. The intent was to provide some means for network to provide "standard" conn= ectivity check services, hence leaving all protocols out would not suit tha= t purpose very well. So let's discuss today if we should use STUN instead. = I guess operator hosted STUN could provide additional benefits as well.. Best regards, Teemu From teemu.savolainen@nokia.com Thu Jun 21 02:48:34 2012 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 6F21921F85B1 for ; Thu, 21 Jun 2012 02:48:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 4lblfuWb4Fcq for ; Thu, 21 Jun 2012 02:48:34 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id A3C2C21F8535 for ; Thu, 21 Jun 2012 02:48:32 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q5L9mN5T008603; Thu, 21 Jun 2012 12:48:23 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.61]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 21 Jun 2012 12:48:24 +0300 Received: from 008-AM1MPN1-053.mgdnok.nokia.com ([169.254.3.37]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi id 14.02.0283.004; Thu, 21 Jun 2012 11:48:22 +0200 From: To: , Thread-Topic: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09 Thread-Index: AQHNR+G9CBCjjZ1MSUejEPV+sICjIpb2eW/ggAAeTwCADf4cMA== Date: Thu, 21 Jun 2012 09:48:22 +0000 Message-ID: <916CE6CF87173740BC8A2CE443096962043AF1B0@008-AM1MPN1-053.mgdnok.nokia.com> References: <9B57C850BB53634CACEC56EF4853FF653B62BDA4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <20120611145125.GC11684@mail.yitter.info> <916CE6CF87173740BC8A2CE4430969620439DD7C@008-AM1MPN1-053.mgdnok.nokia.com> <20120612140610.GA16548@mail.yitter.info> In-Reply-To: <20120612140610.GA16548@mail.yitter.info> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.163.16.207] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 21 Jun 2012 09:48:24.0934 (UTC) FILETIME=[0069E860:01CD4F93] X-Nokia-AV: Clean Subject: Re: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09 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, 21 Jun 2012 09:48:34 -0000 > Right. It's ok with me if it just says, "This does not change the pictur= e for > 'coffee shop' ad hoc network use," or something like that too. The point= is > really just that DNS64/NAT64 is never going to be an option wherever you > have a lot of people who don't trust the network trying to use it, and al= so > trying to use DNSSEC. If DANE/TLSA takes off, this will be a problem. --- The security considerations follow closely those of RFC 6147 [RFC6147]. The= possible attacks are very similar in the case where attacker controls DNS6= 4 server and returns tampered IPv6 addresses to a node and in the case wher= e attacker causes the node to use tampered Pref64::/n for local address sy= nthesis. Hence this document does not change the big picture for untrusted = network scenarios. If an attacker mangles with Pref64::/n used by a DNS64 s= erver or a node, the traffic generated by the node will be delivered to an = altered destination. This can result in either a denial-of-service (DoS) at= tack (if the resulting IPv6 addresses are not assigned to any device), a fl= ooding attack (if the resulting IPv6 addresses are assigned to devices that= do not wish to receive the traffic), or an eavesdropping attack (in case t= he altered NSP is routed through the attacker). --- Perhaps? Teemu From simon.perreault@viagenie.ca Thu Jun 21 06:22:26 2012 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 6013421F85FC for ; Thu, 21 Jun 2012 06:22:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-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 9JOM0FtxP-sT for ; Thu, 21 Jun 2012 06:22:25 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 7CAD121F85E4 for ; Thu, 21 Jun 2012 06:22:25 -0700 (PDT) Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c064:1435:1ef2:cef2:725e]) by jazz.viagenie.ca (Postfix) with ESMTPSA id A0AB741581; Thu, 21 Jun 2012 09:22:23 -0400 (EDT) Message-ID: <4FE3200F.8000109@viagenie.ca> Date: Thu, 21 Jun 2012 09:22:23 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1 MIME-Version: 1.0 To: Dan Wing References: <9B57C850BB53634CACEC56EF4853FF653B62BDA4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B66483D@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <4FE1DC2C.1010002@viagenie.ca> <916CE6CF87173740BC8A2CE443096962043AEAFE@008-AM1MPN1-053.mgdnok.nokia.com> <4FE219D4.5060002@viagenie.ca> <023b01cd4f2e$c8294450$587bccf0$@com> In-Reply-To: <023b01cd4f2e$c8294450$587bccf0$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: behave@ietf.org Subject: Re: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09 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, 21 Jun 2012 13:22:26 -0000 On 2012-06-20 17:51, Dan Wing wrote: > I suggest, > > NXDOMAIN and NXRRSET hijacking may result in a false positive. > One method to detect such hijacking is to query a FQDN that is > known to be invalid (and normally return an empty response or > an error response) and see if it returns a valid resource > record. Wfm. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From teemu.savolainen@nokia.com Thu Jun 21 06:28:44 2012 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 7FB6221F8643 for ; Thu, 21 Jun 2012 06:28:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 0bVBGYBm-Z+c for ; Thu, 21 Jun 2012 06:28:44 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id C3D1D21F8569 for ; Thu, 21 Jun 2012 06:28:43 -0700 (PDT) Received: from vaebh102.NOE.Nokia.com (in-mx.nokia.com [10.160.244.23]) by mgw-da02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q5LDS0bU016339; Thu, 21 Jun 2012 16:28:37 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.57]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 21 Jun 2012 16:28:28 +0300 Received: from 008-AM1MPN1-053.mgdnok.nokia.com ([169.254.3.37]) by 008-AM1MMR1-002.mgdnok.nokia.com ([65.54.30.57]) with mapi id 14.02.0283.004; Thu, 21 Jun 2012 15:28:17 +0200 From: To: , Thread-Topic: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09 Thread-Index: AQHNTzVzgKyYFn88QeSiVcin492nCZcEwuoQ Date: Thu, 21 Jun 2012 13:28:17 +0000 Message-ID: <916CE6CF87173740BC8A2CE443096962043AF580@008-AM1MPN1-053.mgdnok.nokia.com> References: <9B57C850BB53634CACEC56EF4853FF653B62BDA4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B66483D@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <4FE250F5.5010505@acm.org> In-Reply-To: <4FE250F5.5010505@acm.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.163.35.18] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 21 Jun 2012 13:28:28.0681 (UTC) FILETIME=[BE75CF90:01CD4FB1] X-Nokia-AV: Clean Cc: behave@ietf.org Subject: Re: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09 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, 21 Jun 2012 13:28:44 -0000 Thank you Marc for your review, responses inline: > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf > Of ext Marc Petit-Huguenin > Sent: 21. kes=E4kuuta 2012 01:39 > To: Dave Thaler > Cc: behave@ietf.org > Subject: Re: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuris= tic- > 09 >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 >=20 > On 06/18/2012 05:00 PM, Dave Thaler wrote: > > So far I've seen 3 reviews: * Andrew Sullivan * Aaron Yi DING * Dave > > Thaler > > > > We need at least 5 reviews on this document. Can we get two more > > volunteers? Maybe Simon and/or Marc P.-H.? Anyone else? > > >=20 > 1. Section 3.2 >=20 > It seems to me that using ICMP connectivity checks cannot be done with th= e > Well-Known Prefix, as it is not possible to register a PTR RR for each do= main > using it. This should be said somewhere as this is a good reason to pref= er a > Network Specific Prefix if connectivity check are to be deployed in the f= uture. Good point, added draft text to Connectivity Check section:"The Pref64::/n = -based connectivity check approach works only with NSP, as it is not possib= le to register A record for each different domain using WKP." > 2. Section 3.3 "...to perform a function similar to ipv4-only.arpa, ..." >=20 > It should be "ipv4only.arpa" Fixed, there were few of these. > Which bring another question: Was the intent to use specifically ipv4- > only. (or ipv4only.), i.e. is the leftmost component fixe= d, > or is the whole domain name provisionable? =20 The idea was to have fixed "ipv4only.arpa" , i.e. no changes to left or rig= ht components. =20 > 3. Appendix A "nat64.example.org IN AAAA..." >=20 > Why is that RR in the example? I cannot find in the normative text how t= his is > used. Besides it seems malformed (IP address is 14 bytes long, and the > "nat64.example.com." at the end of the line should be at the beginning of= the > the next line). =20 The section 3.1.2 section 4 performs AAAA query for NAT64 FQDN. Would the c= orrect configuration be then: nat64.example.com.=20 IN AAAA 2001:db8:0:0:0:0:0:0=20 nat64.example.com.=20 IN A 192.0.2.1 =20 > Nits > =3D=3D=3D=3D >=20 > - - Section 3.1.1, third bullet >=20 > s/MUST HAVE/MUST have/ Fixed > - - Section 3.2 last paragraph >=20 > s/mode/node/ Fixed, thanks. > - - Section 3.3: >=20 > s/. DNS For example/. For example/ Fixed, thanks. Best regards, Teemu From simon.perreault@viagenie.ca Thu Jun 21 06:36:41 2012 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 D0B9121F8669 for ; Thu, 21 Jun 2012 06:36:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-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 0V0lCRkL+fRr for ; Thu, 21 Jun 2012 06:36:41 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id EE3F521F866A for ; Thu, 21 Jun 2012 06:36:40 -0700 (PDT) Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c064:1435:1ef2:cef2:725e]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 66E9C41581; Thu, 21 Jun 2012 09:36:40 -0400 (EDT) Message-ID: <4FE32367.5080207@viagenie.ca> Date: Thu, 21 Jun 2012 09:36:39 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1 MIME-Version: 1.0 To: teemu.savolainen@nokia.com References: <9B57C850BB53634CACEC56EF4853FF653B62BDA4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B66483D@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <4FE1DC2C.1010002@viagenie.ca> <20120620143826.GE41079@mail.yitter.info>, <4FE1ECFD.3070102@viagenie.ca> <916CE6CF87173740BC8A2CE443096962043AEA77@008-AM1MPN1-053.mgdnok.nokia.com> <4FE2152D.7040402@viagenie.ca> <916CE6CF87173740BC8A2CE443096962043AEEBF@008-AM1MPN1-053.mgdnok.nokia.com> In-Reply-To: <916CE6CF87173740BC8A2CE443096962043AEEBF@008-AM1MPN1-053.mgdnok.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: behave@ietf.org Subject: Re: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09 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, 21 Jun 2012 13:36:41 -0000 On 2012-06-21 03:11, teemu.savolainen@nokia.com wrote: >> My first concern is that it doesn't really add any security. If you >> come visit me to my office, where we run a NAT64, and I really want >> you to discover our prefix securely without you having to click >> through a scary dialog box, I will just squat the prefix of someone >> else who is probably already on the list (e.g., nokia.com), and >> route it to our NAT64 box. I didn't add any security, but somehow >> your client thinks this is secure. I just picked a different >> prefix, one that is in your client's "secure" set. > > The client must always use network/transport/application layer > security to be secure. > > But I do know this "problem". I tried to tackle this in the previous > I-D versions by writing that NAT64 FQDN should be served using split > DNS and "nokia.com"'s authoritative name server should respond to > queries for NAT64 FQDN coming only from the "correct" access network > (e.g. via whitelisted RDNSS). Hence if my host in your network would > ask for NAT64 FQDN, it would not get positive response. That time > people did not agree this is actually a real problem, and hence I > ceased to think about solutions. > > Definitely the host can only trust the Pref64::/n is valid as such, > but host cannot trust that it is used in correct network:-) > > Maybe when host is provisioned with trusted domains it is also > provisioned with list of access networks where the domains are > allowed to be used. Hence your "SSID" would not be found on the > access network list and hence your service (or attack) would fail. > > The attacks I can imagine you can launch with this are similar you > can cause if you can send RAs to host (i.e. redirection, DoS). > > I'm not sure we can solve this in easy manner - best is to start > using end-to-end IPv6. > > And I do not agree these problems are caused by heuristic draft, but > effectively are present in NAT64/DNS64 framework already. Hence I > don't see why these issues would be showstoppers for heuristic > discovery. See below: I agree with your assessment, and I also believe heuristic discovery should proceed forward. However, secure discovery might have to be dropped if all it does is provide a false sense of security. >> My second concern is that it allows the people who control domains >> that are on the list to do evil things. Here's an example attack: >> the owner of nokia.com, which is on the list, turns evil. He goes >> in any public NAT64 hotspot and starts a rogue DNS64 server with a >> Pref64::/n that belongs to nokia.com. That prefix is routed to a >> NAT64 that belongs to Nokia, somewhere in the Internet. The prefix >> will be "securely discovered" because all the appropriate DNS >> records are present and signed, the NAT64 works, and nokia.com is >> on the list, yet Nokia would be hijacking traffic. > > Right, but when compared to today's state the number of possible > attackers actually decreases: only owners who control trusted domains > can attack with "malicious" Pref64::/n. > > Today anyone who can inject a hostile DNS64 address to a host's RDNSS > list can launch the same hijacking attack. > > So isn't this draft actually an improvement?-) Very tiny improvement. I still think it would give the user a false sense of security. > The beef again here I that the "secure discovery" does not mean the > traffic sent using the securely discovered Pref64::/n goes to the > right place, only that the destination address is securely formed. I presume "securely formed" means something different to you than it does to me... > That is similar to DNSSEC anyway: with DNSSEC you can only be sure > the destination address is valid - DNSSEC does not ensure the packets > sent to valid address are delivered where they should. With secure discovery you can't even be sure that the destination address is valid! All you can be sure of is that it is an address that belongs to somebody that also owns a domain in your trusted list. That is practically almost useless. >> In a nutshell, the proposed secure method of Pref64::/n discovery >> ensures that the DNS64 is controlled by an entity that also >> controls a domain name that is on a trusted list. That's not what >> "secure discovery" should be, IMHO. I would expect secure discovery >> to ensure that the DNS64 is controlled by the same entity that >> controls the network on which the client is. > > So we agree on this, but do you agree this is a general problem, not > heuristic-specific problem? Unsecure discovery is fine. It is just as unsecure as everything else. But a secure discovery that is not secure at all is just misleading. > I mean even today when I talk to DNS64 in IPv6-only access network, I > have no real means to tell I'm talking to legitimate DNS64. Maybe I > can trust the DNS64 is legitimate if I learned it via pretty trusted > channel, like 3GPP network L2 signaling. > > So... host should have means to learn the DNS64 address first via > secure means. SEND?-) IMHO, secure discovery is not necessary. It would be nice if the DNSSEC method had worked, but I don't think it does. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From simon.perreault@viagenie.ca Thu Jun 21 06:48:24 2012 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 4DFB921F864A for ; Thu, 21 Jun 2012 06:48:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-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 c0OSV9RCSS4B for ; Thu, 21 Jun 2012 06:48:23 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 7F9E021F8649 for ; Thu, 21 Jun 2012 06:48:23 -0700 (PDT) Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c064:1435:1ef2:cef2:725e]) by jazz.viagenie.ca (Postfix) with ESMTPSA id E5F46415E5; Thu, 21 Jun 2012 09:48:22 -0400 (EDT) Message-ID: <4FE32626.8000004@viagenie.ca> Date: Thu, 21 Jun 2012 09:48:22 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1 MIME-Version: 1.0 To: teemu.savolainen@nokia.com References: <9B57C850BB53634CACEC56EF4853FF653B62BDA4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B66483D@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <4FE1DC2C.1010002@viagenie.ca> <916CE6CF87173740BC8A2CE443096962043AEAFE@008-AM1MPN1-053.mgdnok.nokia.com> <4FE219D4.5060002@viagenie.ca> <916CE6CF87173740BC8A2CE443096962043AF006@008-AM1MPN1-053.mgdnok.nokia.com> In-Reply-To: <916CE6CF87173740BC8A2CE443096962043AF006@008-AM1MPN1-053.mgdnok.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: behave@ietf.org Subject: Re: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09 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, 21 Jun 2012 13:48:24 -0000 On 2012-06-21 04:37, teemu.savolainen@nokia.com wrote: >> I think that would be fine if you only define two priority levels: >> 1. (highest priority) Prefix without suffix-field. 2. (lowest >> priority) Prefix with suffix-field. > > So how does network-side NAT64 load balancing actually work? Does it > work so that a single Pref64::/n is used for a host, and different > hosts see different Pref64::/n, or does a single host see multiple > Pref64::/n? Both possibilities are possible, and have pros and cons. It's just like regular DNS-based load balancing. Cameron Byrne would have more information, he looked into the problem pretty deeply. See also these: http://tools.ietf.org/html/draft-li-behave-dns64-load-balancing-02 http://tools.ietf.org/html/draft-zhang-behave-nat64-load-balancing-03 http://tools.ietf.org/html/draft-chen-v6ops-nat64-experience-01 > If both are used in the field, then it would be ok for a node to > stick using just one, right? (Picked e.g. pseudo-randomly from the > learned Pref64::/n list)? No, because it would result in different traffic pattern from what would happen with normal DNS64. With normal DNS64, the node would pick one at random for each connection (ideally) or for each domain name (common because many apps have broken caching). If you just pick one at random for all your connections, you have a completely different traffic pattern, and that might cause problems because of unforeseen operational reasons. You want the traffic pattern to remain close to regular DNS64. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From yding@cs.helsinki.fi Thu Jun 21 08:09:40 2012 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 43E3021F8720 for ; Thu, 21 Jun 2012 08:09:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 nmkkfOO+2xZT for ; Thu, 21 Jun 2012 08:09:39 -0700 (PDT) Received: from mail.cs.helsinki.fi (courier.cs.helsinki.fi [128.214.9.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14A7F21F871E for ; Thu, 21 Jun 2012 08:09:37 -0700 (PDT) Received: from [128.214.9.154] (wel-33.cs.helsinki.fi [128.214.9.154]) (AUTH: PLAIN yding, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Thu, 21 Jun 2012 18:09:35 +0300 id 0008C6A2.4FE3392F.00002E55 Message-ID: <4FE3392E.40803@cs.helsinki.fi> Date: Thu, 21 Jun 2012 18:09:34 +0300 From: Aaron Yi DING Organization: Helsinki University User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Simon Perreault References: <9B57C850BB53634CACEC56EF4853FF653B62BDA4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B66483D@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <4FE1DC2C.1010002@viagenie.ca> <20120620143826.GE41079@mail.yitter.info>, <4FE1ECFD.3070102@viagenie.ca> <916CE6CF87173740BC8A2CE443096962043AEA77@008-AM1MPN1-053.mgdnok.nokia.com> <4FE2152D.7040402@viagenie.ca> <916CE6CF87173740BC8A2CE443096962043AEEBF@008-AM1MPN1-053.mgdnok.nokia.com> <4FE32367.5080207@viagenie.ca> In-Reply-To: <4FE32367.5080207@viagenie.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: behave@ietf.org Subject: Re: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09 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, 21 Jun 2012 15:09:40 -0000 Hello, Concerning the security discussion so far, it's good to keep such section rather than dropping it IMHO, since the main intention is to improve the security level of heuristic discovery. The sense of false security as Simon cited is a pretty tricky topic, especially when we assume there will always be certain kind of imaginary attacks out there (though what Simon mentioned are indeed valid) Such false security statement is just like the Carl Sagan's Dragon http://www.users.qwest.net/~jcosta3/article_dragon.htm To believe the approach as "insecure" is essentially a statement that can hardly be proven wrong, period. Please kindly check Carl's dragon, If hard to comprehend. The security section needs improvement, yes, but not dropped. Thanks, Aaron On 21/06/12 16:36, Simon Perreault wrote: > On 2012-06-21 03:11, teemu.savolainen@nokia.com wrote: >>> My first concern is that it doesn't really add any security. If you >>> come visit me to my office, where we run a NAT64, and I really want >>> you to discover our prefix securely without you having to click >>> through a scary dialog box, I will just squat the prefix of someone >>> else who is probably already on the list (e.g., nokia.com), and >>> route it to our NAT64 box. I didn't add any security, but somehow >>> your client thinks this is secure. I just picked a different >>> prefix, one that is in your client's "secure" set. >> >> The client must always use network/transport/application layer >> security to be secure. >> >> But I do know this "problem". I tried to tackle this in the previous >> I-D versions by writing that NAT64 FQDN should be served using split >> DNS and "nokia.com"'s authoritative name server should respond to >> queries for NAT64 FQDN coming only from the "correct" access network >> (e.g. via whitelisted RDNSS). Hence if my host in your network would >> ask for NAT64 FQDN, it would not get positive response. That time >> people did not agree this is actually a real problem, and hence I >> ceased to think about solutions. >> >> Definitely the host can only trust the Pref64::/n is valid as such, >> but host cannot trust that it is used in correct network:-) >> >> Maybe when host is provisioned with trusted domains it is also >> provisioned with list of access networks where the domains are >> allowed to be used. Hence your "SSID" would not be found on the >> access network list and hence your service (or attack) would fail. >> >> The attacks I can imagine you can launch with this are similar you >> can cause if you can send RAs to host (i.e. redirection, DoS). >> >> I'm not sure we can solve this in easy manner - best is to start >> using end-to-end IPv6. >> >> And I do not agree these problems are caused by heuristic draft, but >> effectively are present in NAT64/DNS64 framework already. Hence I >> don't see why these issues would be showstoppers for heuristic >> discovery. See below: > > I agree with your assessment, and I also believe heuristic discovery > should proceed forward. However, secure discovery might have to be > dropped if all it does is provide a false sense of security. > >>> My second concern is that it allows the people who control domains >>> that are on the list to do evil things. Here's an example attack: >>> the owner of nokia.com, which is on the list, turns evil. He goes >>> in any public NAT64 hotspot and starts a rogue DNS64 server with a >>> Pref64::/n that belongs to nokia.com. That prefix is routed to a >>> NAT64 that belongs to Nokia, somewhere in the Internet. The prefix >>> will be "securely discovered" because all the appropriate DNS >>> records are present and signed, the NAT64 works, and nokia.com is >>> on the list, yet Nokia would be hijacking traffic. >> >> Right, but when compared to today's state the number of possible >> attackers actually decreases: only owners who control trusted domains >> can attack with "malicious" Pref64::/n. >> >> Today anyone who can inject a hostile DNS64 address to a host's RDNSS >> list can launch the same hijacking attack. >> >> So isn't this draft actually an improvement?-) > > Very tiny improvement. I still think it would give the user a false > sense of security. > >> The beef again here I that the "secure discovery" does not mean the >> traffic sent using the securely discovered Pref64::/n goes to the >> right place, only that the destination address is securely formed. > > I presume "securely formed" means something different to you than it > does to me... > >> That is similar to DNSSEC anyway: with DNSSEC you can only be sure >> the destination address is valid - DNSSEC does not ensure the packets >> sent to valid address are delivered where they should. > > With secure discovery you can't even be sure that the destination > address is valid! All you can be sure of is that it is an address that > belongs to somebody that also owns a domain in your trusted list. That > is practically almost useless. > >>> In a nutshell, the proposed secure method of Pref64::/n discovery >>> ensures that the DNS64 is controlled by an entity that also >>> controls a domain name that is on a trusted list. That's not what >>> "secure discovery" should be, IMHO. I would expect secure discovery >>> to ensure that the DNS64 is controlled by the same entity that >>> controls the network on which the client is. >> >> So we agree on this, but do you agree this is a general problem, not >> heuristic-specific problem? > > Unsecure discovery is fine. It is just as unsecure as everything else. > > But a secure discovery that is not secure at all is just misleading. > >> I mean even today when I talk to DNS64 in IPv6-only access network, I >> have no real means to tell I'm talking to legitimate DNS64. Maybe I >> can trust the DNS64 is legitimate if I learned it via pretty trusted >> channel, like 3GPP network L2 signaling. >> >> So... host should have means to learn the DNS64 address first via >> secure means. SEND?-) > > IMHO, secure discovery is not necessary. It would be nice if the > DNSSEC method had worked, but I don't think it does. > > Simon From iesg-secretary@ietf.org Thu Jun 21 12:31:40 2012 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 7099911E80CF; Thu, 21 Jun 2012 12:31:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.231 X-Spam-Level: X-Spam-Status: No, score=-102.231 tagged_above=-999 required=5 tests=[AWL=-0.232, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 cdOmeO0Jn5qk; Thu, 21 Jun 2012 12:31:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D298C11E80D1; Thu, 21 Jun 2012 12:31:39 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.21 Message-ID: <20120621193139.30370.11453.idtracker@ietfa.amsl.com> Date: Thu, 21 Jun 2012 12:31:39 -0700 Cc: behave WG Subject: [BEHAVE] WG Action: Rechartered Behavior Engineering for Hindrance Avoidance (behave) 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, 21 Jun 2012 19:31:40 -0000 The Behavior Engineering for Hindrance Avoidance (behave) working group in the Transport Area of the IETF has been rechartered. For additional information please contact the Area Directors or the WG Chairs. Behavior Engineering for Hindrance Avoidance (behave) ------------------------------------------------ Current Status: Active Working Group Chairs: Dan Wing Dave Thaler Assigned Area Director: Wesley Eddy Mailing list Address: behave@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/behave Archive: http://www.ietf.org/mail-archive/web/behave Charter of Working Group: The working group creates documents to enable IPv4/IPv4 and IPv6/IPv4 NATs to function in as deterministic a fashion as possible. To support deployments where communicating hosts require using different address families (IPv4 or IPv6), address family translation is needed to establish communication. BEHAVE will coordinate on this topic with the V6ops WG on requirements and operational considerations. "An IPv4 network" or "an IPv6 network" in the descriptions below refer to a network with a clearly identifiable administrative domain (e.g., an enterprise campus network, a mobile operator's cellular network, a residential subscriber network, etc.). It will also be that network that deploys the necessary equipment for translation. BEHAVE will finish four scenarios: (1) An IPv6 network to IPv4 Internet, (2) an IPv6 Internet to an IPv4 network, (3) an IPv6 network to an IPv4 network, and (4) an IPv4 network to an IPv6 network. Specifically, BEHAVE will update the NAT MIB (RFC 4008) to be consistent with the management aspects of its IPv6/IPv4 NAT solutions, and specify IPFIX information elements to meet logging requirements, reusing existing elements, if possible. In addition, when a NAT (such as a NAT64 in the "An IPv6 network to IPv4 Internet" scenario) serves multiple subscribers, inter-subscriber fairness issues arise. As such, BEHAVE will complete its work on Carrier Grade NAT requirements for such scenarios, and update the NAT MIB as needed to meet such requirements. BEHAVE will not, however, standardize IPv4-specific behavioral mechanisms. The following scenarios remain in scope for discussion, but will not be solved by BEHAVE: * An IPv4 network to IPv6 Internet, i.e. perform translation between IPv4 and IPv6 for packets in uni- or bi-directional flows that are initiated from an IPv4 host towards an IPv6 host. The translator function is intended to service a specific IPv4 network using either public or private IPv4 address space. * IPv4 Internet to an IPv6 network, i.e. perform translation between IPv4 and IPv6 for packets in uni- or bi-directional flows that are initiated from an IPv4 host towards an IPv6 host. The translator function is intended to service a specific IPv6 network where selected IPv6 hosts and services are to be reachable. This group will also provide reviews of any work by the MBoneD WG on multicast translation, including control traffic (IGMP and MLD), Single Source Multicast (SSM) and Any Source Multicast (ASM). If the WG deems it necessary, BEHAVE will revise RFCs previously published by BEHAVE. Milestones: Done - Submit BCP that defines unicast UDP behavioral requirements for NATs to IESG Done - Submit a BCP that defines TCP behavioral requireents for NATs to IESG Done - Submit a BCP that defines ICMP behavioral requirements for NATs to IESG Done - Submit informational that discusses current NAT traversal techniques used by applications Done - Submit BCP that defines multicast UDP Done - Submit revision of RFC 3489 to IESG behavioral requirements for NATs to IESG Done - Submit informational document for rfc3489bis test vectors Done - Submit experimental document that describes how an application can determine the type of NAT it is behind Done - Submit BCP document for DCCP NAT behavior Done - Determine relative prioritization of the four translation cases. Documented in IETF74 minutes. Done - Determine what solutions(s) and components are needed to solve each of the four cases. Create new milestones for the solution(s) and the components. Documented in IETF74 minutes. Done - Submit to IESG: relaying of a TCP bytestream (std) Done - Submit to IESG: relay protocol (std) Done - Submit to IESG: TURN-URI document (std) Done - Submit to IESG: IPv6 relay protocol (std) Done - Submit to IESG: framework for IPv6/IPv4 translation (info) Done - Submit to IESG: stateless IPv6/IPv4 translation (std) Done - Submit to IESG: stateful IPv6/IPv4 translation (std) Done - Submit to IESG: DNS rewriting for IPv6/IPv4 translation (std) Done - Submit to IESG: IPv6 prefix for IPv6/IPv4 translator (std) Done - Determine need and scope of multicast 6/4 translation Done - Submit to IESG: FTP ALG for IPv6/IPv4 translation (std) Done - Submit to IESG: Analysis of NAT-PT considerations with IPv6/IPv4 translation (info) Done - Submit to IESG: host-based NAT46 translation for IPv4-only applications to access IPv6-only servers (std) Jul 2012 - Submit to IESG: large scale NAT requirements (BCP) Jul 2012 - Submit to IESG: avoiding NAT64 with dual-stack host for local networks (std) Nov 2012 - Submit to IESG: updates to NAT MIB for NAT64 (std) Nov 2012 - Submit to IESG: updates to NAT MIB for CGNs (std) Nov 2012 - Submit to IESG: IPFIX information elements (std) From petithug@acm.org Sun Jun 24 12:21:20 2012 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 A569921F8659 for ; Sun, 24 Jun 2012 12:21:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.023, 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 NqWYGfcfUze8 for ; Sun, 24 Jun 2012 12:21:19 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id C722221F8633 for ; Sun, 24 Jun 2012 12:21:19 -0700 (PDT) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 33C612045A for ; Sun, 24 Jun 2012 19:21:17 +0000 (UTC) Message-ID: <4FE768AB.3060303@acm.org> Date: Sun, 24 Jun 2012 12:21:15 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.4) Gecko/20120510 Icedove/10.0.4 MIME-Version: 1.0 To: Behave WG X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [BEHAVE] In some cases Java does not work with DNS64 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: Sun, 24 Jun 2012 19:21:20 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I discovered a problem with DNS64 when working on an implementation of draft-ietf-behave-nat64-discovery-heuristic for a review. In most cases, Java delegates the DNS resolution to getaddrinfo(3), and in this case, everything works just fine. But in some cases a different resolver needs to be used, mostly when the Java developer wants to be able to provision the nameserver(s) to use for the resolution. Switching the resolver is simple and can be done on *any* Java application by adding the following option on the java command line: - -Dsun.net.spi.nameservice.provider.1=dns,sun The problem with this resolver is that it will send an ANY request instead of two separate A and AAAA requests, and as RFC 6147 does not say anything about ANY requests, the AAAA RR are not synthesized. This problem has been tested with Java 1.6 (Sun and OpenJDK), 1.7 and the current 1.8 (I did not check Android yet). I am a Java developer, so obviously I consider this to be a huge problem, especially because many existing Java applications will not work as expected as soon the command line options are modified. What is the correct way to fix RFC 6147 and the DNS64 implementations out there? Thanks. - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJP52ilAAoJECnERZXWan7E6eQQAK7thiirVIbjh+ztQjsdHV4l 7x6McnqSPuA8O6KCFkdFCg6lixVE6iy+m9u8xKBHghvEZSqiCu3StPozFkhMf+i7 G8rir2dAJFqsUf6NFsopl2aYWKX17R+3cuVI2mG933+I/dJyxnL2GY+vgKoSAHpH pWKmJk2h8EcttwfzlmgwmSzRh6Q7UJILzglQHtmQIuQcvxTcK9n3Ry7uMgDp9eZm QatAYg629HACgreaiHJQqRVeqlTdireqOLktuiWgxjne4OEKqkB3pOQ4wbBfaLNw Xx9LZt7km662YQJJgvNAP53vcIXi1DEV+3ehb02jg+1zb5j4+daxnrYDXjeWDI4v HjwRQk2O3oyawzH7l9MEnxGwgBCQKK42vwR7s9bVQi6ndqTKt0jh0yUK2YihUqg5 FrpwuUVuSXM+tC/AIFY3qx0lP7ClnY6s4SL+MeXrzXB4e/y5bWzVf7FI8CeNDCOc OLMuGP4zgIF6fzbJnm3u64bRbLw/8intDgeDcto3VpUpXQaWOQCLmXaigLr5tSAn 5mDP6xfhro7CuDbnG7Z45Kkg9WbUn7tziYNdduh9QFJl0FJHl7jf4g8RAqT0GpuY vwjTk1UpX0iETaOkRwKGwG/C2d0GYxmThgSIHoWh+7KRalg/IDA1/4DPUaK/a+nn aU64jb6ruIInFZhcTTBL =yNiU -----END PGP SIGNATURE----- From ajs@anvilwalrusden.com Sun Jun 24 15:57:08 2012 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 4D46E21F852D for ; Sun, 24 Jun 2012 15:57:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 QQToR0Abtmdz for ; Sun, 24 Jun 2012 15:57:07 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id BD7B821F852C for ; Sun, 24 Jun 2012 15:57:07 -0700 (PDT) Received: from mail.yitter.info (unknown [109.81.193.55]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 68A8D1ECB41C for ; Sun, 24 Jun 2012 22:57:06 +0000 (UTC) Date: Sun, 24 Jun 2012 18:57:02 -0400 From: Andrew Sullivan To: behave@ietf.org Message-ID: <20120624225702.GB45427@mail.yitter.info> References: <4FE768AB.3060303@acm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4FE768AB.3060303@acm.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [BEHAVE] In some cases Java does not work with DNS64 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: Sun, 24 Jun 2012 22:57:08 -0000 On Sun, Jun 24, 2012 at 12:21:15PM -0700, Marc Petit-Huguenin wrote: > The problem with this resolver is that it will send an ANY request instead of > two separate A and AAAA requests, and as RFC 6147 does not say anything about > ANY requests, the AAAA RR are not synthesized. What Java is doing in that case has a broken assumption. Suppose you have two end nodes on the network sharing a single caching, full-service resolver. Suppose also that example.com exists, and contains at least an A and AAAA record at that owner name. The first end node ("1") sends only A queries. The second end node ("2") is using this Java strategy of sending queries for ANY. If 1 queries first for example.com A?, then the cache gets a copy of the A record for example.com. Now, when 2 queries for example.com ANY?, what do you suppose happens? Many people seem to think that an ANY query is relayed upstream. But that's not what is required by the RFCs. In fact, at least usualy, the intermediate cache answers _with the records it has_, which means that 2 gets an answer with only A records in it. The response from a cache when the TYPE is 255 is dependent on what is in the cache when the query is received (even more than usual with caches). > I am a Java developer, so obviously I consider this to be a huge problem, > especially because many existing Java applications will not work as expected > as soon the command line options are modified. What is the correct way to fix > RFC 6147 and the DNS64 implementations out there? Fix Java. It's what's broken. I agree, however, that a revision of DNS64 (I have apparently committed to working one up; I suppose I'm running out of calendar in which to do it) needs to point out this sharp, pointy issue, but it can't fix it. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From marka@isc.org Sun Jun 24 16:31:21 2012 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 2711421F85F6 for ; Sun, 24 Jun 2012 16:31:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.325 X-Spam-Level: X-Spam-Status: No, score=-2.325 tagged_above=-999 required=5 tests=[AWL=0.274, 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 Hi25GWCX-b5H for ; Sun, 24 Jun 2012 16:31:20 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 2141221F85D2 for ; Sun, 24 Jun 2012 16:31:20 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id E7C805F99C5; Sun, 24 Jun 2012 23:31:03 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:49db:b78e:a3fc:c3b4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id E629D216C33; Sun, 24 Jun 2012 23:31:01 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id A2B5121E3E76; Mon, 25 Jun 2012 09:31:08 +1000 (EST) To: Marc Petit-Huguenin From: Mark Andrews References: <4FE768AB.3060303@acm.org> In-reply-to: Your message of "Sun, 24 Jun 2012 12:21:15 MST." <4FE768AB.3060303@acm.org> Date: Mon, 25 Jun 2012 09:31:08 +1000 Message-Id: <20120624233108.A2B5121E3E76@drugs.dv.isc.org> Cc: Behave WG Subject: Re: [BEHAVE] In some cases Java does not work with DNS64 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: Sun, 24 Jun 2012 23:31:21 -0000 In message <4FE768AB.3060303@acm.org>, Marc Petit-Huguenin writes: > > I discovered a problem with DNS64 when working on an implementation of > draft-ietf-behave-nat64-discovery-heuristic for a review. > > In most cases, Java delegates the DNS resolution to getaddrinfo(3), and in > this case, everything works just fine. But in some cases a different resolve > r > needs to be used, mostly when the Java developer wants to be able to provisio > n > the nameserver(s) to use for the resolution. Switching the resolver is simpl > e > and can be done on *any* Java application by adding the following option on > the java command line: > > - -Dsun.net.spi.nameservice.provider.1=dns,sun > > The problem with this resolver is that it will send an ANY request instead of > two separate A and AAAA requests, and as RFC 6147 does not say anything about > ANY requests, the AAAA RR are not synthesized. This problem has been tested > with Java 1.6 (Sun and OpenJDK), 1.7 and the current 1.8 (I did not check > Android yet). So? ANY requests are NOT guarenteed to return ALL records, just all *available* records (RFC 1034). This is why "ANY" is used to describe "*" despite the official alternate name for "*" being "ALL". If there are no AAAA records in the ANY response the application should make a seperate AAAA query. If this is not happening then the application is broken. This is basic DNS. Now there are AAAA records that are excluded and the ANY response from a DNS64 server could filter AAAA RRsets that contain only these records but I doubt that this is your concern. > I am a Java developer, so obviously I consider this to be a huge problem, > especially because many existing Java applications will not work as expected > as soon the command line options are modified. What is the correct way to fi > x RFC 6147 and the DNS64 implementations out there? > > Thanks. > > - -- > Marc Petit-Huguenin > Email: marc@petit-huguenin.org > Blog: http://blog.marc.petit-huguenin.org > Profile: http://www.linkedin.com/in/petithug > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.12 (GNU/Linux) > > iQIcBAEBCAAGBQJP52ilAAoJECnERZXWan7E6eQQAK7thiirVIbjh+ztQjsdHV4l > 7x6McnqSPuA8O6KCFkdFCg6lixVE6iy+m9u8xKBHghvEZSqiCu3StPozFkhMf+i7 > G8rir2dAJFqsUf6NFsopl2aYWKX17R+3cuVI2mG933+I/dJyxnL2GY+vgKoSAHpH > pWKmJk2h8EcttwfzlmgwmSzRh6Q7UJILzglQHtmQIuQcvxTcK9n3Ry7uMgDp9eZm > QatAYg629HACgreaiHJQqRVeqlTdireqOLktuiWgxjne4OEKqkB3pOQ4wbBfaLNw > Xx9LZt7km662YQJJgvNAP53vcIXi1DEV+3ehb02jg+1zb5j4+daxnrYDXjeWDI4v > HjwRQk2O3oyawzH7l9MEnxGwgBCQKK42vwR7s9bVQi6ndqTKt0jh0yUK2YihUqg5 > FrpwuUVuSXM+tC/AIFY3qx0lP7ClnY6s4SL+MeXrzXB4e/y5bWzVf7FI8CeNDCOc > OLMuGP4zgIF6fzbJnm3u64bRbLw/8intDgeDcto3VpUpXQaWOQCLmXaigLr5tSAn > 5mDP6xfhro7CuDbnG7Z45Kkg9WbUn7tziYNdduh9QFJl0FJHl7jf4g8RAqT0GpuY > vwjTk1UpX0iETaOkRwKGwG/C2d0GYxmThgSIHoWh+7KRalg/IDA1/4DPUaK/a+nn > aU64jb6ruIInFZhcTTBL > =yNiU > -----END PGP SIGNATURE----- > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From petithug@acm.org Sun Jun 24 16:34:26 2012 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 8442221F86D1 for ; Sun, 24 Jun 2012 16:34:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.019, 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 mPa41WYKZtk0 for ; Sun, 24 Jun 2012 16:34:25 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 6F3F621F86D0 for ; Sun, 24 Jun 2012 16:34:25 -0700 (PDT) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id D02312045A; Sun, 24 Jun 2012 23:34:21 +0000 (UTC) Message-ID: <4FE7A3FB.4080109@acm.org> Date: Sun, 24 Jun 2012 16:34:19 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.4) Gecko/20120510 Icedove/10.0.4 MIME-Version: 1.0 To: Andrew Sullivan References: <4FE768AB.3060303@acm.org> <20120624225702.GB45427@mail.yitter.info> In-Reply-To: <20120624225702.GB45427@mail.yitter.info> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: behave@ietf.org Subject: Re: [BEHAVE] In some cases Java does not work with DNS64 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: Sun, 24 Jun 2012 23:34:26 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 06/24/2012 03:57 PM, Andrew Sullivan wrote: > On Sun, Jun 24, 2012 at 12:21:15PM -0700, Marc Petit-Huguenin wrote: > >> The problem with this resolver is that it will send an ANY request >> instead of two separate A and AAAA requests, and as RFC 6147 does not say >> anything about ANY requests, the AAAA RR are not synthesized. > > What Java is doing in that case has a broken assumption. > > Suppose you have two end nodes on the network sharing a single caching, > full-service resolver. Suppose also that example.com exists, and contains > at least an A and AAAA record at that owner name. > > The first end node ("1") sends only A queries. > > The second end node ("2") is using this Java strategy of sending queries > for ANY. > > If 1 queries first for example.com A?, then the cache gets a copy of the A > record for example.com. > > Now, when 2 queries for example.com ANY?, what do you suppose happens? Many > people seem to think that an ANY query is relayed upstream. But that's not > what is required by the RFCs. In fact, at least usualy, the intermediate > cache answers _with the records it has_, which means that 2 gets an answer > with only A records in it. The response from a cache when the TYPE is 255 > is dependent on what is in the cache when the query is received (even more > than usual with caches). > >> I am a Java developer, so obviously I consider this to be a huge >> problem, especially because many existing Java applications will not work >> as expected as soon the command line options are modified. What is the >> correct way to fix RFC 6147 and the DNS64 implementations out there? > > Fix Java. It's what's broken. OK, it make sense, the Java resolver implementers thought that ANY meant ALL. I will fill a bug, and we'll see what happen. > I agree, however, that a revision of DNS64 (I have apparently committed to > working one up; I suppose I'm running out of calendar in which to do it) > needs to point out this sharp, pointy issue, but it can't fix it. OTOH, what is the downside of synthesizing the AAAA when only the A RR are returned from the cache for an ANY? Sure it would have been better to use the native AAAA than NAT64, but isn't that better than no connectivity at all for a pure IPv6 client? - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJP56P5AAoJECnERZXWan7ErDsP/26y2vowbv2geSFfY5pxbWfv 7y94EzFLVEFza3uR0wW3AtJWTbbURMQEgzJhMkisr76bunGVKBoJt8pw285Q6Yh0 EYyLY1k0qxoAX20uCOdZCWFR2+WwAcBfIK8jlrjeuU1uQxVkPYCne8VzggrKRozs 0FIiSUWUasHypodmlL2FDJnJKbQtR00G09bmQoLbS3CjZLcpVTT7ZYhyBn+4FV3U 1vTefFPeI2k7RHb7O/+6/gZjI0CueA8uz8Cq+R0TOsvJf00TLXdl6ioS8ob/6+vl PI7CHWG/QPoV8DS8bU6NkdpuiPig6CizwcWDKeb7KpEXPt4gulUSA5kGwKMCTkXx AbzxSM1ejH0BTF9aNMIGhaziXa7OCAqYdd8WtJFMnRUkBuM0FTzmC5gUgwlJQG1d gh45oYFpXKFNWL1XggpBePK6CANk/NI45o861js7NuUFr2btptV6eU0wnUTifhV9 NdVFo2HIUQUzS/zTOU25QE/kUu2I90r6CtV+rm1mh87XHruKy5/JMnc3NKillW1s sm7sRTfblhy5LO+F/Skew7XnpMa1KyzrMPvlNu8FgPhLNV+VUCiGLW7lXB5S0yew Oa0PV+t5gSt5lCYhezTmh/B0pINRvBV/+ALngaijG80crO/EabV6dx4hLV5vJM29 4pMURn0eAsRvx+1FVrC2 =mVxT -----END PGP SIGNATURE----- From marka@isc.org Sun Jun 24 16:49:57 2012 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 F34F421F8659 for ; Sun, 24 Jun 2012 16:49:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.38 X-Spam-Level: X-Spam-Status: No, score=-2.38 tagged_above=-999 required=5 tests=[AWL=0.219, 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 jdHRsaYB3UN5 for ; Sun, 24 Jun 2012 16:49:56 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 7F08221F861C for ; Sun, 24 Jun 2012 16:49:56 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS id 9182EC9423; Sun, 24 Jun 2012 23:49:47 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:49db:b78e:a3fc:c3b4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id DC0B2216C33; Sun, 24 Jun 2012 23:49:44 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 177DC21E3F6F; Mon, 25 Jun 2012 09:49:52 +1000 (EST) To: Andrew Sullivan From: Mark Andrews In-reply-to: Your message of "Sun, 24 Jun 2012 18:57:02 -0400." <20120624225702.GB45427@mail.yitter.info> Date: Mon, 25 Jun 2012 09:49:52 +1000 Message-Id: <20120624234952.177DC21E3F6F@drugs.dv.isc.org> Cc: behave@ietf.org Subject: [BEHAVE] CD overloading in DNS64 considered bad 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: Sun, 24 Jun 2012 23:49:57 -0000 I can't write a DNS64 + DNSSEC application / server that works due to the overloading of CD. DNSSEC has CD=1 meaning don't validate. DNS64 has CD=1 meaning don't synthesis. If I have a validating DNS64 recursive server with a bad clock / out of date trust anchors. I can't get a synthesised response from this server. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From marka@isc.org Sun Jun 24 17:34:56 2012 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 DD6D021F86FA for ; Sun, 24 Jun 2012 17:34:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.416 X-Spam-Level: X-Spam-Status: No, score=-2.416 tagged_above=-999 required=5 tests=[AWL=0.183, 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 w6FTotKDy7IS for ; Sun, 24 Jun 2012 17:34:52 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 4EF0521F86A3 for ; Sun, 24 Jun 2012 17:34:52 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS id DAB94C96C0; Mon, 25 Jun 2012 00:34:41 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:49db:b78e:a3fc:c3b4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 2E312216C36; Mon, 25 Jun 2012 00:34:39 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 966D521E410A; Mon, 25 Jun 2012 10:34:45 +1000 (EST) To: Marc Petit-Huguenin From: Mark Andrews References: <4FE768AB.3060303@acm.org> <20120624225702.GB45427@mail.yitter.info> <4FE7A3FB.4080109@acm.org> In-reply-to: Your message of "Sun, 24 Jun 2012 16:34:19 MST." <4FE7A3FB.4080109@acm.org> Date: Mon, 25 Jun 2012 10:34:45 +1000 Message-Id: <20120625003445.966D521E410A@drugs.dv.isc.org> Cc: behave@ietf.org, Andrew Sullivan Subject: Re: [BEHAVE] In some cases Java does not work with DNS64 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, 25 Jun 2012 00:34:57 -0000 In message <4FE7A3FB.4080109@acm.org>, Marc Petit-Huguenin writes: > OTOH, what is the downside of synthesizing the AAAA when only the A RR are > returned from the cache for an ANY? Sure it would have been better to use th > e > native AAAA than NAT64, but isn't that better than no connectivity at all for > a pure IPv6 client? If you are trying to match AAAA records to IP6.ARPA PTR records then generating DNS64 records in the ANY response when there *are* AAAA records will prevent the client making the subsequent AAAA query it should causing the match to fail when it would otherwise succeed. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From teemu.savolainen@nokia.com Sun Jun 24 23:03:13 2012 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 0E7A421F8507 for ; Sun, 24 Jun 2012 23:03:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 oU9DAtcbxRT1 for ; Sun, 24 Jun 2012 23:03:08 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 32CFA21F8540 for ; Sun, 24 Jun 2012 23:03:07 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (in-mx.nokia.com [10.160.244.32]) by mgw-da01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q5P60a5A020681; Mon, 25 Jun 2012 09:01:00 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.21]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 25 Jun 2012 09:00:39 +0300 Received: from 008-AM1MPN1-052.mgdnok.nokia.com ([169.254.2.174]) by 008-AM1MMR1-012.mgdnok.nokia.com ([65.54.30.21]) with mapi id 14.02.0283.004; Mon, 25 Jun 2012 08:00:32 +0200 From: To: , Thread-Topic: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09 Thread-Index: AQHNT30ldLiJvmyt7UWhmN4ulcOpf5cE4MrYgAWqxFA= Date: Mon, 25 Jun 2012 06:00:31 +0000 Message-ID: <916CE6CF87173740BC8A2CE443096962043B7A20@008-AM1MPN1-052.mgdnok.nokia.com> References: <9B57C850BB53634CACEC56EF4853FF653B62BDA4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B66483D@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <4FE1DC2C.1010002@viagenie.ca> <20120620143826.GE41079@mail.yitter.info>, <4FE1ECFD.3070102@viagenie.ca> <916CE6CF87173740BC8A2CE443096962043AEA77@008-AM1MPN1-053.mgdnok.nokia.com> <4FE2152D.7040402@viagenie.ca> <916CE6CF87173740BC8A2CE443096962043AEEBF@008-AM1MPN1-053.mgdnok.nokia.com> <4FE32367.5080207@viagenie.ca> <4FE3392E.40803@cs.helsinki.fi> In-Reply-To: <4FE3392E.40803@cs.helsinki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.163.17.111] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 25 Jun 2012 06:00:39.0218 (UTC) FILETIME=[D8AA2120:01CD5297] X-Nokia-AV: Clean Cc: behave@ietf.org Subject: Re: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09 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, 25 Jun 2012 06:03:13 -0000 Hi Aaron, Simon, We discussed this a bit in the interim call, and I'm updating the draft to = change the language from "Secure Learning of Pref64::/n" to "Validation of = Discovered Pref64::/n" and add statements that all that this validation doe= s is to verify the Pref64::/n is indeed one that ought to be used with a do= main. Best regards, Teemu > -----Original Message----- > From: ext Aaron Yi DING [mailto:yding@cs.helsinki.fi] > Sent: 21. kes=E4kuuta 2012 18:10 > To: Simon Perreault > Cc: Savolainen Teemu (Nokia-NRC/Tampere); behave@ietf.org > Subject: Re: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuris= tic- > 09 >=20 > Hello, >=20 > Concerning the security discussion so far, it's good to keep such section= rather > than dropping it IMHO, since the main intention is to improve the securit= y > level of heuristic discovery. >=20 > The sense of false security as Simon cited is a pretty tricky topic, espe= cially > when we assume there will always be certain kind of imaginary attacks out > there (though what Simon mentioned are indeed valid) >=20 > Such false security statement is just like the Carl Sagan's Dragon > http://www.users.qwest.net/~jcosta3/article_dragon.htm >=20 > To believe the approach as "insecure" is essentially a statement that can > hardly be proven wrong, period. > Please kindly check Carl's dragon, If hard to comprehend. >=20 > The security section needs improvement, yes, but not dropped. >=20 > Thanks, > Aaron >=20 >=20 >=20 > On 21/06/12 16:36, Simon Perreault wrote: > > On 2012-06-21 03:11, teemu.savolainen@nokia.com wrote: > >>> My first concern is that it doesn't really add any security. If you > >>> come visit me to my office, where we run a NAT64, and I really want > >>> you to discover our prefix securely without you having to click > >>> through a scary dialog box, I will just squat the prefix of someone > >>> else who is probably already on the list (e.g., nokia.com), and > >>> route it to our NAT64 box. I didn't add any security, but somehow > >>> your client thinks this is secure. I just picked a different prefix, > >>> one that is in your client's "secure" set. > >> > >> The client must always use network/transport/application layer > >> security to be secure. > >> > >> But I do know this "problem". I tried to tackle this in the previous > >> I-D versions by writing that NAT64 FQDN should be served using split > >> DNS and "nokia.com"'s authoritative name server should respond to > >> queries for NAT64 FQDN coming only from the "correct" access network > >> (e.g. via whitelisted RDNSS). Hence if my host in your network would > >> ask for NAT64 FQDN, it would not get positive response. That time > >> people did not agree this is actually a real problem, and hence I > >> ceased to think about solutions. > >> > >> Definitely the host can only trust the Pref64::/n is valid as such, > >> but host cannot trust that it is used in correct network:-) > >> > >> Maybe when host is provisioned with trusted domains it is also > >> provisioned with list of access networks where the domains are > >> allowed to be used. Hence your "SSID" would not be found on the > >> access network list and hence your service (or attack) would fail. > >> > >> The attacks I can imagine you can launch with this are similar you > >> can cause if you can send RAs to host (i.e. redirection, DoS). > >> > >> I'm not sure we can solve this in easy manner - best is to start > >> using end-to-end IPv6. > >> > >> And I do not agree these problems are caused by heuristic draft, but > >> effectively are present in NAT64/DNS64 framework already. Hence I > >> don't see why these issues would be showstoppers for heuristic > >> discovery. See below: > > > > I agree with your assessment, and I also believe heuristic discovery > > should proceed forward. However, secure discovery might have to be > > dropped if all it does is provide a false sense of security. > > > >>> My second concern is that it allows the people who control domains > >>> that are on the list to do evil things. Here's an example attack: > >>> the owner of nokia.com, which is on the list, turns evil. He goes in > >>> any public NAT64 hotspot and starts a rogue DNS64 server with a > >>> Pref64::/n that belongs to nokia.com. That prefix is routed to a > >>> NAT64 that belongs to Nokia, somewhere in the Internet. The prefix > >>> will be "securely discovered" because all the appropriate DNS > >>> records are present and signed, the NAT64 works, and nokia.com is on > >>> the list, yet Nokia would be hijacking traffic. > >> > >> Right, but when compared to today's state the number of possible > >> attackers actually decreases: only owners who control trusted domains > >> can attack with "malicious" Pref64::/n. > >> > >> Today anyone who can inject a hostile DNS64 address to a host's RDNSS > >> list can launch the same hijacking attack. > >> > >> So isn't this draft actually an improvement?-) > > > > Very tiny improvement. I still think it would give the user a false > > sense of security. > > > >> The beef again here I that the "secure discovery" does not mean the > >> traffic sent using the securely discovered Pref64::/n goes to the > >> right place, only that the destination address is securely formed. > > > > I presume "securely formed" means something different to you than it > > does to me... > > > >> That is similar to DNSSEC anyway: with DNSSEC you can only be sure > >> the destination address is valid - DNSSEC does not ensure the packets > >> sent to valid address are delivered where they should. > > > > With secure discovery you can't even be sure that the destination > > address is valid! All you can be sure of is that it is an address that > > belongs to somebody that also owns a domain in your trusted list. That > > is practically almost useless. > > > >>> In a nutshell, the proposed secure method of Pref64::/n discovery > >>> ensures that the DNS64 is controlled by an entity that also controls > >>> a domain name that is on a trusted list. That's not what "secure > >>> discovery" should be, IMHO. I would expect secure discovery to > >>> ensure that the DNS64 is controlled by the same entity that controls > >>> the network on which the client is. > >> > >> So we agree on this, but do you agree this is a general problem, not > >> heuristic-specific problem? > > > > Unsecure discovery is fine. It is just as unsecure as everything else. > > > > But a secure discovery that is not secure at all is just misleading. > > > >> I mean even today when I talk to DNS64 in IPv6-only access network, I > >> have no real means to tell I'm talking to legitimate DNS64. Maybe I > >> can trust the DNS64 is legitimate if I learned it via pretty trusted > >> channel, like 3GPP network L2 signaling. > >> > >> So... host should have means to learn the DNS64 address first via > >> secure means. SEND?-) > > > > IMHO, secure discovery is not necessary. It would be nice if the > > DNSSEC method had worked, but I don't think it does. > > > > Simon From ajs@anvilwalrusden.com Sun Jun 24 23:18:32 2012 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 D7D0321F849A for ; Sun, 24 Jun 2012 23:18:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 zrN5oBL0tJBd for ; Sun, 24 Jun 2012 23:18:32 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 2CFFE21F8499 for ; Sun, 24 Jun 2012 23:18:32 -0700 (PDT) Received: from mail.yitter.info (unknown [109.81.193.55]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 97EA21ECB41C for ; Mon, 25 Jun 2012 06:18:30 +0000 (UTC) Date: Mon, 25 Jun 2012 02:18:25 -0400 From: Andrew Sullivan To: behave@ietf.org Message-ID: <20120625061825.GD45427@mail.yitter.info> References: <20120624225702.GB45427@mail.yitter.info> <20120624234952.177DC21E3F6F@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120624234952.177DC21E3F6F@drugs.dv.isc.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [BEHAVE] CD overloading in DNS64 considered bad 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, 25 Jun 2012 06:18:33 -0000 On Mon, Jun 25, 2012 at 09:49:52AM +1000, Mark Andrews wrote: > > I can't write a DNS64 + DNSSEC application / server that works > due to the overloading of CD. Please expand the meaning of "works" there. > DNSSEC has CD=1 meaning don't validate. > DNS64 has CD=1 meaning don't synthesis. I think we may agree, but I don't regard them as so different. DNS64 uses the CD=1 bit to say, "Whatever is really in the DNS, regardless of what you think, give it to me raw," which is not dissimilar to what it means in DNSSEC. > If I have a validating DNS64 recursive server with a bad clock / > out of date trust anchors. I can't get a synthesised response from > this server. Correct. DNS64 and DNSSEC are bound to be an awkward combination, because DNSSEC is designed to detect modifications of data changes along the resolution path, and DNS64 is designed to modify data along the resolution path. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From marcelo@it.uc3m.es Sun Jun 24 23:53:17 2012 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 6C96B21F855E for ; Sun, 24 Jun 2012 23:53:17 -0700 (PDT) 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 ugJReKmZ1LMT for ; Sun, 24 Jun 2012 23:53:17 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id D29A021F855B for ; Sun, 24 Jun 2012 23:53:16 -0700 (PDT) X-uc3m-safe: yes Received: from marcelo-bagnulos-macbook-pro.local (unknown [163.117.139.57]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: marcelo@smtp01.uc3m.es) by smtp01.uc3m.es (Postfix) with ESMTPSA id 422F3C3B4C8 for ; Mon, 25 Jun 2012 08:53:14 +0200 (CEST) Message-ID: <4FE80ADA.1060802@it.uc3m.es> Date: Mon, 25 Jun 2012 08:53:14 +0200 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: behave@ietf.org References: <20120624234952.177DC21E3F6F@drugs.dv.isc.org> In-Reply-To: <20120624234952.177DC21E3F6F@drugs.dv.isc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.1.0.1224-6.8.0.1017-18978.006 X-TM-AS-Result: No--4.989-7.0-31-1 X-imss-scan-details: No--4.989-7.0-31-1 Subject: Re: [BEHAVE] CD overloading in DNS64 considered bad 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, 25 Jun 2012 06:53:17 -0000 That is correct but is not due to the overloading fo the CD bit, but it is a fundamental limitation of the DNS64 and DNSSEC interaction. You cannot validate dynthetice respeconses, well, because they are synthetic, so validation would fail. This is documented in rfc6147 3. If the CD bit is set and DO is set, then vDNS64 MAY perform validation, but MUST NOT perform synthesis. It MUST return the data to the query initiator, just like a regular recursive resolver, and depend on the client to do the validation and the synthesis itself. The disadvantage to this approach is that an end point that is translation-oblivious but security-aware and validating will not be able to use the DNS64 functionality. In this case, the end point will not have the desired benefit of NAT64. In effect, this strategy means that any end point that wishes to do validation in a NAT64 context must be upgraded to be translation-aware as well. So, as you say, you cant make this work. Regards, marcelo El 25/06/12 01:49, Mark Andrews escribió: > I can't write a DNS64 + DNSSEC application / server that works > due to the overloading of CD. > > DNSSEC has CD=1 meaning don't validate. > DNS64 has CD=1 meaning don't synthesis. > > If I have a validating DNS64 recursive server with a bad clock / > out of date trust anchors. I can't get a synthesised response from > this server. > > Mark From yding@cs.helsinki.fi Mon Jun 25 00:30:57 2012 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 9793F21F8508 for ; Mon, 25 Jun 2012 00:30:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 NVnO0jXY16AP for ; Mon, 25 Jun 2012 00:30:53 -0700 (PDT) Received: from mail.cs.helsinki.fi (courier.cs.helsinki.fi [128.214.9.1]) by ietfa.amsl.com (Postfix) with ESMTP id D012021F84FE for ; Mon, 25 Jun 2012 00:30:51 -0700 (PDT) Received: from [192.168.93.102] (host-94-101-2-100.igua.fi [94.101.2.100]) (AUTH: PLAIN yding, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Mon, 25 Jun 2012 10:30:49 +0300 id 0008C5BA.4FE813A9.000078B3 Message-ID: <4FE813A9.7070905@cs.helsinki.fi> Date: Mon, 25 Jun 2012 10:30:49 +0300 From: Aaron Yi DING Organization: Helsinki University User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: teemu.savolainen@nokia.com References: <9B57C850BB53634CACEC56EF4853FF653B62BDA4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B66483D@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <4FE1DC2C.1010002@viagenie.ca> <20120620143826.GE41079@mail.yitter.info>, <4FE1ECFD.3070102@viagenie.ca> <916CE6CF87173740BC8A2CE443096962043AEA77@008-AM1MPN1-053.mgdnok.nokia.com> <4FE2152D.7040402@viagenie.ca> <916CE6CF87173740BC8A2CE443096962043AEEBF@008-AM1MPN1-053.mgdnok.nokia.com> <4FE32367.5080207@viagenie.ca> <4FE3392E.40803@cs.helsinki.fi> <916CE6CF87173740BC8A2CE443096962043B7A20@008-AM1MPN1-052.mgdnok.nokia.com> In-Reply-To: <916CE6CF87173740BC8A2CE443096962043B7A20@008-AM1MPN1-052.mgdnok.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: behave@ietf.org Subject: Re: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09 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, 25 Jun 2012 07:30:57 -0000 Hi Teemu, Thanks for your update. Replacing the term with 'validation' helps. Look forward to the new version, Aaron On 25/06/12 09:00, teemu.savolainen@nokia.com wrote: > Hi Aaron, Simon, > > We discussed this a bit in the interim call, and I'm updating the draft to change the language from "Secure Learning of Pref64::/n" to "Validation of Discovered Pref64::/n" and add statements that all that this validation does is to verify the Pref64::/n is indeed one that ought to be used with a domain. > > Best regards, > > Teemu > >> -----Original Message----- >> From: ext Aaron Yi DING [mailto:yding@cs.helsinki.fi] >> Sent: 21. kesäkuuta 2012 18:10 >> To: Simon Perreault >> Cc: Savolainen Teemu (Nokia-NRC/Tampere); behave@ietf.org >> Subject: Re: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic- >> 09 >> >> Hello, >> >> Concerning the security discussion so far, it's good to keep such section rather >> than dropping it IMHO, since the main intention is to improve the security >> level of heuristic discovery. >> >> The sense of false security as Simon cited is a pretty tricky topic, especially >> when we assume there will always be certain kind of imaginary attacks out >> there (though what Simon mentioned are indeed valid) >> >> Such false security statement is just like the Carl Sagan's Dragon >> http://www.users.qwest.net/~jcosta3/article_dragon.htm >> >> To believe the approach as "insecure" is essentially a statement that can >> hardly be proven wrong, period. >> Please kindly check Carl's dragon, If hard to comprehend. >> >> The security section needs improvement, yes, but not dropped. >> >> Thanks, >> Aaron >> >> >> >> On 21/06/12 16:36, Simon Perreault wrote: >>> On 2012-06-21 03:11, teemu.savolainen@nokia.com wrote: >>>>> My first concern is that it doesn't really add any security. If you >>>>> come visit me to my office, where we run a NAT64, and I really want >>>>> you to discover our prefix securely without you having to click >>>>> through a scary dialog box, I will just squat the prefix of someone >>>>> else who is probably already on the list (e.g., nokia.com), and >>>>> route it to our NAT64 box. I didn't add any security, but somehow >>>>> your client thinks this is secure. I just picked a different prefix, >>>>> one that is in your client's "secure" set. >>>> The client must always use network/transport/application layer >>>> security to be secure. >>>> >>>> But I do know this "problem". I tried to tackle this in the previous >>>> I-D versions by writing that NAT64 FQDN should be served using split >>>> DNS and "nokia.com"'s authoritative name server should respond to >>>> queries for NAT64 FQDN coming only from the "correct" access network >>>> (e.g. via whitelisted RDNSS). Hence if my host in your network would >>>> ask for NAT64 FQDN, it would not get positive response. That time >>>> people did not agree this is actually a real problem, and hence I >>>> ceased to think about solutions. >>>> >>>> Definitely the host can only trust the Pref64::/n is valid as such, >>>> but host cannot trust that it is used in correct network:-) >>>> >>>> Maybe when host is provisioned with trusted domains it is also >>>> provisioned with list of access networks where the domains are >>>> allowed to be used. Hence your "SSID" would not be found on the >>>> access network list and hence your service (or attack) would fail. >>>> >>>> The attacks I can imagine you can launch with this are similar you >>>> can cause if you can send RAs to host (i.e. redirection, DoS). >>>> >>>> I'm not sure we can solve this in easy manner - best is to start >>>> using end-to-end IPv6. >>>> >>>> And I do not agree these problems are caused by heuristic draft, but >>>> effectively are present in NAT64/DNS64 framework already. Hence I >>>> don't see why these issues would be showstoppers for heuristic >>>> discovery. See below: >>> I agree with your assessment, and I also believe heuristic discovery >>> should proceed forward. However, secure discovery might have to be >>> dropped if all it does is provide a false sense of security. >>> >>>>> My second concern is that it allows the people who control domains >>>>> that are on the list to do evil things. Here's an example attack: >>>>> the owner of nokia.com, which is on the list, turns evil. He goes in >>>>> any public NAT64 hotspot and starts a rogue DNS64 server with a >>>>> Pref64::/n that belongs to nokia.com. That prefix is routed to a >>>>> NAT64 that belongs to Nokia, somewhere in the Internet. The prefix >>>>> will be "securely discovered" because all the appropriate DNS >>>>> records are present and signed, the NAT64 works, and nokia.com is on >>>>> the list, yet Nokia would be hijacking traffic. >>>> Right, but when compared to today's state the number of possible >>>> attackers actually decreases: only owners who control trusted domains >>>> can attack with "malicious" Pref64::/n. >>>> >>>> Today anyone who can inject a hostile DNS64 address to a host's RDNSS >>>> list can launch the same hijacking attack. >>>> >>>> So isn't this draft actually an improvement?-) >>> Very tiny improvement. I still think it would give the user a false >>> sense of security. >>> >>>> The beef again here I that the "secure discovery" does not mean the >>>> traffic sent using the securely discovered Pref64::/n goes to the >>>> right place, only that the destination address is securely formed. >>> I presume "securely formed" means something different to you than it >>> does to me... >>> >>>> That is similar to DNSSEC anyway: with DNSSEC you can only be sure >>>> the destination address is valid - DNSSEC does not ensure the packets >>>> sent to valid address are delivered where they should. >>> With secure discovery you can't even be sure that the destination >>> address is valid! All you can be sure of is that it is an address that >>> belongs to somebody that also owns a domain in your trusted list. That >>> is practically almost useless. >>> >>>>> In a nutshell, the proposed secure method of Pref64::/n discovery >>>>> ensures that the DNS64 is controlled by an entity that also controls >>>>> a domain name that is on a trusted list. That's not what "secure >>>>> discovery" should be, IMHO. I would expect secure discovery to >>>>> ensure that the DNS64 is controlled by the same entity that controls >>>>> the network on which the client is. >>>> So we agree on this, but do you agree this is a general problem, not >>>> heuristic-specific problem? >>> Unsecure discovery is fine. It is just as unsecure as everything else. >>> >>> But a secure discovery that is not secure at all is just misleading. >>> >>>> I mean even today when I talk to DNS64 in IPv6-only access network, I >>>> have no real means to tell I'm talking to legitimate DNS64. Maybe I >>>> can trust the DNS64 is legitimate if I learned it via pretty trusted >>>> channel, like 3GPP network L2 signaling. >>>> >>>> So... host should have means to learn the DNS64 address first via >>>> secure means. SEND?-) >>> IMHO, secure discovery is not necessary. It would be nice if the >>> DNSSEC method had worked, but I don't think it does. >>> >>> Simon From marka@isc.org Mon Jun 25 00:41:41 2012 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 8899B21F8512 for ; Mon, 25 Jun 2012 00:41:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.442 X-Spam-Level: X-Spam-Status: No, score=-2.442 tagged_above=-999 required=5 tests=[AWL=0.157, 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 dy-M+9iN7nha for ; Mon, 25 Jun 2012 00:41:37 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 0761A21F850D for ; Mon, 25 Jun 2012 00:41:37 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS id 210A4C95E1; Mon, 25 Jun 2012 07:41:25 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:49db:b78e:a3fc:c3b4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 5ABB6216C33; Mon, 25 Jun 2012 07:41:22 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id A627221EC353; Mon, 25 Jun 2012 17:41:13 +1000 (EST) To: Andrew Sullivan From: Mark Andrews References: <20120624225702.GB45427@mail.yitter.info> <20120624234952.177DC21E3F6F@drugs.dv.isc.org> <20120625061825.GD45427@mail.yitter.info> In-reply-to: Your message of "Mon, 25 Jun 2012 02:18:25 -0400." <20120625061825.GD45427@mail.yitter.info> Date: Mon, 25 Jun 2012 17:41:13 +1000 Message-Id: <20120625074113.A627221EC353@drugs.dv.isc.org> Cc: behave@ietf.org Subject: Re: [BEHAVE] CD overloading in DNS64 considered bad 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, 25 Jun 2012 07:41:41 -0000 In message <20120625061825.GD45427@mail.yitter.info>, Andrew Sullivan writes: > On Mon, Jun 25, 2012 at 09:49:52AM +1000, Mark Andrews wrote: > > > > I can't write a DNS64 + DNSSEC application / server that works > > due to the overloading of CD. > > Please expand the meaning of "works" there. I have a application which knows to set CD=1 for particular names because a upstream server (recursive or authoritative) is DNSSEC broken and it is willing to live with non-validating data. Now try it introduce DNS64. It won't work because CD=1 says "don't synthesis" and without CD=1 there is no data for DNS64 to work with. > > DNSSEC has CD=1 meaning don't validate. > > DNS64 has CD=1 meaning don't synthesis. > > I think we may agree, but I don't regard them as so different. DNS64 > uses the CD=1 bit to say, "Whatever is really in the DNS, regardless > of what you think, give it to me raw," which is not dissimilar to what > it means in DNSSEC. What comes out looks the same but the purposes are orthogonal. > > If I have a validating DNS64 recursive server with a bad clock / > > out of date trust anchors. I can't get a synthesised response from > > this server. > > Correct. DNS64 and DNSSEC are bound to be an awkward combination, > because DNSSEC is designed to detect modifications of data changes > along the resolution path, and DNS64 is designed to modify data along > the resolution path. And they can be made to work. See my recent post to this list for how. > Best, > > A > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From marcelo@it.uc3m.es Mon Jun 25 01:07:03 2012 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 5B92021F84B2 for ; Mon, 25 Jun 2012 01:07:03 -0700 (PDT) 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 5lMgJr+fVe0C for ; Mon, 25 Jun 2012 01:06:59 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by ietfa.amsl.com (Postfix) with ESMTP id 3AF5821F84B3 for ; Mon, 25 Jun 2012 01:06:59 -0700 (PDT) X-uc3m-safe: yes Received: from dummyhost9.it.uc3m.es (dummyhost9.it.uc3m.es [163.117.139.57]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: marcelo@smtp02.uc3m.es) by smtp02.uc3m.es (Postfix) with ESMTPSA id 6FDDF7663B5 for ; Mon, 25 Jun 2012 10:06:57 +0200 (CEST) Message-ID: <4FE81C20.50208@it.uc3m.es> Date: Mon, 25 Jun 2012 10:06:56 +0200 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: behave@ietf.org References: <20120624225702.GB45427@mail.yitter.info> <20120624234952.177DC21E3F6F@drugs.dv.isc.org> <20120625061825.GD45427@mail.yitter.info> <20120625074113.A627221EC353@drugs.dv.isc.org> In-Reply-To: <20120625074113.A627221EC353@drugs.dv.isc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.1.0.1224-6.8.0.1017-18994.005 X-TM-AS-Result: No--18.274-7.0-31-1 X-imss-scan-details: No--18.274-7.0-31-1 Subject: Re: [BEHAVE] CD overloading in DNS64 considered bad 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, 25 Jun 2012 08:07:03 -0000 El 25/06/12 09:41, Mark Andrews escribió: > In message<20120625061825.GD45427@mail.yitter.info>, Andrew Sullivan writes: >> On Mon, Jun 25, 2012 at 09:49:52AM +1000, Mark Andrews wrote: >>> I can't write a DNS64 + DNSSEC application / server that works >>> due to the overloading of CD. >> Please expand the meaning of "works" there. > I have a application which knows to set CD=1 for particular names > because a upstream server (recursive or authoritative) is DNSSEC > broken and it is willing to live with non-validating data. i am missing something here. If the application is willing to live wihtout DNSSEc data, why would it set CD bit? If that is the case, it shouldnot set any DNSSEC bit and live without DNSSEC and DNS64 would work just fine. I guess this is not what you have in mind, so can you clarify? > > Now try it introduce DNS64. It won't work because CD=1 says "don't > synthesis" and without CD=1 there is no data for DNS64 to work with. > >>> DNSSEC has CD=1 meaning don't validate. >>> DNS64 has CD=1 meaning don't synthesis. >> I think we may agree, but I don't regard them as so different. DNS64 >> uses the CD=1 bit to say, "Whatever is really in the DNS, regardless >> of what you think, give it to me raw," which is not dissimilar to what >> it means in DNSSEC. > What comes out looks the same but the purposes are orthogonal. > >>> If I have a validating DNS64 recursive server with a bad clock / >>> out of date trust anchors. I can't get a synthesised response from >>> this server. >> Correct. DNS64 and DNSSEC are bound to be an awkward combination, >> because DNSSEC is designed to detect modifications of data changes >> along the resolution path, and DNS64 is designed to modify data along >> the resolution path. > And they can be made to work. See my recent post to this list for how. Sorry, i must have missed this one, could you send me a pointer? Regards, marcelo >> Best, >> >> A >> >> -- >> Andrew Sullivan >> ajs@anvilwalrusden.com >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave From ajs@anvilwalrusden.com Mon Jun 25 04:57:53 2012 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 83DAB21F8501 for ; Mon, 25 Jun 2012 04:57:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 cu2NB6c2BYit for ; Mon, 25 Jun 2012 04:57:53 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 0611C21F84F0 for ; Mon, 25 Jun 2012 04:57:52 -0700 (PDT) Received: from mail.yitter.info (unknown [199.91.193.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id A015E1ECB41C for ; Mon, 25 Jun 2012 11:57:51 +0000 (UTC) Date: Mon, 25 Jun 2012 07:57:19 -0400 From: Andrew Sullivan To: behave@ietf.org Message-ID: <20120625115719.GA45859@mail.yitter.info> References: <20120624225702.GB45427@mail.yitter.info> <20120624234952.177DC21E3F6F@drugs.dv.isc.org> <20120625061825.GD45427@mail.yitter.info> <20120625074113.A627221EC353@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120625074113.A627221EC353@drugs.dv.isc.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [BEHAVE] CD overloading in DNS64 considered bad 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, 25 Jun 2012 11:57:53 -0000 On Mon, Jun 25, 2012 at 05:41:13PM +1000, Mark Andrews wrote: > I have a application which knows to set CD=1 for particular names > because a upstream server (recursive or authoritative) is DNSSEC > broken and it is willing to live with non-validating data. > > Now try it introduce DNS64. It won't work because CD=1 says "don't > synthesis" and without CD=1 there is no data for DNS64 to work with. Correct. If you want to use CD=1, then you need to be DNS64 aware too. DNS64 has failure modes that other resolution strategies don't have, yes. > > the resolution path. > > And they can be made to work. See my recent post to this list for how. Is this the one from some weeks ago where you suggested using the DO bit instead? I don't see how that's going to work: many shipping resolvers set DO, but very few set CD. Please recall that the main point of DNS64/NAT64 is that very few things in the network need to be altered. It's a hack to get around the lack of IPv6 deployment. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From marka@isc.org Mon Jun 25 07:03:19 2012 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 58EBE21F85BD for ; Mon, 25 Jun 2012 07:03:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.462 X-Spam-Level: X-Spam-Status: No, score=-2.462 tagged_above=-999 required=5 tests=[AWL=0.137, 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 qbTZJuUSmXIR for ; Mon, 25 Jun 2012 07:03:14 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id AAD7821F85C6 for ; Mon, 25 Jun 2012 07:03:14 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS id 0DCD1C973D; Mon, 25 Jun 2012 14:03:03 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:5951:da2b:5f8a:d787]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 31A54216C33; Mon, 25 Jun 2012 14:03:00 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 2B22A21ECFB2; Tue, 26 Jun 2012 00:02:59 +1000 (EST) To: marcelo bagnulo braun From: Mark Andrews References: <20120624225702.GB45427@mail.yitter.info> <20120624234952.177DC21E3F6F@drugs.dv.isc.org> <20120625061825.GD45427@mail.yitter.info> <20120625074113.A627221EC353@drugs.dv.isc.org> <4FE81C20.50208@it.uc3m.es> In-reply-to: Your message of "Mon, 25 Jun 2012 10:06:56 +0200." <4FE81C20.50208@it.uc3m.es> Date: Tue, 26 Jun 2012 00:02:58 +1000 Message-Id: <20120625140259.2B22A21ECFB2@drugs.dv.isc.org> Cc: behave@ietf.org Subject: Re: [BEHAVE] CD overloading in DNS64 considered bad 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, 25 Jun 2012 14:03:19 -0000 In message <4FE81C20.50208@it.uc3m.es>, marcelo bagnulo braun writes: > El 25/06/12 09:41, Mark Andrews escribi=F3: > > In message<20120625061825.GD45427@mail.yitter.info>, Andrew Sullivan writ= > es: > >> On Mon, Jun 25, 2012 at 09:49:52AM +1000, Mark Andrews wrote: > >>> I can't write a DNS64 + DNSSEC application / server that works > >>> due to the overloading of CD. > >> Please expand the meaning of "works" there. > > I have a application which knows to set CD=1 for particular names > > because a upstream server (recursive or authoritative) is DNSSEC > > broken and it is willing to live with non-validating data. > > i am missing something here. If the application is willing to live = > wihtout DNSSEc data, why would it set CD bit? Because it wants a answer and there is a upstream validator stopping the answer due to a DNSSEC validation failure. > If that is the case, it shouldnot set any DNSSEC bit and live without = > DNSSEC and DNS64 would work just fine. It isn't just the end client that validates in DNSSEC. Everything except the authoritative sources should be validating as there are error cases / attacks that can't be recovered from unless everyone is validating. Not everyone in the DNSSEC community will agree with me on this but time and experience will tell that I'm right on this. You don't have to be setting bits for DNSSEC to impact responses. You need to set bits to stop DNSSEC to impacting responses i.e. CD=1. RFC 6147 Section 5.5 failed to even address CD=1, DO=0. It also failed to address that there are both signed and unsigned responses to DO=1 queries. It also failed to address daisy chained validators. > I guess this is not what you have in mind, so can you clarify? > > > Now try it introduce DNS64. It won't work because CD=1 says "don't > > synthesis" and without CD=1 there is no data for DNS64 to work with. > > > >>> DNSSEC has CD=1 meaning don't validate. > >>> DNS64 has CD=1 meaning don't synthesis. > >> > >> I think we may agree, but I don't regard them as so different. DNS64 > >> uses the CD=1 bit to say, "Whatever is really in the DNS, regardless > >> of what you think, give it to me raw," which is not dissimilar to what > >> it means in DNSSEC. > > What comes out looks the same but the purposes are orthogonal. > > > >>> If I have a validating DNS64 recursive server with a bad clock / > >>> out of date trust anchors. I can't get a synthesised response from > >>> this server. > >> Correct. DNS64 and DNSSEC are bound to be an awkward combination, > >> because DNSSEC is designed to detect modifications of data changes > >> along the resolution path, and DNS64 is designed to modify data along > >> the resolution path. > > And they can be made to work. See my recent post to this list for how. > > Sorry, i must have missed this one, could you send me a pointer? http://www.ietf.org/mail-archive/web/behave/current/msg10461.html > Regards, marcelo > > >> Best, > >> > >> A > >> > >> -- = > > >> Andrew Sullivan > >> ajs@anvilwalrusden.com > >> _______________________________________________ > >> 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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From ajs@anvilwalrusden.com Mon Jun 25 07:42:02 2012 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 0925321F8637 for ; Mon, 25 Jun 2012 07:42:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 2Wfj669ckOpo for ; Mon, 25 Jun 2012 07:42:01 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 98AB221F8642 for ; Mon, 25 Jun 2012 07:42:00 -0700 (PDT) Received: from mail.yitter.info (unknown [199.91.193.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 270441ECB41C for ; Mon, 25 Jun 2012 14:41:59 +0000 (UTC) Date: Mon, 25 Jun 2012 10:41:46 -0400 From: Andrew Sullivan To: behave@ietf.org Message-ID: <20120625144145.GA46008@mail.yitter.info> References: <20120624225702.GB45427@mail.yitter.info> <20120624234952.177DC21E3F6F@drugs.dv.isc.org> <20120625061825.GD45427@mail.yitter.info> <20120625074113.A627221EC353@drugs.dv.isc.org> <4FE81C20.50208@it.uc3m.es> <20120625140259.2B22A21ECFB2@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120625140259.2B22A21ECFB2@drugs.dv.isc.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [BEHAVE] CD overloading in DNS64 considered bad 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, 25 Jun 2012 14:42:02 -0000 Mark, On Tue, Jun 26, 2012 at 12:02:58AM +1000, Mark Andrews wrote: > > RFC 6147 Section 5.5 failed to even address CD=1, DO=0. It also > failed to address that there are both signed and unsigned responses > to DO=1 queries. It also failed to address daisy chained validators. Two things. First, with respect, as far as I know you were participating here when RFC 6147 was called; solicitations for review also appeared on the DNSEXT mailing list. It'd have been nice if you sent text when it was asked for. But more importantly, since we're talking about deficiencies, what exactly would you like to have happen when CD=1 and DO=0? Why do you think that the signed and unsigned responses matter, given that the only way the protocol allows you to do DNSSEC with DNS64 is to do the DNS64 yourself? And why do you think that it should have addressed daisy chained validators (in particular)? Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From marka@isc.org Mon Jun 25 08:33:04 2012 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 358A311E808D for ; Mon, 25 Jun 2012 08:33:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.477 X-Spam-Level: X-Spam-Status: No, score=-2.477 tagged_above=-999 required=5 tests=[AWL=0.122, 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 Wby3JZ9g6FMr for ; Mon, 25 Jun 2012 08:33:03 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 9A47811E808C for ; Mon, 25 Jun 2012 08:33:03 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 8E4365F99C1; Mon, 25 Jun 2012 15:32:49 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:5951:da2b:5f8a:d787]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id BC071216C33; Mon, 25 Jun 2012 15:32:47 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id F195521ED7B3; Tue, 26 Jun 2012 01:32:42 +1000 (EST) To: Andrew Sullivan From: Mark Andrews References: <20120624225702.GB45427@mail.yitter.info> <20120624234952.177DC21E3F6F@drugs.dv.isc.org> <20120625061825.GD45427@mail.yitter.info> <20120625074113.A627221EC353@drugs.dv.isc.org> <20120625115719.GA45859@mail.yitter.info> In-reply-to: Your message of "Mon, 25 Jun 2012 07:57:19 -0400." <20120625115719.GA45859@mail.yitter.info> Date: Tue, 26 Jun 2012 01:32:42 +1000 Message-Id: <20120625153242.F195521ED7B3@drugs.dv.isc.org> Cc: behave@ietf.org Subject: Re: [BEHAVE] CD overloading in DNS64 considered bad 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, 25 Jun 2012 15:33:04 -0000 In message <20120625115719.GA45859@mail.yitter.info>, Andrew Sullivan writes: > On Mon, Jun 25, 2012 at 05:41:13PM +1000, Mark Andrews wrote: > > I have a application which knows to set CD=1 for particular names > > because a upstream server (recursive or authoritative) is DNSSEC > > broken and it is willing to live with non-validating data. > > > > Now try it introduce DNS64. It won't work because CD=1 says "don't > > synthesis" and without CD=1 there is no data for DNS64 to work with. > > Correct. If you want to use CD=1, then you need to be DNS64 aware > too. DNS64 has failure modes that other resolution strategies don't > have, yes. > > > the resolution path. > > > > And they can be made to work. See my recent post to this list for how. > > Is this the one from some weeks ago where you suggested using the DO > bit instead? I don't see how that's going to work: many shipping > resolvers set DO, but very few set CD. Please recall that the main > point of DNS64/NAT64 is that very few things in the network need to be > altered. It's a hack to get around the lack of IPv6 deployment. At the moment we have every application that accepts raw IP addresses needing to be upgraded. Now we can push that down into getaddrinfo() but that requires upgrading the system libraries. You also need to upgrade recursive servers to be DNS64 aware as RFC 1034 recursive servers don't pass on CD=1 and DNSSEC recursive servers return cached CD=0 answers to CD=1 queries. Even if DNS64 aware recursive servers are installed there is no sane DNS64 signalling to the DNS64 server. Additionally if there are DNSSEC errors there is no way to pass DNS64 information on the the client when that occurs because DNS64 has stolen the one bit that is used to turn off DNSSEC and re-purposed it for DNS64. And while it is a hack I expect it to be around for many years and I don't want it to slow down DNSSEC deployment. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From marka@isc.org Mon Jun 25 09:36:53 2012 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 92D9D21F8480 for ; Mon, 25 Jun 2012 09:36:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.489 X-Spam-Level: X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[AWL=0.110, 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 nNJ134Sjsbaa for ; Mon, 25 Jun 2012 09:36:53 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id C8B2721F8421 for ; Mon, 25 Jun 2012 09:36:52 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS id B5B7DC94D9; Mon, 25 Jun 2012 16:36:41 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:5951:da2b:5f8a:d787]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id CCC06216C33; Mon, 25 Jun 2012 16:36:38 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 53F5F21EDA40; Tue, 26 Jun 2012 02:36:36 +1000 (EST) To: Andrew Sullivan From: Mark Andrews References: <20120624225702.GB45427@mail.yitter.info> <20120624234952.177DC21E3F6F@drugs.dv.isc.org> <20120625061825.GD45427@mail.yitter.info> <20120625074113.A627221EC353@drugs.dv.isc.org> <4FE81C20.50208@it.uc3m.es> <20120625140259.2B22A21ECFB2@drugs.dv.isc.org> <20120625144145.GA46008@mail.yitter.info> In-reply-to: Your message of "Mon, 25 Jun 2012 10:41:46 -0400." <20120625144145.GA46008@mail.yitter.info> Date: Tue, 26 Jun 2012 02:36:36 +1000 Message-Id: <20120625163636.53F5F21EDA40@drugs.dv.isc.org> Cc: behave@ietf.org Subject: Re: [BEHAVE] CD overloading in DNS64 considered bad 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, 25 Jun 2012 16:36:53 -0000 In message <20120625144145.GA46008@mail.yitter.info>, Andrew Sullivan writes: > Mark, > > On Tue, Jun 26, 2012 at 12:02:58AM +1000, Mark Andrews wrote: > > > > RFC 6147 Section 5.5 failed to even address CD=1, DO=0. It also > > failed to address that there are both signed and unsigned responses > > to DO=1 queries. It also failed to address daisy chained validators. > > Two things. First, with respect, as far as I know you were > participating here when RFC 6147 was called; solicitations for review > also appeared on the DNSEXT mailing list. It'd have been nice if you > sent text when it was asked for. If I had thought of it I would have mentioned it at the time. Not synthesising on CD=1, DO=1 is fine. RFC 6147 was pushed through in behave. Lots of things were left for later. draft-ietf-behave-nat64-discovery-heuristic has taken CD=1, DO=1 from RFC 6147 and made it just CD=1 which breaks DNSSEC error handling. > But more importantly, since we're talking about deficiencies, what > exactly would you like to have happen when CD=1 and DO=0? That the unvalidated answers have DNS64 processing applied to them. > Why do you > think that the signed and unsigned responses matter, given that the > only way the protocol allows you to do DNSSEC with DNS64 is to do the > DNS64 yourself? This working group wanted DNS64 to work through existing servers to the best of its ability. You can synthesis responses to DO=1,CD=1 queries provided the responses from the authoritative sources are not signed and not break validation. > And why do you think that it should have addressed daisy chained > validators (in particular)? > Best, > > A > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From teemu.savolainen@nokia.com Mon Jun 25 12:11:45 2012 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 784E611E80B5 for ; Mon, 25 Jun 2012 12:11:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 v5ufJPM0BK29 for ; Mon, 25 Jun 2012 12:11:42 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 3E1AF11E8089 for ; Mon, 25 Jun 2012 12:11:41 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q5PJBWWv015398; Mon, 25 Jun 2012 22:11:34 +0300 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); Mon, 25 Jun 2012 22:11:38 +0300 Received: from 008-AM1MPN1-052.mgdnok.nokia.com ([169.254.2.174]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.02.0283.004; Mon, 25 Jun 2012 21:11:31 +0200 From: To: , Thread-Topic: [BEHAVE] CD overloading in DNS64 considered bad Thread-Index: AQHNUvDAVsfawtaob0m7nLeJLMv2NZcLYzZA Date: Mon, 25 Jun 2012 19:11:31 +0000 Message-ID: <916CE6CF87173740BC8A2CE443096962043BD71C@008-AM1MPN1-052.mgdnok.nokia.com> References: <20120624225702.GB45427@mail.yitter.info> <20120624234952.177DC21E3F6F@drugs.dv.isc.org> <20120625061825.GD45427@mail.yitter.info> <20120625074113.A627221EC353@drugs.dv.isc.org> <4FE81C20.50208@it.uc3m.es> <20120625140259.2B22A21ECFB2@drugs.dv.isc.org> <20120625144145.GA46008@mail.yitter.info> <20120625163636.53F5F21EDA40@drugs.dv.isc.org> In-Reply-To: <20120625163636.53F5F21EDA40@drugs.dv.isc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.163.17.111] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 25 Jun 2012 19:11:38.0211 (UTC) FILETIME=[586DC330:01CD5306] X-Nokia-AV: Clean Cc: behave@ietf.org Subject: Re: [BEHAVE] CD overloading in DNS64 considered bad 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, 25 Jun 2012 19:11:45 -0000 > draft-ietf-behave-nat64-discovery-heuristic has taken CD=3D1, DO=3D1 from= RFC > 6147 and made it just CD=3D1 which breaks DNSSEC error handling. The draft is quite open for corrections and improvements. So heuristic-drafti should say to set DO=3D0 and CD=3D0 ? (instead of just = CD=3D0 as of now - the draft does not say set CD=3D1) DO=3D1 is problem if the DNS64 is security-oblivious (RFC6147 section 3 ste= p 2), I mean with DO=3D0 and CD=3D0 for well-known name query the DNS64 will perf= orm RFC6147 section 3 step 5, and validate the A record of well-known name = but still will synthesize AAAA record for the querying node. Right? Best regards, Teemu From Dmitry.Anipko@microsoft.com Mon Jun 25 14:25:08 2012 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 6007211E80B8 for ; Mon, 25 Jun 2012 14:25:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.467 X-Spam-Level: X-Spam-Status: No, score=-0.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132] 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 xHdfhdJhuzQO for ; Mon, 25 Jun 2012 14:25:07 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe002.messaging.microsoft.com [213.199.154.140]) by ietfa.amsl.com (Postfix) with ESMTP id 6663211E80A4 for ; Mon, 25 Jun 2012 14:25:07 -0700 (PDT) Received: from mail60-db3-R.bigfish.com (10.3.81.228) by DB3EHSOBE005.bigfish.com (10.3.84.25) with Microsoft SMTP Server id 14.1.225.23; Mon, 25 Jun 2012 21:23:27 +0000 Received: from mail60-db3 (localhost [127.0.0.1]) by mail60-db3-R.bigfish.com (Postfix) with ESMTP id D85772E02C7 for ; Mon, 25 Jun 2012 21:23:27 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -27 X-BigFish: VS-27(zz9371I542M1432Izz1202hzz1033IL8275dhz2fh2a8h683h839h944hd25hf0ah) Received-SPF: pass (mail60-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Dmitry.Anipko@microsoft.com; helo=TK5EX14HUBC104.redmond.corp.microsoft.com ; icrosoft.com ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.244.37; KIP:(null); UIP:(null); (null); H:CH1PRD0310HT002.namprd03.prod.outlook.com; R:internal; EFV:INT Received: from mail60-db3 (localhost.localdomain [127.0.0.1]) by mail60-db3 (MessageSwitch) id 1340659406215621_11477; Mon, 25 Jun 2012 21:23:26 +0000 (UTC) Received: from DB3EHSMHS011.bigfish.com (unknown [10.3.81.244]) by mail60-db3.bigfish.com (Postfix) with ESMTP id 32C58440049 for ; Mon, 25 Jun 2012 21:23:26 +0000 (UTC) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS011.bigfish.com (10.3.87.111) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 25 Jun 2012 21:23:25 +0000 Received: from tx2outboundpool.messaging.microsoft.com (157.54.51.112) by mail.microsoft.com (157.54.80.25) with Microsoft SMTP Server (TLS) id 14.2.309.3; Mon, 25 Jun 2012 21:25:00 +0000 Received: from mail140-tx2-R.bigfish.com (10.9.14.235) by TX2EHSOBE006.bigfish.com (10.9.40.26) with Microsoft SMTP Server id 14.1.225.23; Mon, 25 Jun 2012 21:22:48 +0000 Received: from mail140-tx2 (localhost [127.0.0.1]) by mail140-tx2-R.bigfish.com (Postfix) with ESMTP id BE09A120100 for ; Mon, 25 Jun 2012 21:22:47 +0000 (UTC) Received: from mail140-tx2 (localhost.localdomain [127.0.0.1]) by mail140-tx2 (MessageSwitch) id 134065936551095_6926; Mon, 25 Jun 2012 21:22:45 +0000 (UTC) Received: from TX2EHSMHS010.bigfish.com (unknown [10.9.14.254]) by mail140-tx2.bigfish.com (Postfix) with ESMTP id 00A4CE005B for ; Mon, 25 Jun 2012 21:22:45 +0000 (UTC) Received: from CH1PRD0310HT002.namprd03.prod.outlook.com (157.56.244.37) by TX2EHSMHS010.bigfish.com (10.9.99.110) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 25 Jun 2012 21:22:44 +0000 Received: from CH1PRD0310MB368.namprd03.prod.outlook.com ([169.254.8.166]) by CH1PRD0310HT002.namprd03.prod.outlook.com ([10.255.137.37]) with mapi id 14.16.0164.004; Mon, 25 Jun 2012 21:24:20 +0000 From: Dmitry Anipko To: Dave Thaler , "behave@ietf.org" Thread-Topic: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09 Thread-Index: AQHNTa6WlGX//ByshEqwAxlmPJbl9JcLlDUQ Date: Mon, 25 Jun 2012 21:24:19 +0000 Message-ID: <96DD85EB136DCD49AB5CDB6DEC9639AD068597EA@CH1PRD0310MB368.namprd03.prod.outlook.com> References: <9B57C850BB53634CACEC56EF4853FF653B62BDA4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B66483D@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B66483D@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.192.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: CH1PRD0310HT002.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14HUBC104.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC104.redmond.corp.microsoft.com X-OriginatorOrg: microsoft.com Subject: Re: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09 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, 25 Jun 2012 21:25:08 -0000 I've read the draft and have a question. There is a following requirement i= n RFC 6147: >>The implementation SHOULD support mapping of separate IPv4 address ranges to separate IPv6 prefixes for AAAA record synthesis. This allows handling of special use IPv4 addresses [RFC5735]. In case the DNS64 in the network is configured with several such (IPv4 addr= ess range)->(IPv6 prefix) mappings, how a host using the proposed heuristic= can discover all such mappings? (without them, it seems the host would not= be able to perform IPv6 address synthesis correctly for all possible IPv4 = addresses the network DNS64 would be able to).=20 Or is there something that makes the heuristic work even without discovery = of all the mappings? -Dmitry -----Original Message----- From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of= Dave Thaler Sent: Monday, June 18, 2012 5:00 PM To: behave@ietf.org Subject: Re: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristi= c-09 So far I've seen 3 reviews: * Andrew Sullivan * Aaron Yi DING * Dave Thaler We need at least 5 reviews on this document. Can we get two more voluntee= rs? Maybe Simon and/or Marc P.-H.? Anyone else? -Dave > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of Dave Thaler > Sent: Friday, June 1, 2012 6:07 PM > To: behave@ietf.org > Subject: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-= 09 >=20 > This email initiates a two-week Working Group Last Call on draft-ietf-beh= ave- > nat64-discovery-heuristic-09, to conclude > Friday June 15th. Hopefully that will give some time before > our next interim meeting to review the comments and have proposed > resolutions ready to discuss at the June 21st interim meeting. >=20 > We need at least 5 reviewers to comment on the doc (even if just saying > "loos good"). >=20 > -Dave Thaler >=20 >=20 > _______________________________________________ > 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 From marka@isc.org Mon Jun 25 17:14:55 2012 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 3865911E80F7 for ; Mon, 25 Jun 2012 17:14:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 nMsfJtndZzNU for ; Mon, 25 Jun 2012 17:14:54 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 5449F11E80BB for ; Mon, 25 Jun 2012 17:14:54 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 9592F5F98B1; Tue, 26 Jun 2012 00:14:37 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:5951:da2b:5f8a:d787]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id AB3E1216C33; Tue, 26 Jun 2012 00:14:35 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id EC58621EF0C9; Tue, 26 Jun 2012 10:14:32 +1000 (EST) To: Dmitry Anipko From: Mark Andrews References: <9B57C850BB53634CACEC56EF4853FF653B62BDA4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B66483D@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <96DD85EB136DCD49AB5CDB6DEC9639AD068597EA@CH1PRD0310MB368.namprd03.prod.outlook.com> In-reply-to: Your message of "Mon, 25 Jun 2012 21:24:19 GMT." <96DD85EB136DCD49AB5CDB6DEC9639AD068597EA@CH1PRD0310MB368.namprd03.prod.outlook.com> Date: Tue, 26 Jun 2012 10:14:32 +1000 Message-Id: <20120626001432.EC58621EF0C9@drugs.dv.isc.org> Cc: "behave@ietf.org" , Dave Thaler Subject: Re: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09 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, 26 Jun 2012 00:14:55 -0000 In message <96DD85EB136DCD49AB5CDB6DEC9639AD068597EA@CH1PRD0310MB368.namprd03.p rod.outlook.com>, Dmitry Anipko writes: > I've read the draft and have a question. There is a following requirement in > RFC 6147: > > > >>The implementation SHOULD support mapping of separate IPv4 address > ranges to separate IPv6 prefixes for AAAA record synthesis. This > allows handling of special use IPv4 addresses [RFC5735]. > > > In case the DNS64 in the network is configured with several such (IPv4 addres > s range)->(IPv6 prefix) mappings, how a host using the proposed heuristic can > discover all such mappings? (without them, it seems the host would not be ab > le to perform IPv6 address synthesis correctly for all possible IPv4 addresse > s the network DNS64 would be able to). > > Or is there something that makes the heuristic work even without discovery of > all the mappings? > > -Dmitry You can't with draft-ietf-behave-nat64-discovery-heuristic. One could encode the IPv4 address into QNAME and make AAAA queries. .ipv4only.arpa. Where is the 32 bit decimal value of the IPv4 address with no leading zeros. There is no need to split the address into octets or nibbles as there is no delegation needed. The server behaves as if ".ipv4only.arpa. A " exists. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From dwing@cisco.com Mon Jun 25 18:37:57 2012 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 7D2AF11E8079 for ; Mon, 25 Jun 2012 18:37:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.233 X-Spam-Level: X-Spam-Status: No, score=-110.233 tagged_above=-999 required=5 tests=[AWL=0.366, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 v56MLoAmm3PW for ; Mon, 25 Jun 2012 18:37:57 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id F0B3E11E8080 for ; Mon, 25 Jun 2012 18:37:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=199; q=dns/txt; s=iport; t=1340674677; x=1341884277; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=mdJJt1YsDxKePUUdQWUVIf9vT0Fk+eiek+VnM/uwiX4=; b=iUlFrLMddGFlhGD4jGJpJUEAj18Tohvkx0MuJ+5guD5kqCI5vHUnbJsi pFKGPT9CLywd5/DZ/RCFu+zr1f8LmjAAO/ACyvGtIALI8zcXVRFMb6qlf KiSii3sQuLAICcw+TfQGpvyaVQIT/8iXlV1JmFMP0X1499AjKl7IuOSEL 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjQOAPwR6U+rRDoJ/2dsb2JhbABEpzSNRgQBAQKBMIEHgh8ICgEXED8NBRhQIxwBBBwCF4doDJhtoBiMCGgXgRSDHAOISIUDlX6BZoJ/gT8 X-IronPort-AV: E=Sophos;i="4.77,475,1336348800"; d="scan'208";a="50175239" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 26 Jun 2012 01:37:56 +0000 Received: from dwingWS (sjc-vpn2-154.cisco.com [10.21.112.154]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q5Q1bupZ000746; Tue, 26 Jun 2012 01:37:56 GMT From: "Dan Wing" To: Date: Mon, 25 Jun 2012 18:37:56 -0700 Message-ID: <04a001cd533c$4fcef9c0$ef6ced40$@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: Ac1TPE+Hh9gQ6bk/RnavYRn9Ps7TNQ== Content-Language: en-us Cc: behave-chairs@tools.ietf.org Subject: [BEHAVE] minutes for June 21 interim meeting 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, 26 Jun 2012 01:37:57 -0000 Thanks to Senthil for taking notes. Minutes are now at: http://www.ietf.org/proceedings/interim/2012/06/21/behave/minutes/minutes-in terim-2012-behave-4 Please email me any corrections. -d From teemu.savolainen@nokia.com Tue Jun 26 07:20:37 2012 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 56D4321F8631 for ; Tue, 26 Jun 2012 07:20:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 N7JQhBfN6Xio for ; Tue, 26 Jun 2012 07:20:36 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 3036121F860B for ; Tue, 26 Jun 2012 07:20:36 -0700 (PDT) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-da02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q5QEJuh0022910; Tue, 26 Jun 2012 17:20:30 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.61]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 26 Jun 2012 17:19:57 +0300 Received: from 008-AM1MPN1-052.mgdnok.nokia.com ([169.254.2.174]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi id 14.02.0283.004; Tue, 26 Jun 2012 16:19:49 +0200 From: To: , , Thread-Topic: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09 Thread-Index: AQHNTa6WlGX//ByshEqwAxlmPJbl9JcLlDUQgAEbFmA= Date: Tue, 26 Jun 2012 14:19:48 +0000 Message-ID: <916CE6CF87173740BC8A2CE443096962043BE42D@008-AM1MPN1-052.mgdnok.nokia.com> References: <9B57C850BB53634CACEC56EF4853FF653B62BDA4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B66483D@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <96DD85EB136DCD49AB5CDB6DEC9639AD068597EA@CH1PRD0310MB368.namprd03.prod.outlook.com> In-Reply-To: <96DD85EB136DCD49AB5CDB6DEC9639AD068597EA@CH1PRD0310MB368.namprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.163.25.64] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 26 Jun 2012 14:19:57.0331 (UTC) FILETIME=[C3812630:01CD53A6] X-Nokia-AV: Clean Subject: Re: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09 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, 26 Jun 2012 14:20:37 -0000 Hi, > >>The implementation SHOULD support mapping of separate IPv4 address > ranges to separate IPv6 prefixes for AAAA record synthesis. This > allows handling of special use IPv4 addresses [RFC5735]. >=20 > In case the DNS64 in the network is configured with several such (IPv4 > address range)->(IPv6 prefix) mappings, how a host using the proposed > heuristic can discover all such mappings? (without them, it seems the hos= t > would not be able to perform IPv6 address synthesis correctly for all pos= sible > IPv4 addresses the network DNS64 would be able to). >=20 > Or is there something that makes the heuristic work even without discover= y of > all the mappings? The more interesting question perhaps is what this draft should say about s= ynthesis... It is now (in latest under-work version) saying only that all P= ref64::/n should be used in synthesis, but it is not stating ANYTHING about= what IPv4 addresses can be used in the synthesis. I was actually thinking = to leave that part out of this prefix discovery draft. But basically a node implementing DNS64 by itself would just not implement = that "SHOULD", because the node has no information about mapping data.=20 Best regards, Teemu From iesg-secretary@ietf.org Tue Jun 26 09:59:17 2012 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 0FF9811E808A; Tue, 26 Jun 2012 09:59:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.534 X-Spam-Level: X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.065, 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 F8SJnzrAPv2H; Tue, 26 Jun 2012 09:59:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DB9121F855B; Tue, 26 Jun 2012 09:59:16 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.21 Message-ID: <20120626165916.5977.72045.idtracker@ietfa.amsl.com> Date: Tue, 26 Jun 2012 09:59:16 -0700 Cc: behave@ietf.org Subject: [BEHAVE] Last Call: (Common requirements for Carrier Grade NATs (CGNs)) to Best Current Practice X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 16:59:17 -0000 The IESG has received a request from the Behavior Engineering for Hindrance Avoidance WG (behave) to consider the following document: - 'Common requirements for Carrier Grade NATs (CGNs)' as Best Current Practice The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-07-10. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines common requirements for Carrier-Grade NAT (CGN). It updates RFC 4787. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-behave-lsn-requirements/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-behave-lsn-requirements/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1648/ From Dmitry.Anipko@microsoft.com Tue Jun 26 11:19:20 2012 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 E789D21F852D for ; Tue, 26 Jun 2012 11:19:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.967 X-Spam-Level: X-Spam-Status: No, score=-1.967 tagged_above=-999 required=5 tests=[AWL=1.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] 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 U50sIosNlrP8 for ; Tue, 26 Jun 2012 11:19:20 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe002.messaging.microsoft.com [65.55.88.12]) by ietfa.amsl.com (Postfix) with ESMTP id E7E4521F846B for ; Tue, 26 Jun 2012 11:19:19 -0700 (PDT) Received: from mail151-tx2-R.bigfish.com (10.9.14.248) by TX2EHSOBE002.bigfish.com (10.9.40.22) with Microsoft SMTP Server id 14.1.225.23; Tue, 26 Jun 2012 18:17:37 +0000 Received: from mail151-tx2 (localhost [127.0.0.1]) by mail151-tx2-R.bigfish.com (Postfix) with ESMTP id AD69240227 for ; Tue, 26 Jun 2012 18:17:37 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -28 X-BigFish: VS-28(zz9371I542M1432I4015Izz1202hzz1033IL8275bh8275dhz2fh2a8h683h839h944hd25hf0ah) Received-SPF: pass (mail151-tx2: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Dmitry.Anipko@microsoft.com; helo=TK5EX14HUBC102.redmond.corp.microsoft.com ; icrosoft.com ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.244.37; KIP:(null); UIP:(null); (null); H:CH1PRD0310HT001.namprd03.prod.outlook.com; R:internal; EFV:INT Received: from mail151-tx2 (localhost.localdomain [127.0.0.1]) by mail151-tx2 (MessageSwitch) id 1340734656180153_19189; Tue, 26 Jun 2012 18:17:36 +0000 (UTC) Received: from TX2EHSMHS033.bigfish.com (unknown [10.9.14.238]) by mail151-tx2.bigfish.com (Postfix) with ESMTP id 201C7320047 for ; Tue, 26 Jun 2012 18:17:36 +0000 (UTC) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS033.bigfish.com (10.9.99.133) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 26 Jun 2012 18:17:35 +0000 Received: from am1outboundpool.messaging.microsoft.com (157.54.51.114) by mail.microsoft.com (157.54.7.154) with Microsoft SMTP Server (TLS) id 14.2.309.3; Tue, 26 Jun 2012 18:19:14 +0000 Received: from mail63-am1-R.bigfish.com (10.3.201.247) by AM1EHSOBE004.bigfish.com (10.3.204.24) with Microsoft SMTP Server id 14.1.225.23; Tue, 26 Jun 2012 18:17:31 +0000 Received: from mail63-am1 (localhost [127.0.0.1]) by mail63-am1-R.bigfish.com (Postfix) with ESMTP id 82DA720024C for ; Tue, 26 Jun 2012 18:17:30 +0000 (UTC) Received: from mail63-am1 (localhost.localdomain [127.0.0.1]) by mail63-am1 (MessageSwitch) id 134073464995476_31318; Tue, 26 Jun 2012 18:17:29 +0000 (UTC) Received: from AM1EHSMHS015.bigfish.com (unknown [10.3.201.237]) by mail63-am1.bigfish.com (Postfix) with ESMTP id 0BB0942004A; Tue, 26 Jun 2012 18:17:29 +0000 (UTC) Received: from CH1PRD0310HT001.namprd03.prod.outlook.com (157.56.244.37) by AM1EHSMHS015.bigfish.com (10.3.207.153) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 26 Jun 2012 18:17:28 +0000 Received: from CH1PRD0310MB368.namprd03.prod.outlook.com ([169.254.8.166]) by CH1PRD0310HT001.namprd03.prod.outlook.com ([10.255.137.36]) with mapi id 14.16.0164.004; Tue, 26 Jun 2012 18:19:03 +0000 From: Dmitry Anipko To: "teemu.savolainen@nokia.com" , Dave Thaler , "behave@ietf.org" Thread-Topic: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09 Thread-Index: AQHNU6dBHl1WqM4K4kyX71U7NkG1NpcM43Gw Date: Tue, 26 Jun 2012 18:19:02 +0000 Message-ID: <96DD85EB136DCD49AB5CDB6DEC9639AD0685BB90@CH1PRD0310MB368.namprd03.prod.outlook.com> References: <9B57C850BB53634CACEC56EF4853FF653B62BDA4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B66483D@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <96DD85EB136DCD49AB5CDB6DEC9639AD068597EA@CH1PRD0310MB368.namprd03.prod.outlook.com> <916CE6CF87173740BC8A2CE443096962043BE42D@008-AM1MPN1-052.mgdnok.nokia.com> In-Reply-To: <916CE6CF87173740BC8A2CE443096962043BE42D@008-AM1MPN1-052.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.192.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: CH1PRD0310HT001.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%NOKIA.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14HUBC102.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC102.redmond.corp.microsoft.com X-OriginatorOrg: microsoft.com Subject: Re: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09 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, 26 Jun 2012 18:19:21 -0000 >> The more interesting question perhaps is what this draft should say abou= t synthesis... It is now (in latest under-work version) saying only that al= l Pref64::/n should be used in synthesis, but it is not stating ANYTHING ab= out what IPv4 addresses can be used in the synthesis. I think essentially it is the same question - without some additional knowl= edge (such as e.g. of range->prefix mappings), the host can't answer either= of the questions correctly (either how to synthesize IPv6 based on given I= Pv4, or whether to synthesize IPv6 for a given IPv4). >> I was actually thinking to leave that part out of this prefix discovery = draft....But basically a node implementing DNS64 by itself would just not i= mplement that "SHOULD", because the node has no information about mapping d= ata. I'm not sure that would be sufficient - the node then still could synthesiz= e IPv6 incorrectly, and that could lead to added connectivity issues (IPv6 = connection timeouts), not present without DNS64 function in the node, as we= ll as to unanticipated effects on the network NAT64 device (increased error= reporting, unanticipated traffic load, etc.). Or perhaps I misunderstood w= hat you meant with "not implement"? If the current text is standardized as is, then IMO we can end up in a some= what strange situation where two entities following two standards, which we= re meant to work together, actually don't always interoperate. A couple of = things that could be done to mitigate/address that:=20 1. Say in the draft-ietf-behave-nat64-discovery-heuristic that it doesn't w= ork with network DNS64s configured with different IPv6 prefixes for differe= nt IPv4 ranges. (and then it would make sense to change RFC6147 SHOULD to S= HOULD NOT for any addresses that are likely to be used on the wire) 2. Come up with a procedure, which operator of network DNS64 & node DNS64 c= ould use, if the network DNS64 is configured with such different prefixes, = to enable in-node DNS64 to learn the necessary information. Thanks, Dmitry -----Original Message----- From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of= teemu.savolainen@nokia.com Sent: Tuesday, June 26, 2012 7:20 AM To: Dmitry Anipko; Dave Thaler; behave@ietf.org Subject: Re: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristi= c-09 Hi, > >>The implementation SHOULD support mapping of separate IPv4 address > ranges to separate IPv6 prefixes for AAAA record synthesis. This > allows handling of special use IPv4 addresses [RFC5735]. >=20 > In case the DNS64 in the network is configured with several such (IPv4 > address range)->(IPv6 prefix) mappings, how a host using the proposed > heuristic can discover all such mappings? (without them, it seems the hos= t > would not be able to perform IPv6 address synthesis correctly for all pos= sible > IPv4 addresses the network DNS64 would be able to). >=20 > Or is there something that makes the heuristic work even without discover= y of > all the mappings? The more interesting question perhaps is what this draft should say about s= ynthesis... It is now (in latest under-work version) saying only that all P= ref64::/n should be used in synthesis, but it is not stating ANYTHING about= what IPv4 addresses can be used in the synthesis. I was actually thinking = to leave that part out of this prefix discovery draft. But basically a node implementing DNS64 by itself would just not implement = that "SHOULD", because the node has no information about mapping data.=20 Best regards, Teemu _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From teemu.savolainen@nokia.com Tue Jun 26 11:45:20 2012 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 8E78B11E80C8 for ; Tue, 26 Jun 2012 11:45:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 Y6B1OR2f8m5V for ; Tue, 26 Jun 2012 11:45:19 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 23BB511E809B for ; Tue, 26 Jun 2012 11:45:11 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (in-mx.nokia.com [10.160.244.32]) by mgw-da01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q5QIiwRj022522; Tue, 26 Jun 2012 21:45:06 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.24]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 26 Jun 2012 21:45:13 +0300 Received: from 008-AM1MPN1-052.mgdnok.nokia.com ([169.254.2.174]) by 008-AM1MMR1-008.mgdnok.nokia.com ([65.54.30.24]) with mapi id 14.02.0283.004; Tue, 26 Jun 2012 20:45:04 +0200 From: To: , , Thread-Topic: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09 Thread-Index: AQHNU8vMJW0v97C6d0anvYXMmpcItA== Date: Tue, 26 Jun 2012 18:45:04 +0000 Message-ID: <916CE6CF87173740BC8A2CE443096962043BE62F@008-AM1MPN1-052.mgdnok.nokia.com> References: <9B57C850BB53634CACEC56EF4853FF653B62BDA4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B66483D@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <96DD85EB136DCD49AB5CDB6DEC9639AD068597EA@CH1PRD0310MB368.namprd03.prod.outlook.com> <916CE6CF87173740BC8A2CE443096962043BE42D@008-AM1MPN1-052.mgdnok.nokia.com> <96DD85EB136DCD49AB5CDB6DEC9639AD0685BB90@CH1PRD0310MB368.namprd03.prod.outlook.com> In-Reply-To: <96DD85EB136DCD49AB5CDB6DEC9639AD0685BB90@CH1PRD0310MB368.namprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.163.25.64] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 26 Jun 2012 18:45:13.0203 (UTC) FILETIME=[D21A7C30:01CD53CB] X-Nokia-AV: Clean Subject: Re: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09 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, 26 Jun 2012 18:45:20 -0000 Hi, > I think essentially it is the same question - without some additional kno= wledge > (such as e.g. of range->prefix mappings), the host can't answer either of= the > questions correctly (either how to synthesize IPv6 based on given IPv4, o= r > whether to synthesize IPv6 for a given IPv4). In which case and from where the host would get special use IPv4 address li= terals? Being in IPv6-only access and encountering literal net10 addresses = in html?=20 I mean, in the common case host performs AAAA query for a name and it can g= et synthesized IPv6 address from DNS64 that has this mapping capability (an= d can return synthetic IPv6 address containing IPv4 address from special gr= oup). I would assume this would be the most common case. It is true that this would not work if the host gets a special use IPv4 add= ress literal from somewhere, but how common is that? I mean if the access network (enterprise, cellular, e.g.) would want their = IPv6-only hosts to access their IPv4-only devices that are numbered with sp= ecial use IPv4 addresses, why the said organization would not create AAAA r= ecords containing IPv6 addresses pointing to NAT64, or otherwise ensure the= ir IPv6-only hosts do not encounter these special use IPv4 address literals= ? Or the organization would ensure the packets flow correctly when hosts us= e discovered Pref64::/n in combination with special use addresses. > I'm not sure that would be sufficient - the node then still could synthes= ize IPv6 > incorrectly, and that could lead to added connectivity issues (IPv6 conne= ction > timeouts), not present without DNS64 function in the node, as well as to > unanticipated effects on the network NAT64 device (increased error > reporting, unanticipated traffic load, etc.). Or perhaps I misunderstood = what > you meant with "not implement"? If the node would get these special use IPv4 address literals and synthesiz= e based on those (but network is not prepared to for node to use discovered= Pref64::/n with those addresses), then sure, it would take a while for con= nection attempts to fail. But we have happy eyeballs:) > If the current text is standardized as is, then IMO we can end up in a > somewhat strange situation where two entities following two standards, > which were meant to work together, actually don't always interoperate. A > couple of things that could be done to mitigate/address that: Which entities do not interoperate?=20 > 1. Say in the draft-ietf-behave-nat64-discovery-heuristic that it doesn't= work > with network DNS64s configured with different IPv6 prefixes for different= IPv4 > ranges. (and then it would make sense to change RFC6147 SHOULD to > SHOULD NOT for any addresses that are likely to be used on the wire) It would work, if the NAT64 to which packets using discovered Pref64::/n ar= e routed can reach these special use addresses. I.e. maybe the routing woul= d not be as efficient as with the prefix network's DNS64 would've used for = these IPv4 ranges, but packets could flow nevertheless. I mean I don't understand the use case when different IPv6 prefix is needed= for different IPv4 ranges, unless for route optimization. And if the route= optimization is all that there is, then is there really a problem if some = packets do not follow the most optimal route? =20 > 2. Come up with a procedure, which operator of network DNS64 & node > DNS64 could use, if the network DNS64 is configured with such different > prefixes, to enable in-node DNS64 to learn the necessary information. This would require some sort of policy distribution mechanism, and the desi= gn requirement we had is that there must not be any DNS64 changes. In my opinion we can write a section about implications of special use IPv4= addresses and lack of support for specific IPv4 ranges, but state that iff= the host actually encounters these literals, and synthesizes IPv6 addresse= s with Pref64::/n, the network ought to be able to route packets correctly = nevertheless, and the host should provide graceful failure experience for t= he user (which the host anyway does, TCP SYNs can get lost anyway). Best regards, Teemu From petithug@acm.org Tue Jun 26 15:27:41 2012 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 5EE2111E809F for ; Tue, 26 Jun 2012 15:27:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.584 X-Spam-Level: X-Spam-Status: No, score=-102.584 tagged_above=-999 required=5 tests=[AWL=0.016, 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 3JAbvFIRyBFd for ; Tue, 26 Jun 2012 15:27:40 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 94D0311E808E for ; Tue, 26 Jun 2012 15:27:40 -0700 (PDT) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 100DF20442; Tue, 26 Jun 2012 22:27:37 +0000 (UTC) Message-ID: <4FEA3758.40203@acm.org> Date: Tue, 26 Jun 2012 15:27:36 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.5) Gecko/20120624 Icedove/10.0.5 MIME-Version: 1.0 To: teemu.savolainen@nokia.com References: <9B57C850BB53634CACEC56EF4853FF653B62BDA4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B66483D@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <4FE250F5.5010505@acm.org> <916CE6CF87173740BC8A2CE443096962043AF580@008-AM1MPN1-053.mgdnok.nokia.com> In-Reply-To: <916CE6CF87173740BC8A2CE443096962043AF580@008-AM1MPN1-053.mgdnok.nokia.com> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: behave@ietf.org, dthaler@microsoft.com Subject: Re: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09 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, 26 Jun 2012 22:27:41 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 06/21/2012 06:28 AM, teemu.savolainen@nokia.com wrote: > Thank you Marc for your review, responses inline: > >> -----Original Message----- From: behave-bounces@ietf.org >> [mailto:behave-bounces@ietf.org] On Behalf Of ext Marc Petit-Huguenin >> Sent: 21. kesäkuuta 2012 01:39 To: Dave Thaler Cc: behave@ietf.org >> Subject: Re: [BEHAVE] Last call: >> draft-ietf-behave-nat64-discovery-heuristic- 09 >> >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 >> >> On 06/18/2012 05:00 PM, Dave Thaler wrote: >>> So far I've seen 3 reviews: * Andrew Sullivan * Aaron Yi DING * Dave >>> Thaler >>> >>> We need at least 5 reviews on this document. Can we get two more >>> volunteers? Maybe Simon and/or Marc P.-H.? Anyone else? >>> >> [...] >> 3. Appendix A "nat64.example.org IN AAAA..." >> >> Why is that RR in the example? I cannot find in the normative text how >> this is used. Besides it seems malformed (IP address is 14 bytes long, >> and the "nat64.example.com." at the end of the line should be at the >> beginning of the the next line). > > The section 3.1.2 section 4 performs AAAA query for NAT64 FQDN. Would the > correct configuration be then: > > nat64.example.com. IN AAAA 2001:db8:0:0:0:0:0:0 nat64.example.com. IN A > 192.0.2.1 If it is only for DNSSEC, then the AAAA record is useless for a configuration that does not use DNSSEC, right? I found an additional small issue: 4. Section 3.2, 7th paragraph The text does not say how long an implementation should wait after sending the 3rd ICMPv6 packet before deciding that the Pref64:: is not functioning. FYI I published a partial implementation of this draft as free software: http://blog.marc.petit-huguenin.org/2012/06/nat64-discovery.html Thanks. - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJP6jdWAAoJECnERZXWan7E0E4P/Remto9fjiGgnvo4ARjoQGg3 YjEjDB1lFtAE/9hu9ZoGk3H+eCJutNFlJVFEFj03kjJSpDLxSZufkmqeWsOwvtJJ KdymBK+yQMWznjxXYieZr7uRrTXczTZJSZ8BXjSzNxfQPERfRWq7bGczfIex11J2 ZjDUVFaTWQZa4CFrBfrSynHdKjCHNrTrG1KiYfldP2cQ0R+siM0w4GSQaBvloV6C h7Dly2CYEV8+SZvao9M8i738cOQuHS7yAV5Sr6nNESybTem2CjiZgiQ3G3UHJGHi 9jtEmD2fqy5yL52+3hgP6n4d10g69jXaQH7OttzR0+YNY7gcY8+B2ejbz0wBcz0l zdQFP9jnbQGSoCEkjOmy1aARAQc1PrlOCqVRUVai0LtO0PUzmNxEcy25KT063VPb SkB4xI7qLTwIUhgc5LiSzu64Bmz7+Ko74x9tWi6lLV5Gp/4IzUsuJdgutxbbNjC2 /Gx/g7iRkGKQN0qgc3TvrXPmonCtPJxyATsgN3em0+NM3hq6Vn6TU1aTRW9DyS4r Oty0+QjIeEopq5RZr5UDhMHmLG8Y7szgdowJxVMFzRnlA+Bb9zz2LzV4Nt227Z/r o5PopPFdjXPDMEIcYOqF/ZEUxrKK8d0Qhb9/9kTXd69CCBMYnhBTVM4EDI2wpwa/ GM5MgW436ecXFp1maiU8 =aoyI -----END PGP SIGNATURE----- From teemu.savolainen@nokia.com Wed Jun 27 05:58:48 2012 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 6375221F86F0 for ; Wed, 27 Jun 2012 05:58:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 dGGgzBYfaYig for ; Wed, 27 Jun 2012 05:58:47 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 134F821F86E8 for ; Wed, 27 Jun 2012 05:58:46 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q5RCwdpi015573; Wed, 27 Jun 2012 15:58:39 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.25]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 27 Jun 2012 15:58:47 +0300 Received: from 008-AM1MPN1-052.mgdnok.nokia.com ([169.254.2.174]) by 008-AM1MMR1-009.mgdnok.nokia.com ([65.54.30.25]) with mapi id 14.02.0283.004; Wed, 27 Jun 2012 14:58:38 +0200 From: To: , , Thread-Topic: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09 Thread-Index: AQHNU8vMJW0v97C6d0anvYXMmpcItJcOIT1w Date: Wed, 27 Jun 2012 12:58:37 +0000 Message-ID: <916CE6CF87173740BC8A2CE443096962043BF2D0@008-AM1MPN1-052.mgdnok.nokia.com> References: <9B57C850BB53634CACEC56EF4853FF653B62BDA4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B66483D@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <96DD85EB136DCD49AB5CDB6DEC9639AD068597EA@CH1PRD0310MB368.namprd03.prod.outlook.com> <916CE6CF87173740BC8A2CE443096962043BE42D@008-AM1MPN1-052.mgdnok.nokia.com> <96DD85EB136DCD49AB5CDB6DEC9639AD0685BB90@CH1PRD0310MB368.namprd03.prod.outlook.com> <916CE6CF87173740BC8A2CE443096962043BE62F@008-AM1MPN1-052.mgdnok.nokia.com> In-Reply-To: <916CE6CF87173740BC8A2CE443096962043BE62F@008-AM1MPN1-052.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.163.16.98] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 27 Jun 2012 12:58:47.0513 (UTC) FILETIME=[9747A490:01CD5464] X-Nokia-AV: Clean Subject: Re: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09 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, 27 Jun 2012 12:58:48 -0000 Dmitry, how about following piece of text as new subsection: -- Mapping of IPv4 Address Ranges to IPv6 Prefixes The RFC 6147 [RFC6147] allows DNS64 implementations to be able to map specific IPv4 address ranges to separate Pref64::/n. That allows handling of special use IPv4 addresses [RFC5735]. The heuristic discovery method described herein does not support learning of the possible rules used by DNS64 server for mapping specific IPv4 address ranges to separate Pref64::/n. Therefore, nodes will use the same discovered Pref64::/n to synthesize IPv6 addresses out from any IPv4 address. The operator of the NAT64 and the DNS64 ought to take this into account in the network design and support routing, even if not optimal, of the packets nodes have synthesized by combining the discovered Pref64::/n and the IPv4 address nodes have learned via DNS or obtained as referrals. -- Best regards, Teemu > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf > Of Savolainen Teemu (Nokia-NRC/Tampere) > Sent: 26. kes=E4kuuta 2012 21:45 > To: Dmitry.Anipko@microsoft.com; dthaler@microsoft.com; behave@ietf.org > Subject: Re: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuris= tic- > 09 > > Hi, > > > I think essentially it is the same question - without some additional > > knowledge (such as e.g. of range->prefix mappings), the host can't > > answer either of the questions correctly (either how to synthesize > > IPv6 based on given IPv4, or whether to synthesize IPv6 for a given IPv= 4). > > In which case and from where the host would get special use IPv4 address > literals? Being in IPv6-only access and encountering literal net10 addres= ses in > html? > > I mean, in the common case host performs AAAA query for a name and it can > get synthesized IPv6 address from DNS64 that has this mapping capability > (and can return synthetic IPv6 address containing IPv4 address from speci= al > group). I would assume this would be the most common case. > > It is true that this would not work if the host gets a special use IPv4 a= ddress > literal from somewhere, but how common is that? > > I mean if the access network (enterprise, cellular, e.g.) would want thei= r IPv6- > only hosts to access their IPv4-only devices that are numbered with speci= al > use IPv4 addresses, why the said organization would not create AAAA recor= ds > containing IPv6 addresses pointing to NAT64, or otherwise ensure their IP= v6- > only hosts do not encounter these special use IPv4 address literals? Or t= he > organization would ensure the packets flow correctly when hosts use > discovered Pref64::/n in combination with special use addresses. > > > I'm not sure that would be sufficient - the node then still could > > synthesize IPv6 incorrectly, and that could lead to added connectivity > > issues (IPv6 connection timeouts), not present without DNS64 function > > in the node, as well as to unanticipated effects on the network NAT64 > > device (increased error reporting, unanticipated traffic load, etc.). > > Or perhaps I misunderstood what you meant with "not implement"? > > If the node would get these special use IPv4 address literals and synthes= ize > based on those (but network is not prepared to for node to use discovered > Pref64::/n with those addresses), then sure, it would take a while for > connection attempts to fail. But we have happy eyeballs:) > > > If the current text is standardized as is, then IMO we can end up in a > > somewhat strange situation where two entities following two standards, > > which were meant to work together, actually don't always interoperate. > > A couple of things that could be done to mitigate/address that: > > Which entities do not interoperate? > > > 1. Say in the draft-ietf-behave-nat64-discovery-heuristic that it > > doesn't work with network DNS64s configured with different IPv6 > > prefixes for different IPv4 ranges. (and then it would make sense to > > change RFC6147 SHOULD to SHOULD NOT for any addresses that are likely > > to be used on the wire) > > It would work, if the NAT64 to which packets using discovered Pref64::/n = are > routed can reach these special use addresses. I.e. maybe the routing woul= d > not be as efficient as with the prefix network's DNS64 would've used for = these > IPv4 ranges, but packets could flow nevertheless. > > I mean I don't understand the use case when different IPv6 prefix is need= ed > for different IPv4 ranges, unless for route optimization. And if the rout= e > optimization is all that there is, then is there really a problem if some= packets > do not follow the most optimal route? > > > 2. Come up with a procedure, which operator of network DNS64 & node > > DNS64 could use, if the network DNS64 is configured with such > > different prefixes, to enable in-node DNS64 to learn the necessary > information. > > This would require some sort of policy distribution mechanism, and the de= sign > requirement we had is that there must not be any DNS64 changes. > > In my opinion we can write a section about implications of special use IP= v4 > addresses and lack of support for specific IPv4 ranges, but state that if= f the > host actually encounters these literals, and synthesizes IPv6 addresses w= ith > Pref64::/n, the network ought to be able to route packets correctly > nevertheless, and the host should provide graceful failure experience for= the > user (which the host anyway does, TCP SYNs can get lost anyway). > > Best regards, > > Teemu > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From teemu.savolainen@nokia.com Wed Jun 27 06:07:05 2012 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 2F91A21F85D9 for ; Wed, 27 Jun 2012 06:07:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 gqEn2NA1+ohq for ; Wed, 27 Jun 2012 06:07:04 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 1138121F857A for ; Wed, 27 Jun 2012 06:07:03 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-da02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q5RD6lgc020929; Wed, 27 Jun 2012 16:07:00 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.60]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 27 Jun 2012 16:07:06 +0300 Received: from 008-AM1MPN1-052.mgdnok.nokia.com ([169.254.2.174]) by 008-AM1MMR1-005.mgdnok.nokia.com ([65.54.30.60]) with mapi id 14.02.0283.004; Wed, 27 Jun 2012 15:06:46 +0200 From: To: Thread-Topic: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09 Thread-Index: AQHNVGW0nV8ELkaGokCA2SiRbffcqQ== Date: Wed, 27 Jun 2012 13:06:46 +0000 Message-ID: <916CE6CF87173740BC8A2CE443096962043BF32C@008-AM1MPN1-052.mgdnok.nokia.com> References: <9B57C850BB53634CACEC56EF4853FF653B62BDA4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B66483D@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <4FE250F5.5010505@acm.org> <916CE6CF87173740BC8A2CE443096962043AF580@008-AM1MPN1-053.mgdnok.nokia.com> <4FEA3758.40203@acm.org> In-Reply-To: <4FEA3758.40203@acm.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.163.16.98] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 27 Jun 2012 13:07:06.0930 (UTC) FILETIME=[C0F4A120:01CD5465] X-Nokia-AV: Clean Cc: behave@ietf.org, dthaler@microsoft.com Subject: Re: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09 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, 27 Jun 2012 13:07:05 -0000 SGkgTWFyYywNCg0KQ29tbWVudHMgaW5saW5lOg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+IEZyb206IGV4dCBNYXJjIFBldGl0LUh1Z3VlbmluIFttYWlsdG86cGV0aXRodWdAYWNt Lm9yZ10NCj4gU2VudDogMjcuIGtlc8Oka3V1dGEgMjAxMiAwMToyOA0KPg0KPiA+IG5hdDY0LmV4 YW1wbGUuY29tLiBJTiBBQUFBICAyMDAxOmRiODowOjA6MDowOjA6MCBuYXQ2NC5leGFtcGxlLmNv bS4gSU4NCj4gPiBBDQo+ID4gMTkyLjAuMi4xDQo+IA0KPiBJZiBpdCBpcyBvbmx5IGZvciBETlNT RUMsIHRoZW4gdGhlIEFBQUEgcmVjb3JkIGlzIHVzZWxlc3MgZm9yIGEgY29uZmlndXJhdGlvbg0K PiB0aGF0IGRvZXMgbm90IHVzZSBETlNTRUMsIHJpZ2h0Pw0KDQpSaWdodC4gRm9yIEROU1NFQy1s ZXNzIGZ1bmN0aW9uIHRoZXJlJ3Mgbm8gbmVlZCBmb3IgQUFBQSByZWNvcmQgZm9yIE5BVDY0IEZR RE4uDQoNCj4gSSBmb3VuZCBhbiBhZGRpdGlvbmFsIHNtYWxsIGlzc3VlOg0KPiANCj4gNC4gU2Vj dGlvbiAzLjIsIDd0aCBwYXJhZ3JhcGgNCj4gDQo+IFRoZSB0ZXh0IGRvZXMgbm90IHNheSBob3cg bG9uZyBhbiBpbXBsZW1lbnRhdGlvbiBzaG91bGQgd2FpdCBhZnRlciBzZW5kaW5nDQo+IHRoZSAz cmQgSUNNUHY2IHBhY2tldCBiZWZvcmUgZGVjaWRpbmcgdGhhdCB0aGUgUHJlZjY0OjogaXMgbm90 IGZ1bmN0aW9uaW5nLg0KIA0KVGhlIGNvbm5lY3Rpdml0eSBjaGVjayBpcyBzdGFydGluZyB0byBi ZSBhIGxvbmcgbGFzdGluZyBwcm9jZWR1cmUgKDEgc2VjICsgMyBzZWMgKyBzb21ldGhpbmcpLi4g V2hpY2ggaXMgcHJldHR5IGxvbmcuIE1heWJlIHRoYXQgc2hvdWxkIGJlIHNxdWVlemVkIHRvIDEr MiszIHNlY29uZHM/IExpa2UgdGhpczoNCi0tDQpJZiBubyByZXNwb25zZSBpcyByZWNlaXZlZCBm b3IgdGhlIElDTVB2NiBFY2hvIFJlcXVlc3QsIHRoZSBub2RlIFNIQUxMIHNlbmQgYW5vdGhlciBJ Q01QdjYgRWNobyBSZXF1ZXN0LCBhIHNlY29uZCBsYXRlci4gIElmIHN0aWxsIG5vIHJlc3BvbnNl IGlzIHJlY2VpdmVkLCB0aGUgbm9kZSBTSEFMTCBzZW5kIGEgdGhpcmQgSUNNUHY2IEVjaG8gUmVx dWVzdCB0d28gc2Vjb25kcyBsYXRlci4gSWYgYW4gSUNNUHY2IEVjaG8gUmVzcG9uc2UgaXMgcmVj ZWl2ZWQsIHRoZSBub2RlIGtub3dzIHRoZSBJUHY2IHBhdGggdG8gdGhlIGNvbm5lY3Rpdml0eSBj aGVjayBzZXJ2ZXIgaXMgZnVuY3Rpb25pbmcgbm9ybWFsbHkuICBJZiwgYWZ0ZXIgdGhlIHRocmVl IHRyYW5zbWlzc2lvbnMgYW5kIHRocmVlIHNlY29uZHMgc2luY2UgdGhlIGxhc3QgSUNNUHY2IEVj aG8gUmVxdWVzdCwgbm8gcmVzcG9uc2UgaXMgcmVjZWl2ZWQsIHRoZSBub2RlIGxlYXJucyB0aGlz IFByZWY2NDo6L24gbWlnaHQgbm90IGJlIGZ1bmN0aW9uaW5nLi4uLi4NCi0tDQogDQo+IEZZSSBJ IHB1Ymxpc2hlZCBhIHBhcnRpYWwgaW1wbGVtZW50YXRpb24gb2YgdGhpcyBkcmFmdCBhcyBmcmVl IHNvZnR3YXJlOg0KPiANCj4gaHR0cDovL2Jsb2cubWFyYy5wZXRpdC1odWd1ZW5pbi5vcmcvMjAx Mi8wNi9uYXQ2NC1kaXNjb3ZlcnkuaHRtbA0KDQpUaGFuayB5b3UgZm9yIHRoaXMgd29yaywgd2Ug bm93IGhhdmUgYXQgbGVhc3QgdHdvIHBhcnRpYWwgaW1wbGVtZW50YXRpb25zICh0aGUgb25lIHdl IGRpZCBlYXJsaWVyIGFuZCBub3cgeW91cnMpLiBJIGRlZmluaXRlbHkgYWdyZWUgd2l0aCB5b3Ug dGhhdCBpbXBsZW1lbnRhdGlvbnMgYXJlIHRoZSBiZXN0IHdheSB0byByZXZpZXcgSS1EczopDQoN CkJlc3QgcmVnYXJkcywNCgkNCglUZWVtdQ0K From petithug@acm.org Wed Jun 27 07:05:16 2012 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 437C421F8733 for ; Wed, 27 Jun 2012 07:05:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.014, 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 sHDqOwFWXUBB for ; Wed, 27 Jun 2012 07:05:15 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 7747821F875D for ; Wed, 27 Jun 2012 07:05:15 -0700 (PDT) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 1D676204B8; Wed, 27 Jun 2012 14:05:12 +0000 (UTC) Message-ID: <4FEB1317.1080905@acm.org> Date: Wed, 27 Jun 2012 07:05:11 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.5) Gecko/20120624 Icedove/10.0.5 MIME-Version: 1.0 To: teemu.savolainen@nokia.com References: <9B57C850BB53634CACEC56EF4853FF653B62BDA4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B66483D@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <4FE250F5.5010505@acm.org> <916CE6CF87173740BC8A2CE443096962043AF580@008-AM1MPN1-053.mgdnok.nokia.com> <4FEA3758.40203@acm.org> <916CE6CF87173740BC8A2CE443096962043BF32C@008-AM1MPN1-052.mgdnok.nokia.com> In-Reply-To: <916CE6CF87173740BC8A2CE443096962043BF32C@008-AM1MPN1-052.mgdnok.nokia.com> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: behave@ietf.org, dthaler@microsoft.com Subject: Re: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09 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, 27 Jun 2012 14:05:16 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 06/27/2012 06:06 AM, teemu.savolainen@nokia.com wrote: > Hi Marc, > > Comments inline: > [...] > >> I found an additional small issue: >> >> 4. Section 3.2, 7th paragraph >> >> The text does not say how long an implementation should wait after >> sending the 3rd ICMPv6 packet before deciding that the Pref64:: is not >> functioning. > > The connectivity check is starting to be a long lasting procedure (1 sec + > 3 sec + something).. Which is pretty long. Maybe that should be squeezed > to 1+2+3 seconds? Like this: -- If no response is received for the ICMPv6 > Echo Request, the node SHALL send another ICMPv6 Echo Request, a second > later. If still no response is received, the node SHALL send a third > ICMPv6 Echo Request two seconds later. If an ICMPv6 Echo Response is > received, the node knows the IPv6 path to the connectivity check server is > functioning normally. If, after the three transmissions and three seconds > since the last ICMPv6 Echo Request, no response is received, the node > learns this Pref64::/n might not be functioning..... -- I am surprised that there is not already an RFC somewhere describing how to do connectivity checks with ICMP[v6]. Perhaps it would be simpler to reuse the rules used by STUN: https://tools.ietf.org/html/rfc5389#section-7.2.1 - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJP6xMVAAoJECnERZXWan7ECXYQAJi9/HqEB7/qjX+/iNrLKE1o tiPV8rBkWeLarr2o9+pekd3Gdyjoq7GJ7ZmuLmL+VAeoxq7hyufaI74XPpB10F6s 8+07RSKnqG/EZxZFJCVRaofFOcpbGNUA3amzNreUq0MyHO2XOo6510z21husVfjA SmCGaPR7Gdi4GONzh6crGHGUNfM+yE+fSSrqFIL7Y+vH7dKbDqeUdXeWiM0XU315 WozfgmqrcYBB80fKczFLFohcpUJTBOSA7p7U6vdq5SNQdf93CQLi7G/VZhWQzlC5 00BaH6lxZi86ofAvyS3EntXukVks+2V6no9WXfUikUr81e+PciUCQsmZldLNLyLi AJnAqiubPDba98AsnaFN7j+S3PF9YQw7gpL8xTADzEHyGCXdfaQaISpYkpKqQFUa +1aK9+VqaIJolX1EXHB2W9yBfn0ZkMizTdWWTyV2Ze9+q7d4RkesE6xdiiuGAnHO 8DdUqXYa72ZD+ASvsMoPiAdYyBHFNRASuzQIquxoBE7ELDdHgoiB7DvAVYiW3yus sWCZ0MBK75ccoR1nXYheflnNqFBQX3/DP1IEhrwsx/dRN2ZkPbD0BVsoDl6aIpko XLznwgCXg8mbxr0UxfjKjQ1EMjZaezQqsYsAzFvjO6zKIFYZY9oEO8PHUPMBeDJC d4Cd9DBLgAjTQYcL0G9V =6n6f -----END PGP SIGNATURE----- From stephan.lagerholm@secure64.com Wed Jun 27 08:08:16 2012 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 14D1321F862F for ; Wed, 27 Jun 2012 08:08:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.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 n55x5-B374A9 for ; Wed, 27 Jun 2012 08:08:15 -0700 (PDT) Received: from zimbra.secure64.com (unknown [64.92.221.189]) by ietfa.amsl.com (Postfix) with ESMTP id 43FD421F862B for ; Wed, 27 Jun 2012 08:08:15 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.secure64.com (Postfix) with ESMTP id 71962B8543; Wed, 27 Jun 2012 09:08:13 -0600 (MDT) X-Virus-Scanned: amavisd-new at secure64.com Received: from zimbra.secure64.com ([127.0.0.1]) by localhost (zimbra.secure64.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r8I7nuI+GNw6; Wed, 27 Jun 2012 09:08:11 -0600 (MDT) Received: from exchange.secure64.com (exchange.secure64.com [192.168.254.250]) by zimbra.secure64.com (Postfix) with ESMTPSA id E2175B84FD; Wed, 27 Jun 2012 09:08:10 -0600 (MDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=secure64.com; s=2010; t=1340809690; bh=Zb3g3ayUQ783M155+XbUOW2N1+Ujr7WwxmkUDWy/nfc=; h=MIME-Version:Content-Type:Content-Transfer-Encoding:Subject:Date: Message-ID:In-Reply-To:References:From:To:Cc; b=nK+p9IEpYIW+c5NiC7 3Sn1MGArIm4sRrfa+qNYSM8DA2i8kT34TYGpDqSLZGWVW4I5q/oG9dWTnpkulDB1oE+ swTv/uPh6otv4qHQgXjq7hmMwgLUdnSQypv5BALifAWL3gxSYNmMPuoYw6HJwZQS6yi e3LU2sRvqfyYZOa1uWA= Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 27 Jun 2012 09:07:39 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: In-Reply-To: <4FEB1317.1080905@acm.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] Last call:draft-ietf-behave-nat64-discovery-heuristic-09 Thread-Index: Ac1UbetLKUmkbJdgRrSTFK44llSv9wABtKnw References: <9B57C850BB53634CACEC56EF4853FF653B62BDA4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com><9B57C850BB53634CACEC56EF4853FF653B66483D@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com><4FE250F5.5010505@acm.org><916CE6CF87173740BC8A2CE443096962043AF580@008-AM1MPN1-053.mgdnok.nokia.com><4FEA3758.40203@acm.org><916CE6CF87173740BC8A2CE443096962043BF32C@008-AM1MPN1-052.mgdnok.nokia.com> <4FEB1317.1080905@acm.org> From: "Stephan Lagerholm" To: "Marc Petit-Huguenin" , Cc: behave@ietf.org, dthaler@microsoft.com Subject: Re: [BEHAVE] Last call:draft-ietf-behave-nat64-discovery-heuristic-09 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, 27 Jun 2012 15:08:16 -0000 Hi Teemu and Marc, > >> I found an additional small issue: > >> > >> 4. Section 3.2, 7th paragraph > >> > >> The text does not say how long an implementation should wait after > >> sending the 3rd ICMPv6 packet before deciding that the Pref64:: is > >> not functioning. > > > > The connectivity check is starting to be a long lasting procedure (1 > > sec + > > 3 sec + something).. Which is pretty long. Maybe that should be > > squeezed to 1+2+3 seconds? Like this: -- If no response is received > > for the ICMPv6 Echo Request, the node SHALL send another ICMPv6 Echo > > Request, a second later. If still no response is received, the node > > SHALL send a third > > ICMPv6 Echo Request two seconds later. If an ICMPv6 Echo Response is > > received, the node knows the IPv6 path to the connectivity check > > server is functioning normally. If, after the three transmissions and > > three seconds since the last ICMPv6 Echo Request, no response is > > received, the node learns this Pref64::/n might not be > > functioning..... -- >=20 > I am surprised that there is not already an RFC somewhere describing > how to do connectivity checks with ICMP[v6]. Perhaps it would be > simpler to reuse the rules used by STUN: >=20 > https://tools.ietf.org/html/rfc5389#section-7.2.1 I agree with Marc, there has to be some standardized way of doing those checks should they be needed. However, I'm not so sure that the are needed. RFC6147 is not requiring the DNS64 server to perform any connectivity checks. Does it really add any value to do those types of checks for client learning the prefix? /Stephan From teemu.savolainen@nokia.com Wed Jun 27 11:35:04 2012 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 742D521F8753 for ; Wed, 27 Jun 2012 11:35:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 eBwq7ReMmN7A for ; Wed, 27 Jun 2012 11:34:59 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id BCF9D21F874A for ; Wed, 27 Jun 2012 11:34:58 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q5RIYkOE016064; Wed, 27 Jun 2012 21:34:47 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.60]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 27 Jun 2012 21:34:54 +0300 Received: from 008-AM1MPN1-052.mgdnok.nokia.com ([169.254.2.174]) by 008-AM1MMR1-005.mgdnok.nokia.com ([65.54.30.60]) with mapi id 14.02.0283.004; Wed, 27 Jun 2012 20:34:46 +0200 From: To: Thread-Topic: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09 Thread-Index: AQHNVGW0nV8ELkaGokCA2SiRbffcqZcOEWiAgABrVvA= Date: Wed, 27 Jun 2012 18:34:45 +0000 Message-ID: <916CE6CF87173740BC8A2CE443096962043BF6A2@008-AM1MPN1-052.mgdnok.nokia.com> References: <9B57C850BB53634CACEC56EF4853FF653B62BDA4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B66483D@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <4FE250F5.5010505@acm.org> <916CE6CF87173740BC8A2CE443096962043AF580@008-AM1MPN1-053.mgdnok.nokia.com> <4FEA3758.40203@acm.org> <916CE6CF87173740BC8A2CE443096962043BF32C@008-AM1MPN1-052.mgdnok.nokia.com> <4FEB1317.1080905@acm.org> In-Reply-To: <4FEB1317.1080905@acm.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.163.16.98] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 27 Jun 2012 18:34:54.0965 (UTC) FILETIME=[8C049A50:01CD5493] X-Nokia-AV: Clean Cc: behave@ietf.org, dthaler@microsoft.com Subject: Re: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09 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, 27 Jun 2012 18:35:04 -0000 PiBJIGFtIHN1cnByaXNlZCB0aGF0IHRoZXJlIGlzIG5vdCBhbHJlYWR5IGFuIFJGQyBzb21ld2hl cmUgZGVzY3JpYmluZyBob3cgdG8NCj4gZG8gY29ubmVjdGl2aXR5IGNoZWNrcyB3aXRoIElDTVBb djZdLiAgUGVyaGFwcyBpdCB3b3VsZCBiZSBzaW1wbGVyIHRvIHJldXNlDQo+IHRoZSBydWxlcyB1 c2VkIGJ5IFNUVU46DQo+DQo+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1Mzg5I3Nl Y3Rpb24tNy4yLjENCg0KVGhhdCBzb3VuZHMgbW9yZSBjb21wbGV4IC8gb3ZlcmtpbGwgZm9yIG1l Li4gV2hhdCBiZW5lZml0IGRvZXMgdGhhdCBjb21wbGV4IFJUTyBlc3RpbWF0aW9uIGdpdmUgaGVy ZT8NCg0KSWYgd2UnZCB1c2UgZml4ZWQgaW5pdGlhbCB2YWx1ZSBvZiAxcyBmb3IgUlRPLCBhbmQg dGhlbiBkZWZpbmUgUmMgdG8gYmUgZS5nLiA3LCBhbmQgaGF2ZSBmaW5hbCAiUm0iIGxpa2UgMyAo c2Vjb25kcyksIGlzbid0IHRoYXQgY2xvc2UgZW5vdWdoPyBUaGF0IHdvdWxkIHJlc3VsdCBpbiAx MCBzZWNvbmRzIHVudGlsIGZhaWx1cmU/DQoNCkJlc3QgcmVnYXJkcywNCg0KVGVlbXUNCg0KDQoN Cg== From teemu.savolainen@nokia.com Wed Jun 27 11:39:43 2012 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 40A3821F8771 for ; Wed, 27 Jun 2012 11:39:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 2LgvrMLc331l for ; Wed, 27 Jun 2012 11:39:42 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 8478E21F8773 for ; Wed, 27 Jun 2012 11:39:41 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (in-mx.nokia.com [10.160.244.31]) by mgw-da02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q5RIdY8o001494; Wed, 27 Jun 2012 21:39:37 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.21]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 27 Jun 2012 21:39:45 +0300 Received: from 008-AM1MPN1-052.mgdnok.nokia.com ([169.254.2.174]) by 008-AM1MMR1-012.mgdnok.nokia.com ([65.54.30.21]) with mapi id 14.02.0283.004; Wed, 27 Jun 2012 20:39:36 +0200 From: To: , Thread-Topic: [BEHAVE] Last call:draft-ietf-behave-nat64-discovery-heuristic-09 Thread-Index: Ac1UbetLKUmkbJdgRrSTFK44llSv9wABtKnwAAe08kA= Date: Wed, 27 Jun 2012 18:39:35 +0000 Message-ID: <916CE6CF87173740BC8A2CE443096962043BF6B7@008-AM1MPN1-052.mgdnok.nokia.com> References: <9B57C850BB53634CACEC56EF4853FF653B62BDA4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com><9B57C850BB53634CACEC56EF4853FF653B66483D@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com><4FE250F5.5010505@acm.org><916CE6CF87173740BC8A2CE443096962043AF580@008-AM1MPN1-053.mgdnok.nokia.com><4FEA3758.40203@acm.org><916CE6CF87173740BC8A2CE443096962043BF32C@008-AM1MPN1-052.mgdnok.nokia.com> <4FEB1317.1080905@acm.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.163.16.98] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 27 Jun 2012 18:39:45.0021 (UTC) FILETIME=[38E7A2D0:01CD5494] X-Nokia-AV: Clean Cc: behave@ietf.org, dthaler@microsoft.com Subject: Re: [BEHAVE] Last call:draft-ietf-behave-nat64-discovery-heuristic-09 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, 27 Jun 2012 18:39:43 -0000 > I agree with Marc, there has to be some standardized way of doing those > checks should they be needed. However, I'm not so sure that the are neede= d. > RFC6147 is not requiring the DNS64 server to perform any connectivity > checks. Does it really add any value to do those types of checks for cli= ent > learning the prefix? That has been under debate - one way indeed would be to drop the whole conn= ectivity check section. If the connectivity check fails, the node will anyway be in doubt whether i= t is just the connectivity check that doesn't work... and just using the Pr= ef64::/n would actually yield in working system. Hence node might anyway go= forward using the discovered Pref64::/n (as the only alternative would be = no connection for sure). For diagnostic purposes (and faster error recoveri= es) the connectivity test failure might give a hint that problem could be i= n prefix discovery (or NAT64 system in general). Without connectivity check defined here, the nodes would either just use th= e Pref64::/n and maybe see connections not working with synthetic addresses= , and/or implementations could just choose to (not) have their proprietary = connection check systems like today. I.e. we could separate the connectivity check out from here, if wanted to b= e so. Best regards, Teemu From petithug@acm.org Wed Jun 27 15:14:39 2012 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 2952721F8655 for ; Wed, 27 Jun 2012 15:14:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.013, 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 UaFlQpnZquCK for ; Wed, 27 Jun 2012 15:14:38 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 7E41821F8593 for ; Wed, 27 Jun 2012 15:14:36 -0700 (PDT) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 7E3C7204B8; Wed, 27 Jun 2012 22:14:34 +0000 (UTC) Message-ID: <4FEB85C7.20903@acm.org> Date: Wed, 27 Jun 2012 15:14:31 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.5) Gecko/20120624 Icedove/10.0.5 MIME-Version: 1.0 To: teemu.savolainen@nokia.com References: <9B57C850BB53634CACEC56EF4853FF653B62BDA4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B66483D@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <4FE250F5.5010505@acm.org> <916CE6CF87173740BC8A2CE443096962043AF580@008-AM1MPN1-053.mgdnok.nokia.com> <4FEA3758.40203@acm.org> <916CE6CF87173740BC8A2CE443096962043BF32C@008-AM1MPN1-052.mgdnok.nokia.com> <4FEB1317.1080905@acm.org> <916CE6CF87173740BC8A2CE443096962043BF6A2@008-AM1MPN1-052.mgdnok.nokia.com> In-Reply-To: <916CE6CF87173740BC8A2CE443096962043BF6A2@008-AM1MPN1-052.mgdnok.nokia.com> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: behave@ietf.org, dthaler@microsoft.com Subject: Re: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09 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, 27 Jun 2012 22:14:39 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 06/27/2012 11:34 AM, teemu.savolainen@nokia.com wrote: >> I am surprised that there is not already an RFC somewhere describing how >> to do connectivity checks with ICMP[v6]. Perhaps it would be simpler to >> reuse the rules used by STUN: >> >> https://tools.ietf.org/html/rfc5389#section-7.2.1 > > That sounds more complex / overkill for me.. What benefit does that complex > RTO estimation give here? > > If we'd use fixed initial value of 1s for RTO, and then define Rc to be > e.g. 7, and have final "Rm" like 3 (seconds), isn't that close enough? That > would result in 10 seconds until failure? > My point was that an existing algorithm should be used, instead of designing a new one. But I thought a little bit more about this and I agree with Simon that using ICMPv6 as the baseline connectivity check is not a good idea, but for a different reason: Most of the code that would need to synthesize IPv6 addresses will run in applications. But sending ICMPv6 packets requires root (or something equivalent) and that's generally a bad idea for an application. So my preference would be to have a baseline connectivity protocol that does not require root. It can be STUN, or a TCP connection to port 7, or a UDP connection to port 7 with a retransmission algorithm identical to the STUN - I do not really care, but the draft must mandate one, and must mandate that this baseline protocol is active on the hostname if a PTR RR is installed. After this it is always possible to define a S-NAPTR application to publish the other connectivity protocols available at the hostname in the PTR RR. - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJP64WLAAoJECnERZXWan7Er7EQAKXxO5BaOMJMpdQySkHlq/2p 4oPyISxTxlYeGOcQhZheInCb5IYw+2BbeTfLTAau54LuEpCyUI9MHCah5b4k7vn4 WsHl44UJ2gc5cI58r6snsipv2j6+Jltmg1k+JntJoNXwhChZMuu7gkKoZRvXIclk C3kt2Rv8ghRsXZ+3j1DLNNjDLr/8+35GPA47kvIc/8J3dPjUUuVT9S94VMxCuamL vChbZ1tPKyeJlNBqB6BfV0k0rmgODBByDvA+Y8wH1paEGLtL5qu6waWjYNpFwcsX eD9vkabnI6/mQX1dwpdHfjnSvDP8Zitq5mMlqRhpO1ul07tqzdJRgBbdrrwHGJbl N+/ahuGHO1nuCOF7RTbRW1G/VbnZL80NSM+ZyiaodrxhLDtSG2e6Ru7Cc8OcRNLy I0UWwQiYFqm3UARccBr0lwTTDed9rHoNi1vjtR+DAohf7ZepIxQveA2P7eBBJ9vY s5bkRVm8YyS2xkU+Eyz7xjS4JbJVgLE3iC2gvjDmpEhe2DDHIEWVF48tsSVnW6w3 ukBnawn16osAGabiaO4gBy01XGnJXDDug5rtQE8DvQsZk77uwsaWmWVtMstPCTYx U7Rty4WfUYTBK/WGlWFX8QVbNfKzvFesyD00wg1/2R6uUmLAMVmohzMvXYmiEHeP dq/axJALGsDchu0th9WG =HUMl -----END PGP SIGNATURE----- From dthaler@microsoft.com Wed Jun 27 15:22:54 2012 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 779B421F85D1 for ; Wed, 27 Jun 2012 15:22:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.738 X-Spam-Level: X-Spam-Status: No, score=-103.738 tagged_above=-999 required=5 tests=[AWL=-0.139, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 V7MBhCyRg8Uk for ; Wed, 27 Jun 2012 15:22:51 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe003.messaging.microsoft.com [216.32.180.13]) by ietfa.amsl.com (Postfix) with ESMTP id 22C6621F85D0 for ; Wed, 27 Jun 2012 15:22:51 -0700 (PDT) Received: from mail207-va3-R.bigfish.com (10.7.14.254) by VA3EHSOBE012.bigfish.com (10.7.40.62) with Microsoft SMTP Server id 14.1.225.23; Wed, 27 Jun 2012 22:21:06 +0000 Received: from mail207-va3 (localhost [127.0.0.1]) by mail207-va3-R.bigfish.com (Postfix) with ESMTP id 28D3D4013D; Wed, 27 Jun 2012 22:21:06 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC105.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -38 X-BigFish: VS-38(zzbb2dI98dI154cP9371I542M1432I62a3Izz1202hzz1033IL8275bh8275dhz2fh2a8h668h839h93fhd25hf0ah) Received-SPF: pass (mail207-va3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14HUBC105.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail207-va3 (localhost.localdomain [127.0.0.1]) by mail207-va3 (MessageSwitch) id 1340835663723040_24778; Wed, 27 Jun 2012 22:21:03 +0000 (UTC) Received: from VA3EHSMHS032.bigfish.com (unknown [10.7.14.241]) by mail207-va3.bigfish.com (Postfix) with ESMTP id A440B2C0046; Wed, 27 Jun 2012 22:21:03 +0000 (UTC) Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS032.bigfish.com (10.7.99.42) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 27 Jun 2012 22:20:59 +0000 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC105.redmond.corp.microsoft.com (157.54.80.48) with Microsoft SMTP Server (TLS) id 14.2.309.3; Wed, 27 Jun 2012 22:22:42 +0000 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) with Microsoft SMTP Server (TLS) id 14.2.309.3; Wed, 27 Jun 2012 15:22:41 -0700 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.28]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.02.0309.003; Wed, 27 Jun 2012 15:22:41 -0700 From: Dave Thaler To: Marc Petit-Huguenin , "teemu.savolainen@nokia.com" Thread-Topic: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09 Thread-Index: AQHNU+roac7A8BLN7kWYPxjnPZyC9JcOmOsAgAAQU4CAAEtRgIAAPWeA//+MSMA= Date: Wed, 27 Jun 2012 22:22:41 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B67BCAB@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> References: <9B57C850BB53634CACEC56EF4853FF653B62BDA4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B66483D@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <4FE250F5.5010505@acm.org> <916CE6CF87173740BC8A2CE443096962043AF580@008-AM1MPN1-053.mgdnok.nokia.com> <4FEA3758.40203@acm.org> <916CE6CF87173740BC8A2CE443096962043BF32C@008-AM1MPN1-052.mgdnok.nokia.com> <4FEB1317.1080905@acm.org> <916CE6CF87173740BC8A2CE443096962043BF6A2@008-AM1MPN1-052.mgdnok.nokia.com> <4FEB85C7.20903@acm.org> In-Reply-To: <4FEB85C7.20903@acm.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.90] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "behave@ietf.org" Subject: Re: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09 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, 27 Jun 2012 22:22:54 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBNYXJjIFBldGl0LUh1Z3Vlbmlu IFttYWlsdG86cGV0aXRodWdAYWNtLm9yZ10NCj4gU2VudDogV2VkbmVzZGF5LCBKdW5lIDI3LCAy MDEyIDM6MTUgUE0NCj4gVG86IHRlZW11LnNhdm9sYWluZW5Abm9raWEuY29tDQo+IENjOiBEYXZl IFRoYWxlcjsgYmVoYXZlQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbQkVIQVZFXSBMYXN0IGNh bGw6IGRyYWZ0LWlldGYtYmVoYXZlLW5hdDY0LWRpc2NvdmVyeS1oZXVyaXN0aWMtDQo+IDA5DQo+ IA0KPiAtLS0tLUJFR0lOIFBHUCBTSUdORUQgTUVTU0FHRS0tLS0tDQo+IEhhc2g6IFNIQTI1Ng0K PiANCj4gT24gMDYvMjcvMjAxMiAxMTozNCBBTSwgdGVlbXUuc2F2b2xhaW5lbkBub2tpYS5jb20g d3JvdGU6DQo+ID4+IEkgYW0gc3VycHJpc2VkIHRoYXQgdGhlcmUgaXMgbm90IGFscmVhZHkgYW4g UkZDIHNvbWV3aGVyZSBkZXNjcmliaW5nDQo+ID4+IGhvdyB0byBkbyBjb25uZWN0aXZpdHkgY2hl Y2tzIHdpdGggSUNNUFt2Nl0uICBQZXJoYXBzIGl0IHdvdWxkIGJlDQo+ID4+IHNpbXBsZXIgdG8g cmV1c2UgdGhlIHJ1bGVzIHVzZWQgYnkgU1RVTjoNCj4gPj4NCj4gPj4gaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL3JmYzUzODkjc2VjdGlvbi03LjIuMQ0KPiA+DQo+ID4gVGhhdCBzb3VuZHMg bW9yZSBjb21wbGV4IC8gb3ZlcmtpbGwgZm9yIG1lLi4gV2hhdCBiZW5lZml0IGRvZXMgdGhhdA0K PiA+IGNvbXBsZXggUlRPIGVzdGltYXRpb24gZ2l2ZSBoZXJlPw0KPiA+DQo+ID4gSWYgd2UnZCB1 c2UgZml4ZWQgaW5pdGlhbCB2YWx1ZSBvZiAxcyBmb3IgUlRPLCBhbmQgdGhlbiBkZWZpbmUgUmMg dG8NCj4gPiBiZSBlLmcuIDcsIGFuZCBoYXZlIGZpbmFsICJSbSIgbGlrZSAzIChzZWNvbmRzKSwg aXNuJ3QgdGhhdCBjbG9zZQ0KPiA+IGVub3VnaD8gVGhhdCB3b3VsZCByZXN1bHQgaW4gMTAgc2Vj b25kcyB1bnRpbCBmYWlsdXJlPw0KPiA+DQo+IA0KPiBNeSBwb2ludCB3YXMgdGhhdCBhbiBleGlz dGluZyBhbGdvcml0aG0gc2hvdWxkIGJlIHVzZWQsIGluc3RlYWQgb2YgZGVzaWduaW5nDQo+IGEg bmV3IG9uZS4NCg0KUGluZyBpc24ndCBhIG5ldyBhbGdvcml0aG0uDQoNCj4gQnV0IEkgdGhvdWdo dCBhIGxpdHRsZSBiaXQgbW9yZSBhYm91dCB0aGlzIGFuZCBJIGFncmVlIHdpdGggU2ltb24gdGhh dCB1c2luZw0KPiBJQ01QdjYgYXMgdGhlIGJhc2VsaW5lIGNvbm5lY3Rpdml0eSBjaGVjayBpcyBu b3QgYSBnb29kIGlkZWEsIGJ1dCBmb3IgYQ0KPiBkaWZmZXJlbnQgcmVhc29uOiAgTW9zdCBvZiB0 aGUgY29kZSB0aGF0IHdvdWxkIG5lZWQgdG8gc3ludGhlc2l6ZSBJUHY2DQo+IGFkZHJlc3NlcyB3 aWxsIHJ1biBpbiBhcHBsaWNhdGlvbnMuDQoNCkxlZ2l0aW1hdGUgcXVlc3Rpb246IERvIHlvdSBo YXZlIGRhdGEgdG8gc3VwcG9ydCB0aGF0ICgibW9zdCIpPw0KDQo+IEJ1dCBzZW5kaW5nIElDTVB2 NiBwYWNrZXRzIHJlcXVpcmVzIHJvb3QNCj4gKG9yIHNvbWV0aGluZyBlcXVpdmFsZW50KSBhbmQg dGhhdCdzIGdlbmVyYWxseSBhIGJhZCBpZGVhIGZvciBhbiBhcHBsaWNhdGlvbi4NCj4gDQo+IFNv IG15IHByZWZlcmVuY2Ugd291bGQgYmUgdG8gaGF2ZSBhIGJhc2VsaW5lIGNvbm5lY3Rpdml0eSBw cm90b2NvbCB0aGF0DQo+IGRvZXMgbm90IHJlcXVpcmUgcm9vdC4gIEl0IGNhbiBiZSBTVFVOLCBv ciBhIFRDUCBjb25uZWN0aW9uIHRvIHBvcnQgNywgb3IgYQ0KPiBVRFAgY29ubmVjdGlvbiB0byBw b3J0IDcgd2l0aCBhIHJldHJhbnNtaXNzaW9uIGFsZ29yaXRobSBpZGVudGljYWwgdG8gdGhlDQo+ IFNUVU4gLSBJIGRvIG5vdCByZWFsbHkgY2FyZSwgYnV0IHRoZSBkcmFmdCBtdXN0IG1hbmRhdGUg b25lLCBhbmQgbXVzdA0KPiBtYW5kYXRlIHRoYXQgdGhpcyBiYXNlbGluZSBwcm90b2NvbCBpcyBh Y3RpdmUgb24gdGhlIGhvc3RuYW1lIGlmIGEgUFRSIFJSIGlzDQo+IGluc3RhbGxlZC4NCj4gDQo+ IEFmdGVyIHRoaXMgaXQgaXMgYWx3YXlzIHBvc3NpYmxlIHRvIGRlZmluZSBhIFMtTkFQVFIgYXBw bGljYXRpb24gdG8gcHVibGlzaCB0aGUNCj4gb3RoZXIgY29ubmVjdGl2aXR5IHByb3RvY29scyBh dmFpbGFibGUgYXQgdGhlIGhvc3RuYW1lIGluIHRoZSBQVFIgUlIuDQoNClBlcnNvbmFsbHksIEkg ZG9uJ3QgdGhpbmsgd2Ugc2hvdWxkIHN0YW5kYXJkaXplIGFueXRoaW5nIGFyb3VuZCBTLU5BUFRS Lg0KDQotRGF2ZQ0KDQo+IA0KPiAtIC0tDQo+IE1hcmMgUGV0aXQtSHVndWVuaW4NCj4gRW1haWw6 IG1hcmNAcGV0aXQtaHVndWVuaW4ub3JnDQo+IEJsb2c6IGh0dHA6Ly9ibG9nLm1hcmMucGV0aXQt aHVndWVuaW4ub3JnDQo+IFByb2ZpbGU6IGh0dHA6Ly93d3cubGlua2VkaW4uY29tL2luL3BldGl0 aHVnDQo+IC0tLS0tQkVHSU4gUEdQIFNJR05BVFVSRS0tLS0tDQo+IFZlcnNpb246IEdudVBHIHYx LjQuMTIgKEdOVS9MaW51eCkNCj4gDQo+IGlRSWNCQUVCQ0FBR0JRSlA2NFdMQUFvSkVDbkVSWlhX YW43RXI3RVFBS1h4TzVCYU9NSk1wZFF5U2sNCj4gSGxxLzJwDQo+IDRvUHlJU3hUeGxZZUdPY1Fo WmhlSW5DYjVJWXcrMkJiZVRmTFRBYXU1NEx1RXBDeVVJOU1IQ2FoNWI0azd2bg0KPiA0DQo+IFdz SGw0NFVKMmdjNWNJNThyNnNuc2lwdjJqNitKbHRtZzFrK0pudEpvTlh3aENoWk11dTdna0tvWlJ2 WEljbGsNCj4gQzNrdDJSdjhnaFJzWForM2oxRExOTmpETHIvOCszNUdQQTQ3a3ZJYy84SjNkUGpV VXVWVDlTOTRWTXhDdWFtDQo+IEwNCj4gdkNoYloxdFBLeWVKbE5CcUI2QmZWMGswcm1nT0RCQnlE dkErWTh3SDFwYUVHTHRMNXF1NndhV2pZTnBGdw0KPiBjc1gNCj4gZUQ5dmthYm5JNi9tUVgxZHdw ZEhmam5TdkRQOFppdHE1bU1scVJocE8xdWwwN3RxemRKUmdCYmRycndIR0piDQo+IGwNCj4gTisv YWh1R0hPMW51Q09GN1JUYlJXMUcvVmJuWkw4ME5TTStaeWlhb2RyeGhMRHRTRzJlNlJ1N0NjOE9j DQo+IFJOTHkNCj4gSTBVV3dRaVlGcW0zVUFSY2NCcjBsd1RURGVkOXJIb05pMXZqdFIrREFvaGY3 WmVwSXhRdmVBMlA3ZUJCSjkNCj4gdlkNCj4gczVia1JWbThZeVMyeGtVK0V5ejd4alM0SmJKVmdM RTNpQzJndmpEbXBFaGUyRERISUVXVkY0OHRzU1ZuVzYNCj4gdzMNCj4gdWtCbmF3bjE2b3NBR2Fi aWFPNGdCeTAxWEduSlhERHVnNXJ0UUU4RHZRc1prNzd1d3NhV21XVnRNc3QNCj4gUENUWXgNCj4g VTdSdHk0V2ZVWVRCSy9XR2xXRlg4UVZiTmZLenZGZXN5RDAwd2cxLzJSNnVVbUxBTVZtb2h6TXZY DQo+IFltaUVIZVANCj4gZHEvYXhKQUxHc0RjaHUwdGg5V0cNCj4gPUhVTWwNCj4gLS0tLS1FTkQg UEdQIFNJR05BVFVSRS0tLS0tDQoNCg== From petithug@acm.org Wed Jun 27 15:44:07 2012 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 F08F621F8600 for ; Wed, 27 Jun 2012 15:44:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.011, 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 pQCmtGrvswXi for ; Wed, 27 Jun 2012 15:44:05 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id A573821F85FD for ; Wed, 27 Jun 2012 15:44:05 -0700 (PDT) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id A6220204B8; Wed, 27 Jun 2012 22:43:53 +0000 (UTC) Message-ID: <4FEB8CA7.3000000@acm.org> Date: Wed, 27 Jun 2012 15:43:51 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.5) Gecko/20120624 Icedove/10.0.5 MIME-Version: 1.0 To: Dave Thaler References: <9B57C850BB53634CACEC56EF4853FF653B62BDA4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B66483D@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <4FE250F5.5010505@acm.org> <916CE6CF87173740BC8A2CE443096962043AF580@008-AM1MPN1-053.mgdnok.nokia.com> <4FEA3758.40203@acm.org> <916CE6CF87173740BC8A2CE443096962043BF32C@008-AM1MPN1-052.mgdnok.nokia.com> <4FEB1317.1080905@acm.org> <916CE6CF87173740BC8A2CE443096962043BF6A2@008-AM1MPN1-052.mgdnok.nokia.com> <4FEB85C7.20903@acm.org> <9B57C850BB53634CACEC56EF4853FF653B67BCAB@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B67BCAB@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "behave@ietf.org" Subject: Re: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09 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, 27 Jun 2012 22:44:07 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 06/27/2012 03:22 PM, Dave Thaler wrote: >> -----Original Message----- From: Marc Petit-Huguenin >> [mailto:petithug@acm.org] Sent: Wednesday, June 27, 2012 3:15 PM To: >> teemu.savolainen@nokia.com Cc: Dave Thaler; behave@ietf.org Subject: Re: >> [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic- 09 >> > On 06/27/2012 11:34 AM, teemu.savolainen@nokia.com wrote: >>>>> I am surprised that there is not already an RFC somewhere >>>>> describing how to do connectivity checks with ICMP[v6]. Perhaps it >>>>> would be simpler to reuse the rules used by STUN: >>>>> >>>>> https://tools.ietf.org/html/rfc5389#section-7.2.1 >>>> >>>> That sounds more complex / overkill for me.. What benefit does that >>>> complex RTO estimation give here? >>>> >>>> If we'd use fixed initial value of 1s for RTO, and then define Rc to >>>> be e.g. 7, and have final "Rm" like 3 (seconds), isn't that close >>>> enough? That would result in 10 seconds until failure? >>>> > > My point was that an existing algorithm should be used, instead of > designing a new one. > >> Ping isn't a new algorithm. Yes, but ping (with default options) is a continuous connectivity check, whereas the usage in nat64-discovery-heuristic is more like the ICE connectivity check. > > But I thought a little bit more about this and I agree with Simon that > using ICMPv6 as the baseline connectivity check is not a good idea, but for > a different reason: Most of the code that would need to synthesize IPv6 > addresses will run in applications. > >> Legitimate question: Do you have data to support that ("most")? No, but SIP and SDP look like good candidates for protocols carrying IPv4 addresses that would require to be converted to IPv6 addresses in a NAT64 environment, and applications using these protocols are generally not run under root. > > But sending ICMPv6 packets requires root (or something equivalent) and > that's generally a bad idea for an application. > > So my preference would be to have a baseline connectivity protocol that > does not require root. It can be STUN, or a TCP connection to port 7, or > a UDP connection to port 7 with a retransmission algorithm identical to > the STUN - I do not really care, but the draft must mandate one, and must > mandate that this baseline protocol is active on the hostname if a PTR RR > is installed. > > After this it is always possible to define a S-NAPTR application to publish > the other connectivity protocols available at the hostname in the PTR RR. > >> Personally, I don't think we should standardize anything around S-NAPTR. I like S-NAPTR :-) - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJP64ymAAoJECnERZXWan7EIyYP/0SgGOzZrw1O0GFAiXINQl5x hF63G78cFPIZtGIZlNkwZv2mNyjaRVYohrPnNyojOyp+8oU96eDKRT+lfrvcQbqM kONNf34hKdLcpptfPpDz52BjhjgN6+QM85JOXearBJn3TCsJMZltMxJhRIO4XPEU +z/mVtiSjChe2XJU272cKIQZu87R/hZXj/9MuUt5DfQ9VU7s5KMAapqHmf/aPyMo +6/CGGxl+O3B1P1cK5QBslf9yx9bmadj80SyLd8TGKkccNbjKCVhJxgtnxFh6kYc GZZ9XgIozDUgTBjFoS6xVmO5rleeLMPXdC495n1wlrF+VYUR/hsWZG2wxZJ7uXod 4Cc4kMH8Tx8tRDOojh+gyPrMu2xxCMw3u2yDjdH2R2T601Faq69LaA/qRuLcrVic uHpLi2zWLGQQ/Q/8eFk5MnYcX1eSEUxtbt+GIE5HQ2BP5ebygwsPG1smvSWxHbHs l5HHza8+Ig/FVs1bmF92YA+z1kE3IAnm08f5H3UNPiTMXmVUbL1dzsMA+4Wtk10Y Jqy415r/rzM0xAxA0Ht9NMrJp4WJCG5uwYbQvLvmC4tsGi5G2bwk8FrIe5eb3uHG gXmOrMZCfC+LwShDEO8v4ZsHO9gXopciiuGH2662ZuqA+cLhH2DP4dMJgkrD93gv qsvkATb/0faBQ/vYhSyG =PqEt -----END PGP SIGNATURE----- From Dmitry.Anipko@microsoft.com Wed Jun 27 17:14:07 2012 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 A40AD11E8149 for ; Wed, 27 Jun 2012 17:14:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.717 X-Spam-Level: X-Spam-Status: No, score=-2.717 tagged_above=-999 required=5 tests=[AWL=0.750, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] 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 JcSk1qx59KWp for ; Wed, 27 Jun 2012 17:14:06 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe003.messaging.microsoft.com [65.55.88.13]) by ietfa.amsl.com (Postfix) with ESMTP id 76CDC11E8148 for ; Wed, 27 Jun 2012 17:14:06 -0700 (PDT) Received: from mail68-tx2-R.bigfish.com (10.9.14.241) by TX2EHSOBE003.bigfish.com (10.9.40.23) with Microsoft SMTP Server id 14.1.225.23; Thu, 28 Jun 2012 00:12:21 +0000 Received: from mail68-tx2 (localhost [127.0.0.1]) by mail68-tx2-R.bigfish.com (Postfix) with ESMTP id 3119B4C05EB for ; Thu, 28 Jun 2012 00:12:21 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC106.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -27 X-BigFish: VS-27(zz9371Ic89bh542M1432Izz1202hzz1033IL8275bh8275dhz2fh2a8h683h839hd25hf0ah) Received-SPF: pass (mail68-tx2: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Dmitry.Anipko@microsoft.com; helo=TK5EX14HUBC106.redmond.corp.microsoft.com ; icrosoft.com ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.244.37; KIP:(null); UIP:(null); (null); H:CH1PRD0310HT004.namprd03.prod.outlook.com; R:internal; EFV:INT Received: from mail68-tx2 (localhost.localdomain [127.0.0.1]) by mail68-tx2 (MessageSwitch) id 1340842336289227_11351; Thu, 28 Jun 2012 00:12:16 +0000 (UTC) Received: from TX2EHSMHS018.bigfish.com (unknown [10.9.14.239]) by mail68-tx2.bigfish.com (Postfix) with ESMTP id 3694C1E004A for ; Thu, 28 Jun 2012 00:12:16 +0000 (UTC) Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS018.bigfish.com (10.9.99.118) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 28 Jun 2012 00:12:15 +0000 Received: from tx2outboundpool.messaging.microsoft.com (157.54.51.80) by mail.microsoft.com (157.54.80.61) with Microsoft SMTP Server (TLS) id 14.2.309.3; Thu, 28 Jun 2012 00:13:59 +0000 Received: from mail34-tx2-R.bigfish.com (10.9.14.238) by TX2EHSOBE008.bigfish.com (10.9.40.28) with Microsoft SMTP Server id 14.1.225.23; Thu, 28 Jun 2012 00:12:13 +0000 Received: from mail34-tx2 (localhost [127.0.0.1]) by mail34-tx2-R.bigfish.com (Postfix) with ESMTP id 9EAAD340389 for ; Thu, 28 Jun 2012 00:12:13 +0000 (UTC) Received: from mail34-tx2 (localhost.localdomain [127.0.0.1]) by mail34-tx2 (MessageSwitch) id 134084233158902_3233; Thu, 28 Jun 2012 00:12:11 +0000 (UTC) Received: from TX2EHSMHS040.bigfish.com (unknown [10.9.14.239]) by mail34-tx2.bigfish.com (Postfix) with ESMTP id 00D784E004D; Thu, 28 Jun 2012 00:12:11 +0000 (UTC) Received: from CH1PRD0310HT004.namprd03.prod.outlook.com (157.56.244.37) by TX2EHSMHS040.bigfish.com (10.9.99.140) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 28 Jun 2012 00:12:07 +0000 Received: from CH1PRD0310MB368.namprd03.prod.outlook.com ([169.254.8.166]) by CH1PRD0310HT004.namprd03.prod.outlook.com ([10.255.137.39]) with mapi id 14.16.0152.000; Thu, 28 Jun 2012 00:13:51 +0000 From: Dmitry Anipko To: "teemu.savolainen@nokia.com" , Dave Thaler , "behave@ietf.org" Thread-Topic: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09 Thread-Index: AQHNU6dBHl1WqM4K4kyX71U7NkG1NpcM43GwgAAM2QCAATGJgIAAtyKg Date: Thu, 28 Jun 2012 00:13:51 +0000 Message-ID: <96DD85EB136DCD49AB5CDB6DEC9639AD06860E45@CH1PRD0310MB368.namprd03.prod.outlook.com> References: <9B57C850BB53634CACEC56EF4853FF653B62BDA4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B66483D@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <96DD85EB136DCD49AB5CDB6DEC9639AD068597EA@CH1PRD0310MB368.namprd03.prod.outlook.com> <916CE6CF87173740BC8A2CE443096962043BE42D@008-AM1MPN1-052.mgdnok.nokia.com> <96DD85EB136DCD49AB5CDB6DEC9639AD0685BB90@CH1PRD0310MB368.namprd03.prod.outlook.com> <916CE6CF87173740BC8A2CE443096962043BE62F@008-AM1MPN1-052.mgdnok.nokia.com> <916CE6CF87173740BC8A2CE443096962043BF2D0@008-AM1MPN1-052.mgdnok.nokia.com> In-Reply-To: <916CE6CF87173740BC8A2CE443096962043BF2D0@008-AM1MPN1-052.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.192.100] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: CH1PRD0310HT004.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%NOKIA.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14HUBC106.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC106.redmond.corp.microsoft.com X-OriginatorOrg: microsoft.com Subject: Re: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09 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, 28 Jun 2012 00:14:07 -0000 Hi Teemu, >>> It is true that this would not work if the host gets a special use=20 > IPv4 address literal from somewhere, but how common is that? If there are use cases for draft-ietf-behave-nat64-discovery-heuristic-09, = same use cases if they make sense in e.g. enterprise network using RFC 1918= addresses, in such network will result in 10.* literals. Do use cases of d= raft-ietf-behave-nat64-discovery-heuristic-09 apply to enterprise networks = (or homenet) or other networks, which have legacy parts using RFC 1918 spac= e? E.g. a network which has new IPv6-only segment, and some legacy segment/= servers with IPv4 addressing, to which IPv6 only can only connect using DNS= 64/NAT64? > If the node would get these special use IPv4 address literals and synthes= ize > based on those (but network is not prepared to for node to use discovered > Pref64::/n with those addresses), then sure, it would take a while for > connection attempts to fail. But we have happy eyeballs:) HE is supposed to fix existing brokenness. We don't want to create new brok= enness and rely on HE to fix it. >>> This would require some sort of policy distribution mechanism, and the = design > requirement we had is that there must not be any DNS64 changes. Is this a goal for nodes implementing the heuristic to be able to use the h= euristic on any network with DNS64, or only on a special network that has b= een designed for them? (as the text you proposed suggests) I think we need to better understand the reasoning behind the RFC 6147 SHOU= LD- perhaps RFC 6147 authors and folks who deploy NAT64 in different enviro= nments could help to advice whether it is likely to have e.g. two NAT64 on = the network (e.g. one is for internal network IPv4 island, the other one is= for access to IPv4 Internet), and if so - whether it is possible&feasible = for those NATs to handle traffic with incorrectly synthesized addresses wit= hout breaking connectivity.=20 If nobody actually is/will be deploying such configurations, I agree there = is no practical problem.=20 If some people are deploying configurations with multiple not chained NATs,= and there is no way to make them work with incorrectly synthesized address= es, then there is a problem that has not been addressed. If people are deploying such configurations, and there is a way to make the= m work without breaking connectivity, then the only consideration is whethe= r it is acceptable to require that the network which the node visits needs = to be re-configured in order for the node to be able to use the heuristic. = If it is acceptable, I think the text you proposed would benefit if it is e= laborated how the network shall be designed to handle this case, but otherw= ise it looks good to me. Thank you, Dmitry. -----Original Message----- From: teemu.savolainen@nokia.com [mailto:teemu.savolainen@nokia.com]=20 Sent: Wednesday, June 27, 2012 5:59 AM To: Dmitry Anipko; Dave Thaler; behave@ietf.org Subject: RE: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristi= c-09 Dmitry, how about following piece of text as new subsection: -- Mapping of IPv4 Address Ranges to IPv6 Prefixes The RFC 6147 [RFC6147] allows DNS64 implementations to be able to map specific IPv4 address ranges to separate Pref64::/n. That allows handling of special use IPv4 addresses [RFC5735]. The heuristic discovery method described herein does not support learning of the possible rules used by DNS64 server for mapping specific IPv4 address ranges to separate Pref64::/n. Therefore, nodes will use the same discovered Pref64::/n to synthesize IPv6 addresses out from any IPv4 address. The operator of the NAT64 and the DNS64 ought to take this into account in the network design and support routing, even if not optimal, of the packets nodes have synthesized by combining the discovered Pref64::/n and the IPv4 address nodes have learned via DNS or obtained as referrals. -- Best regards, Teemu > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf > Of Savolainen Teemu (Nokia-NRC/Tampere) > Sent: 26. kes=E4kuuta 2012 21:45 > To: Dmitry.Anipko@microsoft.com; dthaler@microsoft.com; behave@ietf.org > Subject: Re: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuris= tic- > 09 > > Hi, > > > I think essentially it is the same question - without some additional > > knowledge (such as e.g. of range->prefix mappings), the host can't > > answer either of the questions correctly (either how to synthesize > > IPv6 based on given IPv4, or whether to synthesize IPv6 for a given IPv= 4). > > In which case and from where the host would get special use IPv4 address > literals? Being in IPv6-only access and encountering literal net10 addres= ses in > html? > > I mean, in the common case host performs AAAA query for a name and it can > get synthesized IPv6 address from DNS64 that has this mapping capability > (and can return synthetic IPv6 address containing IPv4 address from speci= al > group). I would assume this would be the most common case. > > It is true that this would not work if the host gets a special use IPv4 a= ddress > literal from somewhere, but how common is that? > > I mean if the access network (enterprise, cellular, e.g.) would want thei= r IPv6- > only hosts to access their IPv4-only devices that are numbered with speci= al > use IPv4 addresses, why the said organization would not create AAAA recor= ds > containing IPv6 addresses pointing to NAT64, or otherwise ensure their IP= v6- > only hosts do not encounter these special use IPv4 address literals? Or t= he > organization would ensure the packets flow correctly when hosts use > discovered Pref64::/n in combination with special use addresses. > > > I'm not sure that would be sufficient - the node then still could > > synthesize IPv6 incorrectly, and that could lead to added connectivity > > issues (IPv6 connection timeouts), not present without DNS64 function > > in the node, as well as to unanticipated effects on the network NAT64 > > device (increased error reporting, unanticipated traffic load, etc.). > > Or perhaps I misunderstood what you meant with "not implement"? > > If the node would get these special use IPv4 address literals and synthes= ize > based on those (but network is not prepared to for node to use discovered > Pref64::/n with those addresses), then sure, it would take a while for > connection attempts to fail. But we have happy eyeballs:) > > > If the current text is standardized as is, then IMO we can end up in a > > somewhat strange situation where two entities following two standards, > > which were meant to work together, actually don't always interoperate. > > A couple of things that could be done to mitigate/address that: > > Which entities do not interoperate? > > > 1. Say in the draft-ietf-behave-nat64-discovery-heuristic that it > > doesn't work with network DNS64s configured with different IPv6 > > prefixes for different IPv4 ranges. (and then it would make sense to > > change RFC6147 SHOULD to SHOULD NOT for any addresses that are likely > > to be used on the wire) > > It would work, if the NAT64 to which packets using discovered Pref64::/n = are > routed can reach these special use addresses. I.e. maybe the routing woul= d > not be as efficient as with the prefix network's DNS64 would've used for = these > IPv4 ranges, but packets could flow nevertheless. > > I mean I don't understand the use case when different IPv6 prefix is need= ed > for different IPv4 ranges, unless for route optimization. And if the rout= e > optimization is all that there is, then is there really a problem if some= packets > do not follow the most optimal route? > > > 2. Come up with a procedure, which operator of network DNS64 & node > > DNS64 could use, if the network DNS64 is configured with such > > different prefixes, to enable in-node DNS64 to learn the necessary > information. > > This would require some sort of policy distribution mechanism, and the de= sign > requirement we had is that there must not be any DNS64 changes. > > In my opinion we can write a section about implications of special use IP= v4 > addresses and lack of support for specific IPv4 ranges, but state that if= f the > host actually encounters these literals, and synthesizes IPv6 addresses w= ith > Pref64::/n, the network ought to be able to route packets correctly > nevertheless, and the host should provide graceful failure experience for= the > user (which the host anyway does, TCP SYNs can get lost anyway). > > Best regards, > > Teemu > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From dwing@cisco.com Wed Jun 27 22:49:14 2012 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 6437521F8694 for ; Wed, 27 Jun 2012 22:49:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.416 X-Spam-Level: X-Spam-Status: No, score=-110.416 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 IYiyhlyWaXZg for ; Wed, 27 Jun 2012 22:49:13 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 5943521F85C2 for ; Wed, 27 Jun 2012 18:19:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=12014; q=dns/txt; s=iport; t=1340846360; x=1342055960; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=zwSON0tA7rPO2Nbi83I74uAg7wYkMJZgNJdr2UJ/kno=; b=Fo8+2FpDbBAmbklbALJwlbG9KAxyw/7EuaSq8GBjEwt/hwCaMJ5IbMlM Q6w8S/Y0savpejfNrJKMehi3zswEneYeCbqeVkbRwn9nrfB+TlzjXOp29 dOU6ARE/TU8zKE4TxPV9Cx0l/eMagxI9WEm/1yeEey4lNcmU80QvnaquB c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFALSv60+rRDoH/2dsb2JhbABFpzWPAYEHghgBAQEDAQEBAQUKARQDQwEQBwEDAgkPAgQBARYSBxkOFQoJCAIEARILEAeFb4F1BAyYAKBQizeCYoMoA4gXM4UDiHeNC4Fmgn+BPw X-IronPort-AV: E=Sophos;i="4.77,488,1336348800"; d="scan'208";a="47837631" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 28 Jun 2012 01:19:19 +0000 Received: from dwingWS (sjc-vpn4-1048.cisco.com [10.21.84.23]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q5S1JJAo027931; Thu, 28 Jun 2012 01:19:19 GMT From: "Dan Wing" To: "'Dmitry Anipko'" , , "'Dave Thaler'" , References: <9B57C850BB53634CACEC56EF4853FF653B62BDA4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B66483D@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <96DD85EB136DCD49AB5CDB6DEC9639AD068597EA@CH1PRD0310MB368.namprd03.prod.outlook.com> <916CE6CF87173740BC8A2CE443096962043BE42D@008-AM1MPN1-052.mgdnok.nokia.com> <96DD85EB136DCD49AB5CDB6DEC9639AD0685BB90@CH1PRD0310MB368.namprd03.prod.outlook.com> <916CE6CF87173740BC8A2CE443096962043BE62F@008-AM1MPN1-052.mgdnok.nokia.com> <916CE6CF87173740BC8A2CE443096962043BF2D0@008-AM1MPN1-052.mgdnok.nokia.com> <96DD85EB136DCD49AB5CDB6DEC9639AD06860E45@CH1PRD0310MB368.namprd03.prod.outlook.com> In-Reply-To: <96DD85EB136DCD49AB5CDB6DEC9639AD06860E45@CH1PRD0310MB368.namprd03.prod.outlook.com> Date: Wed, 27 Jun 2012 18:19:18 -0700 Message-ID: <075601cd54cc$0a8396f0$1f8ac4d0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHNU6dBHl1WqM4K4kyX71U7NkG1NpcM43GwgAAM2QCAATGJgIAAtyKggAASk/A= Content-Language: en-us Subject: Re: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09 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, 28 Jun 2012 05:49:14 -0000 > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of Dmitry Anipko > Sent: Wednesday, June 27, 2012 5:14 PM > To: teemu.savolainen@nokia.com; Dave Thaler; behave@ietf.org > Subject: Re: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery- > heuristic-09 >=20 > Hi Teemu, >=20 > >>> It is true that this would not work if the host gets a special use > > IPv4 address literal from somewhere, but how common is that? >=20 > If there are use cases for = draft-ietf-behave-nat64-discovery-heuristic- > 09, same use cases if they make sense in e.g. enterprise network using > RFC 1918 addresses, in such network will result in 10.* literals. Do > use cases of draft-ietf-behave-nat64-discovery-heuristic-09 apply to > enterprise networks (or homenet) or other networks, which have legacy > parts using RFC 1918 space? E.g. a network which has new IPv6-only > segment, and some legacy segment/servers with IPv4 addressing, to = which > IPv6 only can only connect using DNS64/NAT64? What we are effectively describing is a routing table: IPv4 destination NAT64 prefix ---------------- ------------ 10.1.0.0/16 2001:db8:1 10.2.0.0/16 2001:db8:1 192.168.1/24 2001:db8:3 192.168.2/24 2001:db8:4 =20 The simple solution is declare that out of scope, and say that the DNS64 heuristic doesn't support unique NAT64 prefixes per IPv4 prefix. We have always known the DNS64 heuristic is not ideal, is not=20 perfect, and somewhat of a documented kludge. Andrew Sullivan has=20 more colorful, and accurate, summary of the DNS64 heuristic. The harder solution is to specify how to build ipv4only.arpa queries for each different destination IPv4 prefix. ISPs would wildcard their ipv4only.arpa resource record (attracting all destination traffic to their NAT64). > > If the node would get these special use IPv4 address literals and > synthesize > > based on those (but network is not prepared to for node to use > discovered > > Pref64::/n with those addresses), then sure, it would take a while > for > > connection attempts to fail. But we have happy eyeballs:) >=20 > HE is supposed to fix existing brokenness. We don't want to create new > brokenness and rely on HE to fix it. >=20 > >>> This would require some sort of policy distribution mechanism, and > the design > > requirement we had is that there must not be any DNS64 changes. >=20 > Is this a goal for nodes implementing the heuristic to be able to use > the heuristic on any network with DNS64, or only on a special network > that has been designed for them? (as the text you proposed suggests) >=20 > I think we need to better understand the reasoning behind the RFC 6147 > SHOULD- perhaps RFC 6147 authors and folks who deploy NAT64 in > different environments could help to advice whether it is likely to > have e.g. two NAT64 on the network (e.g. one is for internal network > IPv4 island, the other one is for access to IPv4 Internet), and if so = - > whether it is possible&feasible for those NATs to handle traffic with > incorrectly synthesized addresses without breaking connectivity. The idea, as I recall it, was to allow an ISP to operate two NAT64 devices, one going to the Internet, the other connecting to an IPv4-only datacenter (IMAP servers, WWW servers, media streamers, etc.), like this, NAT64-------IPv4-only servers in datacenter / IPv6-only host----< \ NAT64------IPv4 Internet > If nobody actually is/will be deploying such configurations, I agree > there is no practical problem. Deployments like the above, without IPv6 anywhere (just IPv4 and NAT44) = do exist. > If some people are deploying configurations with multiple not chained > NATs, and there is no way to make them work with incorrectly > synthesized addresses, then there is a problem that has not been > addressed. >=20 > If people are deploying such configurations, and there is a way to = make > them work without breaking connectivity, then the only consideration = is > whether it is acceptable to require that the network which the node > visits needs to be re-configured in order for the node to be able to > use the heuristic. If it is acceptable, I think the text you proposed > would benefit if it is elaborated how the network shall be designed to > handle this case, but otherwise it looks good to me. I would declare it as acceptable. Routing on the last 32 bits of the IPv6 _is_ possible, or if that is undesirable, adjust the NAT64 mapping so the IPv4 address is earlier in the IPv6 address. The heuristic and the NAT64 addressing format support either choice. In this way, the same NAT64 prefix is used, but a router in front of the two NAT64's causes the packets to go one way or the other: NAT64-------IPv4-only servers in datacenter / IPv6-only host----router \ NAT64------IPv4 Internet Appropriate filtering -- which probably is already present -- would be needed on the 'other' NAT64 (e.g., so 10.0.0.0/8 doesn't appear on the Internet-connected NAT64). -d > Thank you, > Dmitry. >=20 > -----Original Message----- > From: teemu.savolainen@nokia.com [mailto:teemu.savolainen@nokia.com] > Sent: Wednesday, June 27, 2012 5:59 AM > To: Dmitry Anipko; Dave Thaler; behave@ietf.org > Subject: RE: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery- > heuristic-09 >=20 > Dmitry, how about following piece of text as new subsection: > -- > Mapping of IPv4 Address Ranges to IPv6 Prefixes >=20 > The RFC 6147 [RFC6147] allows DNS64 implementations to be able to > map > specific IPv4 address ranges to separate Pref64::/n. That allows > handling of special use IPv4 addresses [RFC5735]. >=20 > The heuristic discovery method described herein does not support > learning of the possible rules used by DNS64 server for mapping > specific IPv4 address ranges to separate Pref64::/n. Therefore, > nodes will use the same discovered Pref64::/n to synthesize IPv6 > addresses out from any IPv4 address. The operator of the NAT64 and > the DNS64 ought to take this into account in the network design and > support routing, even if not optimal, of the packets nodes have > synthesized by combining the discovered Pref64::/n and the IPv4 > address nodes have learned via DNS or obtained as referrals. > -- >=20 > Best regards, >=20 > Teemu >=20 > > -----Original Message----- > > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf > > Of Savolainen Teemu (Nokia-NRC/Tampere) > > Sent: 26. kes=E4kuuta 2012 21:45 > > To: Dmitry.Anipko@microsoft.com; dthaler@microsoft.com; > behave@ietf.org > > Subject: Re: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery- > heuristic- > > 09 > > > > Hi, > > > > > I think essentially it is the same question - without some > additional > > > knowledge (such as e.g. of range->prefix mappings), the host can't > > > answer either of the questions correctly (either how to synthesize > > > IPv6 based on given IPv4, or whether to synthesize IPv6 for a = given > IPv4). > > > > In which case and from where the host would get special use IPv4 > address > > literals? Being in IPv6-only access and encountering literal net10 > addresses in > > html? > > > > I mean, in the common case host performs AAAA query for a name and = it > can > > get synthesized IPv6 address from DNS64 that has this mapping > capability > > (and can return synthetic IPv6 address containing IPv4 address from > special > > group). I would assume this would be the most common case. > > > > It is true that this would not work if the host gets a special use > IPv4 address > > literal from somewhere, but how common is that? > > > > I mean if the access network (enterprise, cellular, e.g.) would want > their IPv6- > > only hosts to access their IPv4-only devices that are numbered with > special > > use IPv4 addresses, why the said organization would not create AAAA > records > > containing IPv6 addresses pointing to NAT64, or otherwise ensure > their IPv6- > > only hosts do not encounter these special use IPv4 address literals? > Or the > > organization would ensure the packets flow correctly when hosts use > > discovered Pref64::/n in combination with special use addresses. > > > > > I'm not sure that would be sufficient - the node then still could > > > synthesize IPv6 incorrectly, and that could lead to added > connectivity > > > issues (IPv6 connection timeouts), not present without DNS64 > function > > > in the node, as well as to unanticipated effects on the network > NAT64 > > > device (increased error reporting, unanticipated traffic load, > etc.). > > > Or perhaps I misunderstood what you meant with "not implement"? > > > > If the node would get these special use IPv4 address literals and > synthesize > > based on those (but network is not prepared to for node to use > discovered > > Pref64::/n with those addresses), then sure, it would take a while > for > > connection attempts to fail. But we have happy eyeballs:) > > > > > If the current text is standardized as is, then IMO we can end up > in a > > > somewhat strange situation where two entities following two > standards, > > > which were meant to work together, actually don't always > interoperate. > > > A couple of things that could be done to mitigate/address that: > > > > Which entities do not interoperate? > > > > > 1. Say in the draft-ietf-behave-nat64-discovery-heuristic that it > > > doesn't work with network DNS64s configured with different IPv6 > > > prefixes for different IPv4 ranges. (and then it would make sense > to > > > change RFC6147 SHOULD to SHOULD NOT for any addresses that are > likely > > > to be used on the wire) > > > > It would work, if the NAT64 to which packets using discovered > Pref64::/n are > > routed can reach these special use addresses. I.e. maybe the routing > would > > not be as efficient as with the prefix network's DNS64 would've used > for these > > IPv4 ranges, but packets could flow nevertheless. > > > > I mean I don't understand the use case when different IPv6 prefix is > needed > > for different IPv4 ranges, unless for route optimization. And if the > route > > optimization is all that there is, then is there really a problem if > some packets > > do not follow the most optimal route? > > > > > 2. Come up with a procedure, which operator of network DNS64 & = node > > > DNS64 could use, if the network DNS64 is configured with such > > > different prefixes, to enable in-node DNS64 to learn the necessary > > information. > > > > This would require some sort of policy distribution mechanism, and > the design > > requirement we had is that there must not be any DNS64 changes. > > > > In my opinion we can write a section about implications of special > use IPv4 > > addresses and lack of support for specific IPv4 ranges, but state > that iff the > > host actually encounters these literals, and synthesizes IPv6 > addresses with > > Pref64::/n, the network ought to be able to route packets correctly > > nevertheless, and the host should provide graceful failure = experience > for the > > user (which the host anyway does, TCP SYNs can get lost anyway). > > > > Best regards, > > > > Teemu > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www.ietf.org/mailman/listinfo/behave >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From teemu.savolainen@nokia.com Wed Jun 27 23:49:07 2012 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 4489A11E81DF for ; Wed, 27 Jun 2012 23:49:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 OZgcdKqzn3to for ; Wed, 27 Jun 2012 23:49:06 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 76C0411E81DE for ; Wed, 27 Jun 2012 23:49:06 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-da02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q5S6n1NF002787; Thu, 28 Jun 2012 09:49:03 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.23]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 28 Jun 2012 09:49:11 +0300 Received: from 008-AM1MPN1-053.mgdnok.nokia.com ([169.254.3.74]) by 008-AM1MMR1-007.mgdnok.nokia.com ([65.54.30.23]) with mapi id 14.02.0283.004; Thu, 28 Jun 2012 08:49:01 +0200 From: To: , , , Thread-Topic: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09 Thread-Index: AQHNU8vMJW0v97C6d0anvYXMmpcItJcOIT1wgACbboCAABJKAIAAeLuw Date: Thu, 28 Jun 2012 06:49:00 +0000 Message-ID: <916CE6CF87173740BC8A2CE443096962043C8C69@008-AM1MPN1-053.mgdnok.nokia.com> References: <9B57C850BB53634CACEC56EF4853FF653B62BDA4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B66483D@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <96DD85EB136DCD49AB5CDB6DEC9639AD068597EA@CH1PRD0310MB368.namprd03.prod.outlook.com> <916CE6CF87173740BC8A2CE443096962043BE42D@008-AM1MPN1-052.mgdnok.nokia.com> <96DD85EB136DCD49AB5CDB6DEC9639AD0685BB90@CH1PRD0310MB368.namprd03.prod.outlook.com> <916CE6CF87173740BC8A2CE443096962043BE62F@008-AM1MPN1-052.mgdnok.nokia.com> <916CE6CF87173740BC8A2CE443096962043BF2D0@008-AM1MPN1-052.mgdnok.nokia.com> <96DD85EB136DCD49AB5CDB6DEC9639AD06860E45@CH1PRD0310MB368.namprd03.prod.outlook.com> <075601cd54cc$0a8396f0$1f8ac4d0$@com> In-Reply-To: <075601cd54cc$0a8396f0$1f8ac4d0$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.163.23.252] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 28 Jun 2012 06:49:11.0487 (UTC) FILETIME=[1FC05CF0:01CD54FA] X-Nokia-AV: Clean Subject: Re: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09 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, 28 Jun 2012 06:49:07 -0000 > The simple solution is declare that out of scope, and say that the > DNS64 heuristic doesn't support unique NAT64 prefixes per IPv4 prefix. I think that is what we should do - the heuristic will not discover these m= appings, and the ISP should configure their networks so that the impact is = minimal - see below about this. =20 > The harder solution is to specify how to build ipv4only.arpa queries for = each > different destination IPv4 prefix. ISPs would wildcard their ipv4only.ar= pa > resource record (attracting all destination traffic to their NAT64). But how many IPv4 prefixes there are... 4 billion queries to learn mapping = for all 2^32 possible /32 destinations ranges?-) > The idea, as I recall it, was to allow an ISP to operate two NAT64 device= s, one > going to the Internet, the other connecting to an IPv4-only datacenter (I= MAP > servers, WWW servers, media streamers, etc.), like this, >=20 > NAT64-------IPv4-only servers in datacenter > / > IPv6-only host----< > \ > NAT64------IPv4 Internet This mapping of IPv4 address ranges to IPv6 addresses problem for heuristic= s only in the case of NAT64 being close to the IPv6 host? Right? In the above example, if the setup is static, I would suggest ISP to create= signed AAAA records for the IPv4-only servers in the datacenters (using Pr= ef64::/n of the NAT64 above), in which case the IPv6-only DNSSEC using host= would get signed AAAA response from the DNS, and would use that (no need f= or local synthesis). I.e. from host point of view it would be talking to "r= eal" IPv6 destination. Also, in the case of non-DNSSEC using IPv6-only host, it is enough that ISP= 's DNS64 returns synthetic AAAA records for the servers in datacenter. Now in case the ISP does not want to provide signed AAAA records for the se= rvers in data center, but host does DNSSEC validation (or otherwise gets IP= v4 literal), then the packets from the host could end up using Pref64::/n o= f the below NAT64, and packets would be sent using "incorrect" Pref64::/n. = However, in case of ISP, why the ISP could not have more specific routes th= at would ensure the packets host sends to Pref64_of_below_NAT64:IPv4address= ofdatacenter would be actually routed to the above NAT64, and not to Intern= et-leading NAT64? .. . and I notice this is what you propose below:) > I would declare it as acceptable. Routing on the last 32 bits of the IPv= 6 _is_ > possible, or if that is undesirable, adjust the NAT64 mapping so the IPv4 > address is earlier in the IPv6 address. The heuristic and the NAT64 addr= essing > format support either choice. In this way, the same NAT64 prefix is used= , but > a router in front of the two NAT64's causes the packets to go one way or = the > other: >=20 > NAT64-------IPv4-only servers in datacenter > / > IPv6-only host----router > \ > NAT64------IPv4 Internet >=20 > Appropriate filtering -- which probably is already present -- would be ne= eded > on the 'other' NAT64 (e.g., so 10.0.0.0/8 doesn't appear on the Internet- > connected NAT64). Maybe I'll draw this picture into the draft to explain how this can be made= to work, if used by ISP? But generally I would even more prefer for ISP to ensure the IPv6-only host= does not get IPv4 address literal for its servers in datacenters, but inst= ead provides signed AAAA records for those servers. Best regards, Teemu From teemu.savolainen@nokia.com Thu Jun 28 03:09:03 2012 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 7A82C21F85A3 for ; Thu, 28 Jun 2012 03:09:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 vQkAjlwE5aRp for ; Thu, 28 Jun 2012 03:09:01 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id D920C21F863D for ; Thu, 28 Jun 2012 00:44:46 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (in-mx.nokia.com [10.160.244.31]) by mgw-da02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q5S7igPY021382; Thu, 28 Jun 2012 10:44:43 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.21]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 28 Jun 2012 10:44:51 +0300 Received: from 008-AM1MPN1-053.mgdnok.nokia.com ([169.254.3.74]) by 008-AM1MMR1-012.mgdnok.nokia.com ([65.54.30.21]) with mapi id 14.02.0283.004; Thu, 28 Jun 2012 09:44:41 +0200 From: To: Thread-Topic: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09 Thread-Index: AQHNVGW0nV8ELkaGokCA2SiRbffcqZcOEWiAgABrVvCAAB1igIAAv/wg Date: Thu, 28 Jun 2012 07:44:40 +0000 Message-ID: <916CE6CF87173740BC8A2CE443096962043C9DC1@008-AM1MPN1-053.mgdnok.nokia.com> References: <9B57C850BB53634CACEC56EF4853FF653B62BDA4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B66483D@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <4FE250F5.5010505@acm.org> <916CE6CF87173740BC8A2CE443096962043AF580@008-AM1MPN1-053.mgdnok.nokia.com> <4FEA3758.40203@acm.org> <916CE6CF87173740BC8A2CE443096962043BF32C@008-AM1MPN1-052.mgdnok.nokia.com> <4FEB1317.1080905@acm.org> <916CE6CF87173740BC8A2CE443096962043BF6A2@008-AM1MPN1-052.mgdnok.nokia.com> <4FEB85C7.20903@acm.org> In-Reply-To: <4FEB85C7.20903@acm.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.163.23.252] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 28 Jun 2012 07:44:51.0231 (UTC) FILETIME=[E664DAF0:01CD5501] X-Nokia-AV: Clean Cc: behave@ietf.org, dthaler@microsoft.com Subject: Re: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09 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, 28 Jun 2012 10:09:04 -0000 TWFyYywNCg0KPiBNeSBwb2ludCB3YXMgdGhhdCBhbiBleGlzdGluZyBhbGdvcml0aG0gc2hvdWxk IGJlIHVzZWQsIGluc3RlYWQgb2YgZGVzaWduaW5nIGENCj4gbmV3IG9uZS4NCg0KVGhhdCdzIHRo ZSBpbXBsZW1lbnRhdGlvbiBzcGVjaWZpYyBvcHRpb24uIFlvdXIgKGFwcGxpY2F0aW9uKSBpbXBs ZW1lbnRhdGlvbiBjYW4gdXNlIFNUVU4sIG9yIHNvbWUgSFRUUC1iYXNlZCBwcm9wcmlldGFyeSBz Y2hlbWUgKGZvciBleGFtcGxlKSwgIGlmIGl0IGxpa2VzIHdpdGggeW91ciBvd24gY29ubmVjdGl2 aXR5IGNoZWNrIHNlcnZlci4gV2UgZG8gbm90IHdhbnQgdG8gY3JlYXRlIG5ldyBwcm90b2NvbCBk ZXBlbmRlbmNpZXMvcmVxdWlyZW1lbnRzIGhlcmUgLSBhbmQgcmVxdWlyaW5nIFNUVU4gb3Igc2lt aWxhciB3b3VsZCBiZSBvbmUuDQoNCklmIGl0IGlzIHRvbyBkaWZmaWN1bHQgdG8gYWdyZWUgb24g ZGVmYXVsdCBjb25uZWN0aXZpdHkgY2hlY2sgcHJvdG9jb2wsIHdlIGNhbiBqdXN0IGRyb3AgdGhl IGRlZmF1bHQgY29ubmVjdGl2aXR5IGNoZWNrIG91dCBmcm9tIHRoZSBzcGVjaWZpY2F0aW9uIGFu ZCBzdGF0ZSB0aGF0IGlmIGltcGxlbWVudGF0aW9uIHdhbnRzIGFzc3VyYW5jZXMgb3RoZXIgdGhh biBqdXN0IHRyeWluZyB0byBlc3RhYmxpc2ggY29ubmVjdGlvbnMsIHRoZSBpbXBsZW1lbnRhdGlv biBjYW4gdXNlIHRoZWlyIG93biBjb25uZWN0aXZpdHkgY2hlY2sgc3lzdGVtcy4NCg0KQmVzdCBy ZWdhcmRzLA0KDQogICAgICAgIFRlZW11DQoNCg0K From teemu.savolainen@nokia.com Thu Jun 28 03:09:24 2012 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 76F7521F8699 for ; Thu, 28 Jun 2012 03:09:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 ng3wEaMSm9M7 for ; Thu, 28 Jun 2012 03:09:23 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id A077821F88FB for ; Thu, 28 Jun 2012 01:31:03 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q5S8Uv3C020605; Thu, 28 Jun 2012 11:30:59 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.20]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 28 Jun 2012 11:31:07 +0300 Received: from 008-AM1MPN1-053.mgdnok.nokia.com ([169.254.3.74]) by 008-AM1MMR1-011.mgdnok.nokia.com ([65.54.30.20]) with mapi id 14.02.0283.004; Thu, 28 Jun 2012 10:30:57 +0200 From: To: , , Thread-Topic: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09 Thread-Index: AQHNU8vMJW0v97C6d0anvYXMmpcItJcOIT1wgACbboCAAKDUcA== Date: Thu, 28 Jun 2012 08:30:57 +0000 Message-ID: <916CE6CF87173740BC8A2CE443096962043C9E90@008-AM1MPN1-053.mgdnok.nokia.com> References: <9B57C850BB53634CACEC56EF4853FF653B62BDA4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B66483D@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <96DD85EB136DCD49AB5CDB6DEC9639AD068597EA@CH1PRD0310MB368.namprd03.prod.outlook.com> <916CE6CF87173740BC8A2CE443096962043BE42D@008-AM1MPN1-052.mgdnok.nokia.com> <96DD85EB136DCD49AB5CDB6DEC9639AD0685BB90@CH1PRD0310MB368.namprd03.prod.outlook.com> <916CE6CF87173740BC8A2CE443096962043BE62F@008-AM1MPN1-052.mgdnok.nokia.com> <916CE6CF87173740BC8A2CE443096962043BF2D0@008-AM1MPN1-052.mgdnok.nokia.com> <96DD85EB136DCD49AB5CDB6DEC9639AD06860E45@CH1PRD0310MB368.namprd03.prod.outlook.com> In-Reply-To: <96DD85EB136DCD49AB5CDB6DEC9639AD06860E45@CH1PRD0310MB368.namprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.163.23.252] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 28 Jun 2012 08:31:07.0995 (UTC) FILETIME=[5D796AB0:01CD5508] X-Nokia-AV: Clean Subject: Re: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09 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, 28 Jun 2012 10:09:24 -0000 Hi Dmitry, Based on your and Dan's email, I updated the section to look as following: -----start------- 5.1. Mapping of IPv4 Address Ranges to IPv6 Prefixes The RFC 6147 [RFC6147] allows DNS64 implementations to be able to map specific IPv4 address ranges to separate Pref64::/n. That allows handling of special use IPv4 addresses [RFC5735]. The example setup where this might be used is illustrated in Figure 1. The NAT64 "A" is used when accessing IPv4-only servers in the datacenter, and the NAT64 "B" is used for Internet access. NAT64 "A" ----- IPv4-only servers in a datacenter / IPv6-only host----< \ NAT64 "B" ----- IPv4 Internet Figure 1: NAT64s with IPv4 Address Ranges The heuristic discovery method described herein does not support learning of the possible rules used by DNS64 server for mapping specific IPv4 address ranges to separate Pref64::/n. Therefore, nodes will use the same discovered Pref64::/n to synthesize IPv6 addresses out from any IPv4 address. The operator of the NAT64 and the DNS64 ought to take this into account in the network design and support routing, even if not optimal, of the packets nodes have synthesized by combining the discovered Pref64::/n and the IPv4 address nodes have learned via DNS or obtained as referrals. The network operators can help IPv6-only hosts by ensuring the IPv6- hosts do not have to work with IPv4 address literals. That is, the IPv4-only servers ought to have signed AAAA records, which allows IPv6-only hosts to avoid local address synthesis. If the IPv6-only hosts are not using DNSSEC, then it is enough if the network's DNS64=20 server returns synthetic AAAA resource records pointing to IPv4-only ser= vers If the IPv6-only host has no other choice than use IPv4-address literals and perform local synthesis by using the discovered Pref64::/n, then the network ought to ensure with routing that the packets are delivered to the correct NAT64. For example, a router in the path from IPv6-only host to NAT64s can forward the IPv6 packets to correct NAT64 as illustrated in Figure 2. The routing could be based on the last 32-bits of the IPv6 address, but the network operator can also use some other IPv6 address format allowed by RFC 6052 [RFC6052= ], if it simplifies routing setup. NAT64 "A" ----- IPv4-only servers in a datacenter / IPv6-only host----router \ NAT64 "B" ----- IPv4 Internet Figure 2: NAT64s with Assisting Router -----end-------- Some comments also inline. Best regards, Teemu > -----Original Message----- > From: ext Dmitry Anipko [mailto:Dmitry.Anipko@microsoft.com] > Sent: 28. kes=E4kuuta 2012 03:14 > To: Savolainen Teemu (Nokia-NRC/Tampere); Dave Thaler; behave@ietf.org > Subject: RE: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuris= tic- > 09 >=20 > Hi Teemu, >=20 > >>> It is true that this would not work if the host gets a special use > > IPv4 address literal from somewhere, but how common is that? >=20 > If there are use cases for draft-ietf-behave-nat64-discovery-heuristic-09= , same > use cases if they make sense in e.g. enterprise network using RFC 1918 > addresses, in such network will result in 10.* literals. Do use cases of = draft- > ietf-behave-nat64-discovery-heuristic-09 apply to enterprise networks (or > homenet) or other networks, which have legacy parts using RFC 1918 space? > E.g. a network which has new IPv6-only segment, and some legacy > segment/servers with IPv4 addressing, to which IPv6 only can only connect > using DNS64/NAT64? We have not limited this to particular deployments or ruled scenarios out. = Please see above text that ought to help. I.e., in a network that has IPv6-= only segment, it would be wise to have proper AAAA records also for the IPv= 4-only servers, not use DNSSEC, or have routing system assisting as describ= ed. > If people are deploying such configurations, and there is a way to make t= hem > work without breaking connectivity, then the only consideration is whethe= r it > is acceptable to require that the network which the node visits needs to = be re- > configured in order for the node to be able to use the heuristic. If it i= s > acceptable, I think the text you proposed would benefit if it is elaborat= ed how > the network shall be designed to handle this case, but otherwise it looks= good > to me. There should now be proposal on how the network should be designed to work = with this tool. I do not think it is a tough requirement to require network reconfiguration= (e.g. routing, or DNS records to be created), as currently IPv6-only hosts= would not be able to connect there at all (due lack of prefix discovery an= d local synthesis capability).=20 Maybe in some networks, e.g. enterprise with tight administration framework= s and IPv4-only pockets, it might also be useful to be able to deliver deta= iled mapping rules to hosts, but I would assume in such scenarios some othe= r administrative protocols could be used? Best regards, Teemu From teemu.savolainen@nokia.com Thu Jun 28 03:09:38 2012 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 A668621F87DE for ; Thu, 28 Jun 2012 03:09:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 S-ayYxOVWI1z for ; Thu, 28 Jun 2012 03:09:38 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 85FD721F8868 for ; Thu, 28 Jun 2012 00:48:05 -0700 (PDT) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q5S7lx9w010399; Thu, 28 Jun 2012 10:48:00 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.57]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 28 Jun 2012 10:48:09 +0300 Received: from 008-AM1MPN1-053.mgdnok.nokia.com ([169.254.3.74]) by 008-AM1MMR1-002.mgdnok.nokia.com ([65.54.30.57]) with mapi id 14.02.0283.004; Thu, 28 Jun 2012 09:47:58 +0200 From: To: , Thread-Topic: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09 Thread-Index: AQHNVGW0nV8ELkaGokCA2SiRbffcqZcOEWiAgABrVvCAAB1igIAAAkiAgAAF6oCAALjDYA== Date: Thu, 28 Jun 2012 07:47:58 +0000 Message-ID: <916CE6CF87173740BC8A2CE443096962043C9DD9@008-AM1MPN1-053.mgdnok.nokia.com> References: <9B57C850BB53634CACEC56EF4853FF653B62BDA4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B66483D@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <4FE250F5.5010505@acm.org> <916CE6CF87173740BC8A2CE443096962043AF580@008-AM1MPN1-053.mgdnok.nokia.com> <4FEA3758.40203@acm.org> <916CE6CF87173740BC8A2CE443096962043BF32C@008-AM1MPN1-052.mgdnok.nokia.com> <4FEB1317.1080905@acm.org> <916CE6CF87173740BC8A2CE443096962043BF6A2@008-AM1MPN1-052.mgdnok.nokia.com> <4FEB85C7.20903@acm.org> <9B57C850BB53634CACEC56EF4853FF653B67BCAB@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <4FEB8CA7.3000000@acm.org> In-Reply-To: <4FEB8CA7.3000000@acm.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.163.23.252] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 28 Jun 2012 07:48:09.0063 (UTC) FILETIME=[5C4F9F70:01CD5502] X-Nokia-AV: Clean Cc: behave@ietf.org Subject: Re: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09 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, 28 Jun 2012 10:09:38 -0000 PiBObywgYnV0IFNJUCBhbmQgU0RQIGxvb2sgbGlrZSBnb29kIGNhbmRpZGF0ZXMgZm9yIHByb3Rv Y29scyBjYXJyeWluZyBJUHY0DQo+IGFkZHJlc3NlcyB0aGF0IHdvdWxkIHJlcXVpcmUgdG8gYmUg Y29udmVydGVkIHRvIElQdjYgYWRkcmVzc2VzIGluIGEgTkFUNjQNCj4gZW52aXJvbm1lbnQsIGFu ZCBhcHBsaWNhdGlvbnMgdXNpbmcgdGhlc2UgcHJvdG9jb2xzIGFyZSBnZW5lcmFsbHkgbm90IHJ1 bg0KPiB1bmRlciByb290Lg0KDQpJbiB0aGUgY2FzZSBvZiBTSVAsIG9uY2UgdGhlIGNsaWVudCBn ZXRzIElQdjQgYWRkcmVzc2VzIHdpdGggU0RQLCB0aGUgY2xpZW50IGNhbiB0aGVuIHN5bnRoZXNp emUgKHNldCBvZikgSVB2NiBhZGRyZXNzZXMgYW5kIHVzZSB0aGVtIGFzIGNhbmRpZGF0ZSBhZGRy ZXNzZXMgYWxvbmdzaWRlIG90aGVyIGNhbmRpZGF0ZSBhZGRyZXNzZXMsIHJpZ2h0PyBUaGUgSUNF IHByb2NlZHVyZSB3aWxsIHRoZW4gdGVsbCBpZiAoc29tZSBvZikgdGhlIHN5bnRoZXRpYyBhZGRy ZXNzZXMgeWllbGRzIGluIHdvcmtpbmcgY29ubmVjdGlvbiBvciBub3QuDQoNCkhlbmNlIGVzcGVj aWFsbHkgZm9yIFNJUC9JQ0UtdXNpbmcgYXBwcyB3ZSBkbyBub3QgbmVlZCBhbnkgZGVkaWNhdGVk IGNvbm5lY3Rpdml0eSBjaGVjayBzZXJ2ZXJzIGFzIHRoZSBjb25uZWN0aXZpdHkgY2hlY2sgc3lz dGVtIGlzIGFscmVhZHkgaW5idWlsdCB3aXRoIElDRSwgcmlnaHQ/DQoNCkJlc3QgcmVnYXJkcywN Cg0KICAgICAgICBUZWVtdQ0K From petithug@acm.org Thu Jun 28 07:55:40 2012 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 1749C21F857D for ; Thu, 28 Jun 2012 07:55:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.010, 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 FBj2L4PVxeKV for ; Thu, 28 Jun 2012 07:55:38 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id C4B0721F857A for ; Thu, 28 Jun 2012 07:55:38 -0700 (PDT) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 7CCF8204C6; Thu, 28 Jun 2012 14:55:36 +0000 (UTC) Message-ID: <4FEC7066.50204@acm.org> Date: Thu, 28 Jun 2012 07:55:34 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.5) Gecko/20120624 Icedove/10.0.5 MIME-Version: 1.0 To: teemu.savolainen@nokia.com References: <9B57C850BB53634CACEC56EF4853FF653B62BDA4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B66483D@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <4FE250F5.5010505@acm.org> <916CE6CF87173740BC8A2CE443096962043AF580@008-AM1MPN1-053.mgdnok.nokia.com> <4FEA3758.40203@acm.org> <916CE6CF87173740BC8A2CE443096962043BF32C@008-AM1MPN1-052.mgdnok.nokia.com> <4FEB1317.1080905@acm.org> <916CE6CF87173740BC8A2CE443096962043BF6A2@008-AM1MPN1-052.mgdnok.nokia.com> <4FEB85C7.20903@acm.org> <9B57C850BB53634CACEC56EF4853FF653B67BCAB@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <4FEB8CA7.3000000@acm.org> <916CE6CF87173740BC8A2CE443096962043C9DD9@008-AM1MPN1-053.mgdnok.nokia.com> In-Reply-To: <916CE6CF87173740BC8A2CE443096962043C9DD9@008-AM1MPN1-053.mgdnok.nokia.com> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: behave@ietf.org, dthaler@microsoft.com Subject: Re: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09 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, 28 Jun 2012 14:55:40 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 06/28/2012 12:47 AM, teemu.savolainen@nokia.com wrote: >> No, but SIP and SDP look like good candidates for protocols carrying IPv4 >> addresses that would require to be converted to IPv6 addresses in a NAT64 >> environment, and applications using these protocols are generally not run >> under root. > > In the case of SIP, once the client gets IPv4 addresses with SDP, the client can then synthesize (set of) IPv6 addresses and use them as candidate addresses alongside other candidate addresses, right? The ICE procedure will then tell if (some of) the synthetic addresses yields in working connection or not. > > Hence especially for SIP/ICE-using apps we do not need any dedicated connectivity check servers as the connectivity check system is already inbuilt with ICE, right? You are right. - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJP7HBkAAoJECnERZXWan7ES9UP/35/WuWET282G2k0DnC5+uCg rOT3PFDH3wEls+nj8wgjd8hcQ0ysK1IeGFPIFE/Q99QbzMp9gnCCcjeWsU/5TAhO 6hr6drFVS5+XGxBEo8nzMlziCiIJS8QwPcaB6DMOtAwj75zKfwN1pTj4aBSKpkAQ gOkcaVRCwrenoVzjVHAZJxNXpkxA/1IZQUrrei9bz+BJZ2+zUmYPqe4cEUAtSsUX V4YUPejj0HpBDbQJSgMRv7TYaeokiLQC3iyuepmN5CqEY+6Xk+4hPkznRsIeA2HM mtdjZQTa6y+WdHnJoplHwmTO3sw8s/ryqv47p4ng0u4NFcNXQUB50stPW+rltgQI kDzS6svNji5LSjBrPf0YY0bQi5SQn3hsPB9cxteEkHCD5osFNO7jun7q4/H6+338 h5s2QSGzqvKw54K6JgaHIAjjD7LMDNM0KIdS4W8Qlvk3JuNGVCFQ6pi17oXHXSjh dTWjDTVl9Li0nDsthe0u334+nvj8KhorEoUNsP1ji+H35G3Y1CpLhDUonQt1D17c fXTUGzNgHLkNuOVeCLF70YQsD01tAWs8Qpp2816BbK23SyT6+DRImL5h2DpqrPLh IAurjbxkEAc/2GNvk4vmL2tJdJDY74j/s01pnTopVS0LR4NUNhcpXvsx3nW0K2F7 gweiwV04LVfJ9RgdWOAX =9yXu -----END PGP SIGNATURE----- From dwing@cisco.com Thu Jun 28 10:39:54 2012 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 34B3A21F85C6 for ; Thu, 28 Jun 2012 10:39:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.424 X-Spam-Level: X-Spam-Status: No, score=-110.424 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 kpFAfiz-CIKC for ; Thu, 28 Jun 2012 10:39:53 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 429DC21F85A0 for ; Thu, 28 Jun 2012 10:39:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=4167; q=dns/txt; s=iport; t=1340905193; x=1342114793; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=sYtcxJZCO7mYOhGWLGUrQ5erFAWHlnhFygwnj1sOT/0=; b=MNx4QMXmxd6EMk+AMaA89o5GDbEODbffQJlPVMdr+fL8gnlJk3kQ8Gs9 LQNk2nGH3dQV4oTF5r275ae97kaARLTlAdaSq73qLN0+t1covSdyj58GH UMokhbshK+GEAnVBruuUL6GDLg5lUWNgUSUfT7mUy3lA8hfLM3451ZmSJ A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkIFAPyV7E+rRDoJ/2dsb2JhbABFpzuOcIEHghgBAQEDAQgKARcQRAcBAwIJDwIEAQEoBxkjCgkIAgQBEgsQB4dkBJhQoGKLN4YKA4hKhQOId40LgWaCf4E4Iw X-IronPort-AV: E=Sophos;i="4.77,493,1336348800"; d="scan'208";a="50405584" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 28 Jun 2012 17:39:52 +0000 Received: from dwingWS ([10.32.240.194]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q5SHdqbB005882; Thu, 28 Jun 2012 17:39:52 GMT From: "Dan Wing" To: , , , References: <9B57C850BB53634CACEC56EF4853FF653B62BDA4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B66483D@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <96DD85EB136DCD49AB5CDB6DEC9639AD068597EA@CH1PRD0310MB368.namprd03.prod.outlook.com> <916CE6CF87173740BC8A2CE443096962043BE42D@008-AM1MPN1-052.mgdnok.nokia.com> <96DD85EB136DCD49AB5CDB6DEC9639AD0685BB90@CH1PRD0310MB368.namprd03.prod.outlook.com> <916CE6CF87173740BC8A2CE443096962043BE62F@008-AM1MPN1-052.mgdnok.nokia.com> <916CE6CF87173740BC8A2CE443096962043BF2D0@008-AM1MPN1-052.mgdnok.nokia.com> <96DD85EB136DCD49AB5CDB6DEC9639AD06860E45@CH1PRD0310MB368.namprd03.prod.outlook.com> <075601cd54cc$0a8396f0$1f8ac4d0$@com> <916CE6CF87173740BC8A2CE443096962043C8C69@008-AM1MPN1-053.mgdnok.nokia.com> In-Reply-To: <916CE6CF87173740BC8A2CE443096962043C8C69@008-AM1MPN1-053.mgdnok.nokia.com> Date: Thu, 28 Jun 2012 10:39:52 -0700 Message-ID: <09fb01cd5555$0617b310$12471930$@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: AQHNU8vMJW0v97C6d0anvYXMmpcItJcOIT1wgACbboCAABJKAIAAeLuwgAC6ZtA= Content-Language: en-us Subject: Re: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09 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, 28 Jun 2012 17:39:54 -0000 > -----Original Message----- > From: teemu.savolainen@nokia.com [mailto:teemu.savolainen@nokia.com] > Sent: Wednesday, June 27, 2012 11:49 PM > To: dwing@cisco.com; Dmitry.Anipko@microsoft.com; > dthaler@microsoft.com; behave@ietf.org > Subject: RE: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery- > heuristic-09 > > > The simple solution is declare that out of scope, and say that the > > DNS64 heuristic doesn't support unique NAT64 prefixes per IPv4 > prefix. > > I think that is what we should do - the heuristic will not discover > these mappings, and the ISP should configure their networks so that the > impact is minimal - see below about this. > > > The harder solution is to specify how to build ipv4only.arpa queries > for each > > different destination IPv4 prefix. ISPs would wildcard their > ipv4only.arpa > > resource record (attracting all destination traffic to their NAT64). > > But how many IPv4 prefixes there are... 4 billion queries to learn > mapping for all 2^32 possible /32 destinations ranges?-) > > > The idea, as I recall it, was to allow an ISP to operate two NAT64 > devices, one > > going to the Internet, the other connecting to an IPv4-only > datacenter (IMAP > > servers, WWW servers, media streamers, etc.), like this, > > > > NAT64-------IPv4-only servers in datacenter > > / > > IPv6-only host----< > > \ > > NAT64------IPv4 Internet > > This mapping of IPv4 address ranges to IPv6 addresses problem for > heuristics only in the case of NAT64 being close to the IPv6 host? > Right? Yes. > In the above example, if the setup is static, I would suggest ISP to > create signed AAAA records for the IPv4-only servers in the datacenters > (using Pref64::/n of the NAT64 above), in which case the IPv6-only > DNSSEC using host would get signed AAAA response from the DNS, and > would use that (no need for local synthesis). I.e. from host point of > view it would be talking to "real" IPv6 destination. > > Also, in the case of non-DNSSEC using IPv6-only host, it is enough that > ISP's DNS64 returns synthetic AAAA records for the servers in > datacenter. > > Now in case the ISP does not want to provide signed AAAA records for > the servers in data center, but host does DNSSEC validation (or > otherwise gets IPv4 literal), then the packets from the host could end > up using Pref64::/n of the below NAT64, and packets would be sent using > "incorrect" Pref64::/n. However, in case of ISP, why the ISP could not > have more specific routes that would ensure the packets host sends to > Pref64_of_below_NAT64:IPv4addressofdatacenter would be actually routed > to the above NAT64, and not to Internet-leading NAT64? .. . and I > notice this is what you propose below:) > > > I would declare it as acceptable. Routing on the last 32 bits of the > IPv6 _is_ > > possible, or if that is undesirable, adjust the NAT64 mapping so the > IPv4 > > address is earlier in the IPv6 address. The heuristic and the NAT64 > addressing > > format support either choice. In this way, the same NAT64 prefix is > used, but > > a router in front of the two NAT64's causes the packets to go one way > or the > > other: > > > > NAT64-------IPv4-only servers in datacenter > > / > > IPv6-only host----router > > \ > > NAT64------IPv4 Internet > > > > Appropriate filtering -- which probably is already present -- would > be needed > > on the 'other' NAT64 (e.g., so 10.0.0.0/8 doesn't appear on the > Internet- > > connected NAT64). > > Maybe I'll draw this picture into the draft to explain how this can be > made to work, if used by ISP? > > But generally I would even more prefer for ISP to ensure the IPv6-only > host does not get IPv4 address literal for its servers in datacenters, > but instead provides signed AAAA records for those servers. Sure. But we're stuck with IPv4 address literals with SIP, XMPP, and other protocols. -d From dwing@cisco.com Thu Jun 28 13:57:55 2012 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 4AC0711E8087 for ; Thu, 28 Jun 2012 13:57:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.431 X-Spam-Level: X-Spam-Status: No, score=-110.431 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 5iEBDGaENEwW for ; Thu, 28 Jun 2012 13:57:54 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 4F80321F842B for ; Thu, 28 Jun 2012 13:57:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=297; q=dns/txt; s=iport; t=1340917074; x=1342126674; h=from:to:subject:date:message-id:mime-version: content-transfer-encoding; bh=Xtb5nGqkwnt+L3nT0z/ZCIB7u+q/qlMYAqWluz9vz90=; b=ioU09UgTJm/PYrlqosHk49Sz60Qjx7pYHDlO/gVuVpwog4jO0Cd7Cu1B AROt9kJuPXd4bqdkXkenegqYQ0IZGUT1L53YjR1oZ6K/N3XMe18AWnMvr oDzazBaNemzoQsLCWAQiz9KslyQMZN1KOvZ4KVjbOkaEKJTTtNiiKJHGv A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAM/E7E+rRDoI/2dsb2JhbABFpzuPCYEHgh8ICgEXEEwFGFAjHAEEEwsXh2iXGIEooG+OJYMcA4hKhQOWAoFmgn8 X-IronPort-AV: E=Sophos;i="4.77,494,1336348800"; d="scan'208";a="50503820" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 28 Jun 2012 20:57:54 +0000 Received: from dwingWS ([10.154.161.127]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q5SKvrAj005163 for ; Thu, 28 Jun 2012 20:57:53 GMT From: "Dan Wing" To: Date: Thu, 28 Jun 2012 13:57:53 -0700 Message-ID: <0aca01cd5570$afe6d090$0fb471b0$@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: Ac1VcK+2Ho+3sToPTpKyE5g2D/2Wpw== Content-Language: en-us Subject: [BEHAVE] BEHAVE meeting at IETF84 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, 28 Jun 2012 20:57:55 -0000 We have been scheduled for one hour, Thursday, Afternoon Session III 1730-1830 Room Name: Regency E If you want to present at this session please send presenter name, length of presentation, and Internet Drafts related to your presentation to behave-chairs@tools.ietf.org. -d From Dmitry.Anipko@microsoft.com Thu Jun 28 20:40:10 2012 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 3D3F521F8639 for ; Thu, 28 Jun 2012 20:40:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.967 X-Spam-Level: X-Spam-Status: No, score=-2.967 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] 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 j99gOvDHNgfI for ; Thu, 28 Jun 2012 20:40:09 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by ietfa.amsl.com (Postfix) with ESMTP id 24D4F21F8615 for ; Thu, 28 Jun 2012 20:40:09 -0700 (PDT) Received: from mail129-tx2-R.bigfish.com (10.9.14.237) by TX2EHSOBE011.bigfish.com (10.9.40.31) with Microsoft SMTP Server id 14.1.225.23; Fri, 29 Jun 2012 03:38:21 +0000 Received: from mail129-tx2 (localhost [127.0.0.1]) by mail129-tx2-R.bigfish.com (Postfix) with ESMTP id ACA38C0495 for ; Fri, 29 Jun 2012 03:38:20 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC101.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -27 X-BigFish: VS-27(zz9371Ic89bh542M1432Izz1202hzz1033IL8275bh8275dhz2fh2a8h683h839hd25hf0ah) Received-SPF: pass (mail129-tx2: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Dmitry.Anipko@microsoft.com; helo=TK5EX14MLTC101.redmond.corp.microsoft.com ; icrosoft.com ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.244.37; KIP:(null); UIP:(null); (null); H:CH1PRD0310HT002.namprd03.prod.outlook.com; R:internal; EFV:INT Received: from mail129-tx2 (localhost.localdomain [127.0.0.1]) by mail129-tx2 (MessageSwitch) id 1340941098914310_14520; Fri, 29 Jun 2012 03:38:18 +0000 (UTC) Received: from TX2EHSMHS028.bigfish.com (unknown [10.9.14.238]) by mail129-tx2.bigfish.com (Postfix) with ESMTP id D1C9980046 for ; Fri, 29 Jun 2012 03:38:18 +0000 (UTC) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS028.bigfish.com (10.9.99.128) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 29 Jun 2012 03:38:16 +0000 Received: from CH1EHSOBE008.bigfish.com (157.54.51.113) by mail.microsoft.com (157.54.79.178) with Microsoft SMTP Server (TLS) id 14.2.298.5; Fri, 29 Jun 2012 03:40:03 +0000 Received: from mail179-ch1-R.bigfish.com (10.43.68.229) by CH1EHSOBE008.bigfish.com (10.43.70.58) with Microsoft SMTP Server id 14.1.225.23; Fri, 29 Jun 2012 03:38:14 +0000 Received: from mail179-ch1 (localhost [127.0.0.1]) by mail179-ch1-R.bigfish.com (Postfix) with ESMTP id 89B3B220353 for ; Fri, 29 Jun 2012 03:38:14 +0000 (UTC) Received: from mail179-ch1 (localhost.localdomain [127.0.0.1]) by mail179-ch1 (MessageSwitch) id 1340941092180599_13578; Fri, 29 Jun 2012 03:38:12 +0000 (UTC) Received: from CH1EHSMHS024.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.244]) by mail179-ch1.bigfish.com (Postfix) with ESMTP id 29D9740049; Fri, 29 Jun 2012 03:38:12 +0000 (UTC) Received: from CH1PRD0310HT002.namprd03.prod.outlook.com (157.56.244.37) by CH1EHSMHS024.bigfish.com (10.43.70.24) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 29 Jun 2012 03:38:12 +0000 Received: from CH1PRD0310MB368.namprd03.prod.outlook.com ([169.254.8.166]) by CH1PRD0310HT002.namprd03.prod.outlook.com ([10.255.137.37]) with mapi id 14.16.0164.004; Fri, 29 Jun 2012 03:39:59 +0000 From: Dmitry Anipko To: "teemu.savolainen@nokia.com" , Dave Thaler , "behave@ietf.org" Thread-Topic: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09 Thread-Index: AQHNU6dBHl1WqM4K4kyX71U7NkG1NpcM43GwgAAM2QCAATGJgIAAtyKggACQaoCAATllAA== Date: Fri, 29 Jun 2012 03:39:59 +0000 Message-ID: <96DD85EB136DCD49AB5CDB6DEC9639AD06863E7B@CH1PRD0310MB368.namprd03.prod.outlook.com> References: <9B57C850BB53634CACEC56EF4853FF653B62BDA4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B66483D@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <96DD85EB136DCD49AB5CDB6DEC9639AD068597EA@CH1PRD0310MB368.namprd03.prod.outlook.com> <916CE6CF87173740BC8A2CE443096962043BE42D@008-AM1MPN1-052.mgdnok.nokia.com> <96DD85EB136DCD49AB5CDB6DEC9639AD0685BB90@CH1PRD0310MB368.namprd03.prod.outlook.com> <916CE6CF87173740BC8A2CE443096962043BE62F@008-AM1MPN1-052.mgdnok.nokia.com> <916CE6CF87173740BC8A2CE443096962043BF2D0@008-AM1MPN1-052.mgdnok.nokia.com> <96DD85EB136DCD49AB5CDB6DEC9639AD06860E45@CH1PRD0310MB368.namprd03.prod.outlook.com> <916CE6CF87173740BC8A2CE443096962043C9E90@008-AM1MPN1-053.mgdnok.nokia.com> In-Reply-To: <916CE6CF87173740BC8A2CE443096962043C9E90@008-AM1MPN1-053.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.192.100] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: CH1PRD0310HT002.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%NOKIA.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%CISCO.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14MLTC101.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14MLTC101.redmond.corp.microsoft.com X-OriginatorOrg: microsoft.com Cc: Dan Wing Subject: Re: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09 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, 29 Jun 2012 03:40:10 -0000 Thanks Teemu & Dan for clarifications and suggested text. I have 3 comments= : 1. Is this a realistic recommendation for data center operators to create s= igned records for thousands of synthesized addresses of IPv4 only hosts? E.= g., are there tools which allow to do that easily and easily update in case= of network renumbering or new hosts being deployed dynamically?=20 2. I agree with you that a scenario with 2 NAT64 and shared IPv6 prefix can= be solved by routing based on prefix which includes the IPv4 ranges bits. = But my original question was somewhat different - what if there are NAT64 a= nd they serve different IPv4 address ranges, mapped to *different* Pref64/n= .=20 I don't yet see how routing alone helps there. Perhaps I'm missing somethin= g, so let me give an example - let's say the mappings table is A4_1 -> Pref= 64_1/n (for NAT64_1, path to Internet), A4_2 -> Pref64_2/n (for NAT64_2, pa= th to datacenter), and heuristic for a packet destined to A4_1 incorrectly = formed Pref64_2:A4_1 as IPv6 destination address. If the IPv6 network has only Pref64_1/n and Pref64_2/n routes, then such pa= cket Pref64_2:A4_1 will be routed to NAT64_2, which either will drop the pa= cket (if it verifies that IPv4 is in the allowed range for the used IPv6 pr= efix), or will translate it to A4_1, and send packet destined to Internet i= nto datacenter network, that may not go anywhere. If the network has also Pref64_2:A4_1 -> NAT64_1 route, to compensate for h= euristic lack of support of mappings, such route will bring the packet to N= AT64_1, but again, unless NAT64_1 has a configuration for route Pref64_2, N= AT64_1 will not know how to translate Pref64_2:A4_1 -> A4_1 and may drop th= e packet. So is the assumption/suggestion that in addition to routing which include I= Pv4 ranges bits, all NAT64s are configured with shared configuration, so th= at they know about each other prefixes? Or the assumption is that one would= never want to have Pref64_2 !=3D Pref64_1, and just one shared Pref64 is s= ufficient always? 3. If the heuristic is a documented kludge - what are the reasons it is put= on the standards track instead of informational/experimental? Thank you, Dmitry -----Original Message----- From: teemu.savolainen@nokia.com [mailto:teemu.savolainen@nokia.com]=20 Sent: Thursday, June 28, 2012 1:31 AM To: Dmitry Anipko; Dave Thaler; behave@ietf.org Subject: RE: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristi= c-09 Hi Dmitry, Based on your and Dan's email, I updated the section to look as following: -----start------- 5.1. Mapping of IPv4 Address Ranges to IPv6 Prefixes The RFC 6147 [RFC6147] allows DNS64 implementations to be able to map specific IPv4 address ranges to separate Pref64::/n. That allows handling of special use IPv4 addresses [RFC5735]. The example setup where this might be used is illustrated in Figure 1. The NAT64 "A" is used when accessing IPv4-only servers in the datacenter, and the NAT64 "B" is used for Internet access. NAT64 "A" ----- IPv4-only servers in a datacenter / IPv6-only host----< \ NAT64 "B" ----- IPv4 Internet Figure 1: NAT64s with IPv4 Address Ranges The heuristic discovery method described herein does not support learning of the possible rules used by DNS64 server for mapping specific IPv4 address ranges to separate Pref64::/n. Therefore, nodes will use the same discovered Pref64::/n to synthesize IPv6 addresses out from any IPv4 address. The operator of the NAT64 and the DNS64 ought to take this into account in the network design and support routing, even if not optimal, of the packets nodes have synthesized by combining the discovered Pref64::/n and the IPv4 address nodes have learned via DNS or obtained as referrals. The network operators can help IPv6-only hosts by ensuring the IPv6- hosts do not have to work with IPv4 address literals. That is, the IPv4-only servers ought to have signed AAAA records, which allows IPv6-only hosts to avoid local address synthesis. If the IPv6-only hosts are not using DNSSEC, then it is enough if the network's DNS64=20 server returns synthetic AAAA resource records pointing to IPv4-only ser= vers If the IPv6-only host has no other choice than use IPv4-address literals and perform local synthesis by using the discovered Pref64::/n, then the network ought to ensure with routing that the packets are delivered to the correct NAT64. For example, a router in the path from IPv6-only host to NAT64s can forward the IPv6 packets to correct NAT64 as illustrated in Figure 2. The routing could be based on the last 32-bits of the IPv6 address, but the network operator can also use some other IPv6 address format allowed by RFC 6052 [RFC6052= ], if it simplifies routing setup. NAT64 "A" ----- IPv4-only servers in a datacenter / IPv6-only host----router \ NAT64 "B" ----- IPv4 Internet Figure 2: NAT64s with Assisting Router -----end-------- Some comments also inline. Best regards, Teemu > -----Original Message----- > From: ext Dmitry Anipko [mailto:Dmitry.Anipko@microsoft.com] > Sent: 28. kes=E4kuuta 2012 03:14 > To: Savolainen Teemu (Nokia-NRC/Tampere); Dave Thaler; behave@ietf.org > Subject: RE: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuris= tic- > 09 >=20 > Hi Teemu, >=20 > >>> It is true that this would not work if the host gets a special use > > IPv4 address literal from somewhere, but how common is that? >=20 > If there are use cases for draft-ietf-behave-nat64-discovery-heuristic-09= , same > use cases if they make sense in e.g. enterprise network using RFC 1918 > addresses, in such network will result in 10.* literals. Do use cases of = draft- > ietf-behave-nat64-discovery-heuristic-09 apply to enterprise networks (or > homenet) or other networks, which have legacy parts using RFC 1918 space? > E.g. a network which has new IPv6-only segment, and some legacy > segment/servers with IPv4 addressing, to which IPv6 only can only connect > using DNS64/NAT64? We have not limited this to particular deployments or ruled scenarios out. = Please see above text that ought to help. I.e., in a network that has IPv6-= only segment, it would be wise to have proper AAAA records also for the IPv= 4-only servers, not use DNSSEC, or have routing system assisting as describ= ed. > If people are deploying such configurations, and there is a way to make t= hem > work without breaking connectivity, then the only consideration is whethe= r it > is acceptable to require that the network which the node visits needs to = be re- > configured in order for the node to be able to use the heuristic. If it i= s > acceptable, I think the text you proposed would benefit if it is elaborat= ed how > the network shall be designed to handle this case, but otherwise it looks= good > to me. There should now be proposal on how the network should be designed to work = with this tool. I do not think it is a tough requirement to require network reconfiguration= (e.g. routing, or DNS records to be created), as currently IPv6-only hosts= would not be able to connect there at all (due lack of prefix discovery an= d local synthesis capability).=20 Maybe in some networks, e.g. enterprise with tight administration framework= s and IPv4-only pockets, it might also be useful to be able to deliver deta= iled mapping rules to hosts, but I would assume in such scenarios some othe= r administrative protocols could be used? Best regards, Teemu From teemu.savolainen@nokia.com Thu Jun 28 23:42:45 2012 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 42F0111E80D9 for ; Thu, 28 Jun 2012 23:42:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 LYYbGcdvRyBO for ; Thu, 28 Jun 2012 23:42:44 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 2C02B11E80CA for ; Thu, 28 Jun 2012 23:42:43 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (in-mx.nokia.com [10.160.244.31]) by mgw-da01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q5T6fDxP015922; Fri, 29 Jun 2012 09:42:35 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.58]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 29 Jun 2012 09:42:15 +0300 Received: from 008-AM1MPN1-053.mgdnok.nokia.com ([169.254.3.74]) by 008-AM1MMR1-003.mgdnok.nokia.com ([65.54.30.58]) with mapi id 14.02.0283.004; Fri, 29 Jun 2012 08:42:04 +0200 From: To: , , Thread-Topic: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09 Thread-Index: Ac1VwN5gQvCJ4VnISuanj5twaYDwKg== Date: Fri, 29 Jun 2012 06:42:04 +0000 Message-ID: <916CE6CF87173740BC8A2CE443096962043CBA2B@008-AM1MPN1-053.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.163.27.176] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 29 Jun 2012 06:42:15.0981 (UTC) FILETIME=[5280EDD0:01CD55C2] X-Nokia-AV: Clean Cc: dwing@cisco.com Subject: Re: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09 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, 29 Jun 2012 06:42:45 -0000 Hi Dmitry, > 1. Is this a realistic recommendation for data center operators to create > signed records for thousands of synthesized addresses of IPv4 only hosts? > E.g., are there tools which allow to do that easily and easily update in = case of > network renumbering or new hosts being deployed dynamically? Why the operator who creates thousands of (signed) A records for those IPv4= only hosts couldn't create also (signed) AAAA records for the said hosts? = Or are those hosts such that they all update their own DNS records?=20 > 2. I agree with you that a scenario with 2 NAT64 and shared IPv6 prefix c= an be > solved by routing based on prefix which includes the IPv4 ranges bits. Bu= t my > original question was somewhat different - what if there are NAT64 and th= ey > serve different IPv4 address ranges, mapped to *different* Pref64/n. If the network does not provide the routing assistance, does not provide AA= AA DNS records for those hosts, then I suppose the packets do not go to the= right destination. Maybe the operator who has that kind of limitations should not introduce IP= v6-only pockets to their network at the first place:-) > I don't yet see how routing alone helps there. Perhaps I'm missing someth= ing, > so let me give an example - let's say the mappings table is A4_1 -> Pref6= 4_1/n > (for NAT64_1, path to Internet), A4_2 -> Pref64_2/n (for NAT64_2, path to > datacenter), and heuristic for a packet destined to A4_1 incorrectly form= ed > Pref64_2:A4_1 as IPv6 destination address. The DNS64 of the network would give Pref64_1 as the prefix for ipv4only.arp= a, so wouldn't the incorrectly formed address be instead Pref61:2:A4_2? (Th= is is detail, I got the idea). > If the IPv6 network has only Pref64_1/n and Pref64_2/n routes, then such > packet Pref64_2:A4_1 will be routed to NAT64_2, which either will drop th= e > packet (if it verifies that IPv4 is in the allowed range for the used IPv= 6 prefix), > or will translate it to A4_1, and send packet destined to Internet into > datacenter network, that may not go anywhere. Yes, that's why we proposed the router to choose the right NAT64 based on t= he IPv4 address, or to avoid IPv4 literals that provide these kinds of mine= s. Special use IPv4 literals have serious issues already in the traditional= IPv4-only setups. > If the network has also Pref64_2:A4_1 -> NAT64_1 route, to compensate for > heuristic lack of support of mappings, such route will bring the packet t= o > NAT64_1, but again, unless NAT64_1 has a configuration for route Pref64_2= , > NAT64_1 will not know how to translate Pref64_2:A4_1 -> A4_1 and may > drop the packet. Right, the datacenter NAT64s would need to be configured to accept packets = for translation that come with Internet NAT64's Pref64::/n.=20 Now that I think of this more, maybe the bigger problem would be actually i= n the return direction, as the datacenter's NAT64 would need to be clever o= n what is the Pref64::/n it needs to use for a packet going back to the hos= t - the NAT64 could not use it's "default" Pref64_2, but would have to use = Pref64_1 the IPv6-only host chosen to use. This likely creates additional s= tate. > So is the assumption/suggestion that in addition to routing which include= IPv4 > ranges bits, all NAT64s are configured with shared configuration, so that= they > know about each other prefixes?=20 This was the assumption in the range-support proposal, yes. >Or the assumption is that one would never > want to have Pref64_2 !=3D Pref64_1, and just one shared Pref64 is suffic= ient > always? Maybe that is needed with the heuristics-based approach, for addresses that= are delivered as IPv4 literals to hosts. I try to clarify these restrictio= ns of the heuristic-tool to the draft.=20 > 3. If the heuristic is a documented kludge - what are the reasons it is p= ut on > the standards track instead of informational/experimental? What is the DNS64/NAT64 framework but a documented kludge? The stds track w= as agreed on the chartering phase and I think it is justified as we need e.= g. globally hosted IPv4-only name, ipv4only.arpa. Best regards, Teemu From internet-drafts@ietf.org Fri Jun 29 00:46:04 2012 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 3217321F86B9; Fri, 29 Jun 2012 00:46:04 -0700 (PDT) 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=[AWL=0.000, 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 l7R9uTM5zOmH; Fri, 29 Jun 2012 00:46:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8258A21F86B0; Fri, 29 Jun 2012 00:46:03 -0700 (PDT) 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: 4.21p1 Message-ID: <20120629074603.10620.85934.idtracker@ietfa.amsl.com> Date: Fri, 29 Jun 2012 00:46:03 -0700 Cc: behave@ietf.org Subject: [BEHAVE] I-D Action: draft-ietf-behave-nat64-discovery-heuristic-10.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, 29 Jun 2012 07:46:04 -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 Avoida= nce Working Group of the IETF. Title : Discovery of IPv6 Prefix Used for IPv6 Address Synthesis Author(s) : Teemu Savolainen Jouni Korhonen Dan Wing Filename : draft-ietf-behave-nat64-discovery-heuristic-10.txt Pages : 19 Date : 2012-06-29 Abstract: This document describes a method for detecting the presence of DNS64 and for learning the IPv6 prefix used for protocol translation on an access network. The method depends on the existence of a well-known IPv4-only domain name "ipv4only.arpa". The information learned enables nodes to perform local IPv6 address synthesis and to potentially avoid NAT64 on dual-stack and multi-interface deployments. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-behave-nat64-discovery-heuristic There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-behave-nat64-discovery-heuristic-10 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-behave-nat64-discovery-heur= istic-10 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From teemu.savolainen@nokia.com Fri Jun 29 01:18:35 2012 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 76FF621F86AB for ; Fri, 29 Jun 2012 01:18:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 bFN04-6UBe6u for ; Fri, 29 Jun 2012 01:18:33 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id C27EF21F86AA for ; Fri, 29 Jun 2012 01:18:31 -0700 (PDT) Received: from vaebh101.NOE.Nokia.com (in-mx.nokia.com [10.160.244.22]) by mgw-da02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q5T8ISEm032409 for ; Fri, 29 Jun 2012 11:18:30 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.56]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 29 Jun 2012 11:18:39 +0300 Received: from 008-AM1MPN1-053.mgdnok.nokia.com ([169.254.3.74]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.02.0283.004; Fri, 29 Jun 2012 10:18:27 +0200 From: To: Thread-Topic: [BEHAVE] I-D Action: draft-ietf-behave-nat64-discovery-heuristic-10.txt Thread-Index: AQHNVcs/Td3AkFaSsE+024ci5EJfE5cQ88Kw Date: Fri, 29 Jun 2012 08:18:27 +0000 Message-ID: <916CE6CF87173740BC8A2CE443096962043CBCA3@008-AM1MPN1-053.mgdnok.nokia.com> References: <20120629074603.10620.85934.idtracker@ietfa.amsl.com> In-Reply-To: <20120629074603.10620.85934.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.163.27.176] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 29 Jun 2012 08:18:39.0051 (UTC) FILETIME=[C97B61B0:01CD55CF] X-Nokia-AV: Clean Subject: Re: [BEHAVE] I-D Action: draft-ietf-behave-nat64-discovery-heuristic-10.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, 29 Jun 2012 08:18:35 -0000 Hi behave, Here's the version that contains updates, except the appendix change, that = we discussed in the interim meeting. Please use this as a baseline for further 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: 29. kes=E4kuuta 2012 10:46 > To: i-d-announce@ietf.org > Cc: behave@ietf.org > Subject: [BEHAVE] I-D Action: draft-ietf-behave-nat64-discovery-heuristic= - > 10.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 : Discovery of IPv6 Prefix Used for IPv6 Address Sy= nthesis > Author(s) : Teemu Savolainen > Jouni Korhonen > Dan Wing > Filename : draft-ietf-behave-nat64-discovery-heuristic-10.tx= t > Pages : 19 > Date : 2012-06-29 > > Abstract: > This document describes a method for detecting the presence of DNS64 > and for learning the IPv6 prefix used for protocol translation on an > access network. The method depends on the existence of a well-known > IPv4-only domain name "ipv4only.arpa". The information learned > enables nodes to perform local IPv6 address synthesis and to > potentially avoid NAT64 on dual-stack and multi-interface > deployments. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-behave-nat64-discovery-heuris= tic > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-behave-nat64-discovery-heuristic-10 > > A diff from previous version is available at: > http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-behave-nat64-discovery-he= uristic- > 10 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From Dmitry.Anipko@microsoft.com Fri Jun 29 20:45:00 2012 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 2D92911E80C1 for ; Fri, 29 Jun 2012 20:45:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.592 X-Spam-Level: X-Spam-Status: No, score=-1.592 tagged_above=-999 required=5 tests=[AWL=-1.125, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132] 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 w+L0G2Be1Hbh for ; Fri, 29 Jun 2012 20:44:59 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe005.messaging.microsoft.com [216.32.180.31]) by ietfa.amsl.com (Postfix) with ESMTP id 21D7711E80A0 for ; Fri, 29 Jun 2012 20:44:59 -0700 (PDT) Received: from mail197-va3-R.bigfish.com (10.7.14.244) by VA3EHSOBE014.bigfish.com (10.7.40.64) with Microsoft SMTP Server id 14.1.225.23; Sat, 30 Jun 2012 03:43:07 +0000 Received: from mail197-va3 (localhost [127.0.0.1]) by mail197-va3-R.bigfish.com (Postfix) with ESMTP id 909813604BA for ; Sat, 30 Jun 2012 03:43:07 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -26 X-BigFish: VS-26(zz9371I542Mzz1202hzz1033IL8275bh8275dhz2fh2a8h683h839h944hd25hf0ah) Received-SPF: pass (mail197-va3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Dmitry.Anipko@microsoft.com; helo=TK5EX14MLTC102.redmond.corp.microsoft.com ; icrosoft.com ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.244.37; KIP:(null); UIP:(null); (null); H:CH1PRD0310HT005.namprd03.prod.outlook.com; R:internal; EFV:INT Received: from mail197-va3 (localhost.localdomain [127.0.0.1]) by mail197-va3 (MessageSwitch) id 1341027785242492_23757; Sat, 30 Jun 2012 03:43:05 +0000 (UTC) Received: from VA3EHSMHS031.bigfish.com (unknown [10.7.14.254]) by mail197-va3.bigfish.com (Postfix) with ESMTP id 2B2C94E005D for ; Sat, 30 Jun 2012 03:43:05 +0000 (UTC) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS031.bigfish.com (10.7.99.41) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sat, 30 Jun 2012 03:43:04 +0000 Received: from CH1EHSOBE007.bigfish.com (157.54.51.81) by mail.microsoft.com (157.54.79.180) with Microsoft SMTP Server (TLS) id 14.2.298.5; Sat, 30 Jun 2012 03:44:54 +0000 Received: from mail187-ch1-R.bigfish.com (10.43.68.233) by CH1EHSOBE007.bigfish.com (10.43.70.57) with Microsoft SMTP Server id 14.1.225.23; Sat, 30 Jun 2012 03:43:02 +0000 Received: from mail187-ch1 (localhost [127.0.0.1]) by mail187-ch1-R.bigfish.com (Postfix) with ESMTP id 8434F3C049B for ; Sat, 30 Jun 2012 03:43:02 +0000 (UTC) Received: from mail187-ch1 (localhost.localdomain [127.0.0.1]) by mail187-ch1 (MessageSwitch) id 1341027780347572_7140; Sat, 30 Jun 2012 03:43:00 +0000 (UTC) Received: from CH1EHSMHS009.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.236]) by mail187-ch1.bigfish.com (Postfix) with ESMTP id 52A07E00D7; Sat, 30 Jun 2012 03:43:00 +0000 (UTC) Received: from CH1PRD0310HT005.namprd03.prod.outlook.com (157.56.244.37) by CH1EHSMHS009.bigfish.com (10.43.70.9) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sat, 30 Jun 2012 03:43:00 +0000 Received: from CH1PRD0310MB368.namprd03.prod.outlook.com ([169.254.8.166]) by CH1PRD0310HT005.namprd03.prod.outlook.com ([10.255.137.40]) with mapi id 14.16.0152.000; Sat, 30 Jun 2012 03:44:50 +0000 From: Dmitry Anipko To: "teemu.savolainen@nokia.com" , Dave Thaler , "behave@ietf.org" Thread-Topic: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09 Thread-Index: Ac1VwN5g5K5itr7CkE6hut5veGXCuQAsM/BA Date: Sat, 30 Jun 2012 03:44:50 +0000 Message-ID: <96DD85EB136DCD49AB5CDB6DEC9639AD06866A8E@CH1PRD0310MB368.namprd03.prod.outlook.com> References: <916CE6CF87173740BC8A2CE443096962043CBA2B@008-AM1MPN1-053.mgdnok.nokia.com> In-Reply-To: <916CE6CF87173740BC8A2CE443096962043CBA2B@008-AM1MPN1-053.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.192.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: CH1PRD0310HT005.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%NOKIA.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%CISCO.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14MLTC102.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14MLTC102.redmond.corp.microsoft.com X-OriginatorOrg: microsoft.com Cc: "dwing@cisco.com" Subject: Re: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09 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: Sat, 30 Jun 2012 03:45:00 -0000 Hi Teemu, I've read the section on this topic you've added to the -10 revision, I gue= ss it addresses the issue to the extent it can be addressed in the framewor= k of the current draft without introducing full solution for prefixes disco= very. Thank you for adding the section. >> Or are those hosts such that they all update their own DNS records? To my knowledge, there are such networks with trust between hosts and DNS s= ystem. >> The stds track was agreed on the chartering phase and I think it is just= ified as we need e.g. globally hosted IPv4-only name, ipv4only.arpa. I don't mean to rathole on this, but if ipv4only.arpa name is the only reas= on, then perhaps alternative could be to have a separate small standards tr= ack doc introducing such name, which can be used for various things in the = future, not just this particular heuristic. The rest of the document then w= ouldn't have to be standards track. Thank you, Dmitry -----Original Message----- From: teemu.savolainen@nokia.com [mailto:teemu.savolainen@nokia.com]=20 Sent: Thursday, June 28, 2012 11:42 PM To: Dmitry Anipko; Dave Thaler; behave@ietf.org Cc: dwing@cisco.com Subject: RE: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristi= c-09 Hi Dmitry, > 1. Is this a realistic recommendation for data center operators to create > signed records for thousands of synthesized addresses of IPv4 only hosts? > E.g., are there tools which allow to do that easily and easily update in = case of > network renumbering or new hosts being deployed dynamically? Why the operator who creates thousands of (signed) A records for those IPv4= only hosts couldn't create also (signed) AAAA records for the said hosts? = Or are those hosts such that they all update their own DNS records?=20 > 2. I agree with you that a scenario with 2 NAT64 and shared IPv6 prefix c= an be > solved by routing based on prefix which includes the IPv4 ranges bits. Bu= t my > original question was somewhat different - what if there are NAT64 and th= ey > serve different IPv4 address ranges, mapped to *different* Pref64/n. If the network does not provide the routing assistance, does not provide AA= AA DNS records for those hosts, then I suppose the packets do not go to the= right destination. Maybe the operator who has that kind of limitations should not introduce IP= v6-only pockets to their network at the first place:-) > I don't yet see how routing alone helps there. Perhaps I'm missing someth= ing, > so let me give an example - let's say the mappings table is A4_1 -> Pref6= 4_1/n > (for NAT64_1, path to Internet), A4_2 -> Pref64_2/n (for NAT64_2, path to > datacenter), and heuristic for a packet destined to A4_1 incorrectly form= ed > Pref64_2:A4_1 as IPv6 destination address. The DNS64 of the network would give Pref64_1 as the prefix for ipv4only.arp= a, so wouldn't the incorrectly formed address be instead Pref61:2:A4_2? (Th= is is detail, I got the idea). > If the IPv6 network has only Pref64_1/n and Pref64_2/n routes, then such > packet Pref64_2:A4_1 will be routed to NAT64_2, which either will drop th= e > packet (if it verifies that IPv4 is in the allowed range for the used IPv= 6 prefix), > or will translate it to A4_1, and send packet destined to Internet into > datacenter network, that may not go anywhere. Yes, that's why we proposed the router to choose the right NAT64 based on t= he IPv4 address, or to avoid IPv4 literals that provide these kinds of mine= s. Special use IPv4 literals have serious issues already in the traditional= IPv4-only setups. > If the network has also Pref64_2:A4_1 -> NAT64_1 route, to compensate for > heuristic lack of support of mappings, such route will bring the packet t= o > NAT64_1, but again, unless NAT64_1 has a configuration for route Pref64_2= , > NAT64_1 will not know how to translate Pref64_2:A4_1 -> A4_1 and may > drop the packet. Right, the datacenter NAT64s would need to be configured to accept packets = for translation that come with Internet NAT64's Pref64::/n.=20 Now that I think of this more, maybe the bigger problem would be actually i= n the return direction, as the datacenter's NAT64 would need to be clever o= n what is the Pref64::/n it needs to use for a packet going back to the hos= t - the NAT64 could not use it's "default" Pref64_2, but would have to use = Pref64_1 the IPv6-only host chosen to use. This likely creates additional s= tate. > So is the assumption/suggestion that in addition to routing which include= IPv4 > ranges bits, all NAT64s are configured with shared configuration, so that= they > know about each other prefixes?=20 This was the assumption in the range-support proposal, yes. >Or the assumption is that one would never > want to have Pref64_2 !=3D Pref64_1, and just one shared Pref64 is suffic= ient > always? Maybe that is needed with the heuristics-based approach, for addresses that= are delivered as IPv4 literals to hosts. I try to clarify these restrictio= ns of the heuristic-tool to the draft.=20 > 3. If the heuristic is a documented kludge - what are the reasons it is p= ut on > the standards track instead of informational/experimental? What is the DNS64/NAT64 framework but a documented kludge? The stds track w= as agreed on the chartering phase and I think it is justified as we need e.= g. globally hosted IPv4-only name, ipv4only.arpa. Best regards, Teemu