From teemu.savolainen@nokia.com Mon Jan 2 04:02: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 B4CF621F8AC9 for ; Mon, 2 Jan 2012 04:02:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.765 X-Spam-Level: X-Spam-Status: No, score=-2.765 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5g96XDYeOYZ7 for ; Mon, 2 Jan 2012 04:02:07 -0800 (PST) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id E2CFE21F8A7D for ; Mon, 2 Jan 2012 04:02:05 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-sa01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q02C20Dd019810; Mon, 2 Jan 2012 14:02:01 +0200 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); Mon, 2 Jan 2012 14:02:00 +0200 Received: from 008-AM1MPN1-053.mgdnok.nokia.com ([169.254.3.196]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi id 14.01.0355.003; Mon, 2 Jan 2012 13:02:00 +0100 From: To: Thread-Topic: [BEHAVE] Changes on draft-ietf-behave-v4v6-bih-08.txt Thread-Index: AczBRGjS/q4k0O65RVKs+/X8gY+4LgAHo4QAAAO1NbwAA6rrgAHxcRIQ Date: Mon, 2 Jan 2012 12:01:59 +0000 Message-ID: <916CE6CF87173740BC8A2CE443096962042AA887@008-AM1MPN1-053.mgdnok.nokia.com> References: <916CE6CF87173740BC8A2CE443096962042A7E0B@008-AM1MPN1-053.mgdnok.nokia.com> <916CE6CF87173740BC8A2CE443096962042A8187@008-AM1MPN1-053.mgdnok.nokia.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Company Confidential;Project=None; x-titus-version: 3.3.8.1 x-headerinfofordlp: None x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7IqmvyJbo7tfx6El/3h0S6kkwaZDuYTB25zxoEVgyg3+WcD/6TP8b5qwfmODQwFP52mBe/PBZUtjSO44CFzeHgKAdsxLoOhTspw8YzNel+zCqW2Jv8MSVlHMJZ4wBYlwnUPaCy7vLV/ikHqzZRkXmsgOXXSuNLxnUOdioMxNsMKcdltxYOfsfngY+ARtdCeO6AY1zo/cSNopouoyxrgC37WGMfhFnC1+WktS4bJwgCqz2X53OX5mZtRysDgBsykFmFw== x-originating-ip: [10.162.89.107] Content-Type: multipart/alternative; boundary="_000_916CE6CF87173740BC8A2CE443096962042AA887008AM1MPN1053mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 02 Jan 2012 12:02:00.0782 (UTC) FILETIME=[5597FEE0:01CCC946] X-Nokia-AV: Clean Cc: behave@ietf.org Subject: Re: [BEHAVE] Changes on draft-ietf-behave-v4v6-bih-08.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2012 12:02:09 -0000 --_000_916CE6CF87173740BC8A2CE443096962042AA887008AM1MPN1053mg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Okay then, if no other opinions I'll ask AD if we should update with "If no= reply for A query is received after ENR implementation specific timeout, a= fter reception of positive AAAA response, the ENR MAY choose to proceed as = if there were only AAAA record available for the destination." and publish = -09. Thank you for feedback, Teemu From: ext Cameron Byrne [mailto:cb.list6@gmail.com] Sent: 23. joulukuuta 2011 17:38 To: Savolainen Teemu (Nokia-NRC/Tampere) Cc: behave@ietf.org Subject: RE: [BEHAVE] Changes on draft-ietf-behave-v4v6-bih-08.txt On Dec 23, 2011 7:57 AM, > wrote: > > The host should send A and AAAA in parallel, hence one would assume in us= ual case replies should arrive roughly at the same time. This 300ms is for = difference on reply arrival times and hence should not depend much on acces= s network latency. If the host sends queries in series, then it would be di= fferent thing. I was also considering reference to Happy Eyeballs draft: dr= aft-ietf-v6ops-happy-eyeballs-07 , but thought maybe not.. > > If it is hard to agree on specific time, we could just say instead:"If no= reply for A query is received after ENR implementation specific timeout, a= fter reception of positive AAAA response, the ENR MAY choose to proceed as = if there were only AAAA record available for the destination." > I think that new wording is prudent. A and aaaa may be cached and refreshed= separately. Cb > Best regards, > > Teemu > > ________________________________ > From: ext Cameron Byrne [cb.list6@gmail.com] > Sent: Friday, December 23, 2011 2:06 PM > To: Savolainen Teemu (Nokia-NRC/Tampere) > Cc: behave@ietf.org > Subject: Re: [BEHAVE] Changes on draft-ietf-behave-v4v6-bih-08.txt > > > On Dec 23, 2011 2:31 AM, > wrote: > > > > Behave WG, > > > > A new revision of BIH was made to respond to comments given by IESG. In= addition to some clarifications best seen in diff (http://tools.ietf.org/r= fcdiff?url2=3Ddraft-ietf-behave-v4v6-bih-08), the main changes were: > > - Introduction of 1.1 Terminology section > > - Significantly revising section 8. Changes since RFC2767 and RFC3338 > > > > Then there was question from Pete Resnick: "MUST the ENR wait for an ex= plicit negative > > response on the A record lookup, or can it synthesize from the AAAA in = other > > circumstances? Probably best to explicitly say so." For this following = text was added: > > -- > > If no reply for A query is received after 300 ms since reception of pos= itive AAAA response, the ENR MAY choose to proceed as if there were only AA= AA record available for the destination. > > -- > > > > Do you have any data to support 300ms? My concern is the highly latent w= ireless networks will not work best with 300 ms. > > Cb > > > Any comments? > > > > Best regards, > > > > Teemu > > > > -----Original Message----- > > From: behave-bounces@ietf.org [mailto:b= ehave-bounces@ietf.org] On Behalf Of ext in= ternet-drafts@ietf.org > > Sent: 23. joulukuuta 2011 09:24 > > To: i-d-announce@ietf.org > > Cc: behave@ietf.org > > Subject: [BEHAVE] I-D Action: draft-ietf-behave-v4v6-bih-08.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. This draft is a work item of the Behavior Engineering for Hindranc= e Avoidance Working Group of the IETF. > > > > Title : Dual Stack Hosts Using "Bump-in-the-Host" (BIH= ) > > Author(s) : Bill Huang > > Hui Deng > > Teemu Savolainen > > Filename : draft-ietf-behave-v4v6-bih-08.txt > > Pages : 29 > > Date : 2011-12-22 > > > > Bump-In-the-Host (BIH) is a host-based IPv4 to IPv6 protocol > > translation mechanism that allows a class of IPv4-only applications > > that work through NATs to communicate with IPv6-only peers. The host > > on which applications are running may be connected to IPv6-only or > > dual-stack access networks. BIH hides IPv6 and makes the IPv4-only > > applications think they are talking with IPv4 peers by local > > synthesis of IPv4 addresses. This document obsoletes RFC 2767 and > > RFC 3338. > > > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-behave-v4v6-bih-08.txt > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > This Internet-Draft can be retrieved at: > > ftp://ftp.ietf.org/internet-drafts/draft-ietf-behave-v4v6-bih-08.txt > > > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www.ietf.org/mailman/listinfo/behave > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www.ietf.org/mailman/listinfo/behave --_000_916CE6CF87173740BC8A2CE443096962042AA887008AM1MPN1053mg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Okay then, if no other op= inions I’ll ask AD if we should update with “If no reply= for A query is received after ENR implementation specific timeout, after reception of positive AAAA response, the ENR MAY choose to proceed a= s if there were only AAAA record available for the destination.” and publish -09.

 <= /p>

Thank you for feedback,

 <= /p>

Teemu

 <= /p>

From: ext Came= ron Byrne [mailto:cb.list6@gmail.com]
Sent: 23. joulukuuta 2011 17:38
To: Savolainen Teemu (Nokia-NRC/Tampere)
Cc: behave@ietf.org
Subject: RE: [BEHAVE] Changes on draft-ietf-behave-v4v6-bih-08.txt

 


On Dec 23, 2011 7:57 AM, <= teemu.savolainen@nokia.com> wrote:
>
> The host should send A and AAAA in parallel, hence one would assume in= usual case replies should arrive roughly at the same time. This 300ms is f= or difference on reply arrival times and hence should not depend much on ac= cess network latency. If the host sends queries in series, then it would be different thing. I was also considerin= g reference to Happy Eyeballs draft: draft-ietf-v6ops-happy-eyeballs-07 , b= ut thought maybe not..
>
> If it is hard to agree on specific time, we could just say instead:&qu= ot;If no reply for A query is received after ENR implementation specific ti= meout, after reception of positive AAAA response, the ENR MAY choose to pro= ceed as if there were only AAAA record available for the destination."
>

I think that new wording is prudent. A and aaaa may be cached and refres= hed separately.

Cb
> Best regards,
>
> Teemu
>
> ________________________________
> From: ext Cameron Byrne [cb.list= 6@gmail.com]
> Sent: Friday, December 23, 2011 2:06 PM
> To: Savolainen Teemu (Nokia-NRC/Tampere)
> Cc: behave@ietf.org
> Subject: Re: [BEHAVE] Changes on draft-ietf-behave-v4v6-bih-08.txt
>
>
> On Dec 23, 2011 2:31 AM, <teemu.savolainen@nokia.com> wrote:
> >
> > Behave WG,
> >
> > A new revision of BIH was made to respond to comments given by IE= SG. In addition to some clarifications best seen in diff (http://tools.= ietf.org/rfcdiff?url2=3Ddraft-ietf-behave-v4v6-bih-08), the main changes were:
> > - Introduction of 1.1 Terminology section
> > - Significantly revising section 8.  Changes since RFC2767 a= nd RFC3338
> >
> > Then there was question from Pete Resnick: "MUST the ENR wai= t for an explicit negative
> > response on the A record lookup, or can it synthesize from the AA= AA in other
> > circumstances? Probably best to explicitly say so." For this= following text was added:
> > --
> > If no reply for A query is received after 300 ms since reception = of positive AAAA response, the ENR MAY choose to proceed as if there were o= nly AAAA record available for the destination.
> > --
> >
>
> Do you have any data to support 300ms?  My concern is the highly = latent wireless networks will not work best with 300 ms.
>
> Cb
>
> > Any comments?
> >
> > Best regards,
> >
> >        Teemu
> >
> > -----Original Message-----
> > From: behave-bounces@i= etf.org [mailto:behave-bounc= es@ietf.org] On Behalf Of ext internet-drafts@ietf.org > > Sent: 23. joulukuuta 2011 09:24
> > To: i-d-announce@ietf.or= g
> > Cc: behave@ietf.org
> > Subject: [BEHAVE] I-D Action: draft-ietf-behave-v4v6-bih-08.txt > >
> >
> > A New Internet-Draft is available from the on-line Internet-Draft= s directories. This draft is a work item of the Behavior Engineering for Hi= ndrance Avoidance Working Group of the IETF.
> >
> >        Title         &nbs= p; : Dual Stack Hosts Using "Bump-in-the-Host" (BIH)
> >        Author(s)       : Bill = Huang
> >                   &n= bsp;      Hui Deng
> >                   &n= bsp;      Teemu Savolainen
> >        Filename        : = draft-ietf-behave-v4v6-bih-08.txt
> >        Pages         &nbs= p; : 29
> >        Date          = ;  : 2011-12-22
> >
> >   Bump-In-the-Host (BIH) is a host-based IPv4 to IPv6 protoc= ol
> >   translation mechanism that allows a class of IPv4-only app= lications
> >   that work through NATs to communicate with IPv6-only peers= .  The host
> >   on which applications are running may be connected to IPv6= -only or
> >   dual-stack access networks.  BIH hides IPv6 and makes= the IPv4-only
> >   applications think they are talking with IPv4 peers by loc= al
> >   synthesis of IPv4 addresses.  This document obsoletes= RFC 2767 and
> >   RFC 3338.
> >
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-ietf-behave-v4v6-bih-08.txt > >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.or= g/internet-drafts/
> >
> > This Internet-Draft can be retrieved at:
> > ftp://ftp.ietf.org/internet-drafts/draft-ietf-behave-v4v6-bih-08.txt > >
> > _______________________________________________
> > Behave mailing list
> > Behave@ietf.org
> > https://= www.ietf.org/mailman/listinfo/behave
> > _______________________________________________
> > Behave mailing list
> > Behave@ietf.org
> > https://= www.ietf.org/mailman/listinfo/behave

--_000_916CE6CF87173740BC8A2CE443096962042AA887008AM1MPN1053mg_-- From Gandhar.Gokhale@lsi.com Thu Jan 5 00:30: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 73AAA21F8757 for ; Thu, 5 Jan 2012 00:30:12 -0800 (PST) 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 mrzXJVPQAGDa for ; Thu, 5 Jan 2012 00:30:11 -0800 (PST) Received: from na3sys009aog125.obsmtp.com (na3sys009aog125.obsmtp.com [74.125.149.153]) by ietfa.amsl.com (Postfix) with ESMTP id 5D9D921F86B4 for ; Thu, 5 Jan 2012 00:30:10 -0800 (PST) Received: from paledge01.lsi.com ([192.19.193.42]) (using TLSv1) by na3sys009aob125.postini.com ([74.125.148.12]) with SMTP ID DSNKTwVfj7J/VuWNcciAlnQ3nc9plfdZKDap@postini.com; Thu, 05 Jan 2012 00:30:11 PST Received: from PALHUB01.lsi.com (128.94.213.114) by PALEDGE01.lsi.com (192.19.193.42) with Microsoft SMTP Server (TLS) id 8.3.137.0; Thu, 5 Jan 2012 03:34:31 -0500 Received: from inbexch01.lsi.com (135.36.98.37) by PALHUB01.lsi.com (128.94.213.114) with Microsoft SMTP Server (TLS) id 8.3.106.1; Thu, 5 Jan 2012 03:30:06 -0500 Received: from inbmail01.lsi.com ([135.36.98.64]) by inbexch01.lsi.com ([135.36.98.37]) with mapi; Thu, 5 Jan 2012 14:00:02 +0530 From: "Gokhale, Gandhar" To: RFC Errata System Date: Thu, 5 Jan 2012 13:57:15 +0530 Thread-Topic: [Technical Errata Reported] RFC6145 (3061) Thread-Index: AczBZQC27KBGBLIGSXe3RFUXId1/xQKHtPiT Message-ID: <9181E99F41C081478B455A70FC1D01CB0D8B9DCEA2@inbmail01.lsi.com> References: <20111223111948.9759872E008@rfc-editor.org> In-Reply-To: <20111223111948.9759872E008@rfc-editor.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 05 Jan 2012 10:07:03 -0800 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] [Technical Errata Reported] RFC6145 (3061) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 08:31:29 -0000 Hello, I've submitted 3 errata on RFC 6145 (eid: 3059, 3060 & 3061) on December 23= rd, 2011. They are in reported state. I wonder if something needs to be don= e from my side for these to move to next state (approved/rejected etc). Ple= ase let me know when these will be taken up for conclusion. Thanks and Regards, Gandhar Gokhale ________________________________________ From: RFC Errata System [rfc-editor@rfc-editor.org] Sent: Friday, December 23, 2011 4:49 PM To: xing@cernet.edu.cn; congxiao@cernet.edu.cn; fred@cisco.com; ietfdbh@com= cast.net; wes@mti-systems.com; dthaler@microsoft.com; dwing@cisco.com Cc: Gokhale, Gandhar; behave@ietf.org; rfc-editor@rfc-editor.org Subject: [Technical Errata Reported] RFC6145 (3061) The following errata report has been submitted for RFC6145, "IP/ICMP Translation Algorithm". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3D6145&eid=3D3061 -------------------------------------- Type: Technical Reported by: Gandhar Gokhale Section: 5.1.1 Original Text ------------- Fragment Offset: Copied from the Fragment Offset field of the IPv6 Fragmen= t Header. Corrected Text -------------- Fragment Offset: If the Next Header field of the Fragment Header is not an= extension header (except ESP) then Fragment Offset MUST be copied from the= Fragment Offset field of the IPv6 Fragment Header. If the Next Header fiel= d of the Fragment Header is an extension header (except ESP) then the packe= t SHOULD be dropped and logged. Notes ----- If the fragmentable part (as described in RFC 2460) of the original unfragm= ented IPv6 packet had extension headers then the translator can not calcula= te the offset of the IPv4 fragment for non-initial fragments. If extension = headers are present in the fragmentable part then the fragment offset value= of the IPv6 header includes length of the extension headers also. Since tr= anslator strips of the IPv6 extension headers the fragment offset value set= by the sender of IPv6 fragments can not match that received by the IPv4 re= ceiver and the reassembly will fail. For non-initial fragments the translat= or does not have the knowledge of this delta when there is no state maintai= ned. The legth issue stated in erratum 2 is not in itself sufficient to advocate= packet drop. However, the offset issue is sufficient to advocate packet dr= op as the reassembly is bound to fail. Therefore I'm putting a SHOULD in bo= th cases. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6145 (draft-ietf-behave-v6v4-xlate-23) -------------------------------------- Title : IP/ICMP Translation Algorithm Publication Date : April 2011 Author(s) : X. Li, C. Bao, F. Baker Category : PROPOSED STANDARD Source : Behavior Engineering for Hindrance Avoidance Area : Transport Stream : IETF Verifying Party : IESG From ahagens@amsl.com Thu Jan 5 07:28: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 2880F21F8759 for ; Thu, 5 Jan 2012 07:28:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[AWL=0.950, 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 xZaM5HmSBkwq for ; Thu, 5 Jan 2012 07:28:51 -0800 (PST) Received: from mail.amsl.com (mail.amsl.com [IPv6:2001:1890:123a::1:14]) by ietfa.amsl.com (Postfix) with ESMTP id 45F4E21F8734 for ; Thu, 5 Jan 2012 07:28:51 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id E055212CA14; Thu, 5 Jan 2012 07:28:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NYQisTTRUO6U; Thu, 5 Jan 2012 07:28:48 -0800 (PST) Received: from rfc2.home (pool-72-66-107-92.washdc.fios.verizon.net [72.66.107.92]) by c8a.amsl.com (Postfix) with ESMTPSA id 4BCD712C908; Thu, 5 Jan 2012 07:28:48 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Alice Hagens In-Reply-To: <9181E99F41C081478B455A70FC1D01CB0D8B9DCEA2@inbmail01.lsi.com> Date: Thu, 5 Jan 2012 10:28:47 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <1A8E3EBB-E6BC-453C-9A26-5DD31CC3EA14@amsl.com> References: <20111223111948.9759872E008@rfc-editor.org> <9181E99F41C081478B455A70FC1D01CB0D8B9DCEA2@inbmail01.lsi.com> To: "Gokhale, Gandhar" X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Thu, 05 Jan 2012 10:07:02 -0800 Cc: behave@ietf.org, RFC Editor Subject: Re: [BEHAVE] [Technical Errata Reported] RFC6145 (3061) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 15:28:52 -0000 Greetings, On your side, there is no further action beyond participating (via = email) if there is discussion of the errata triggered by the initial = mail.=20 For RFCs from the IETF stream, the IESG reviews errata and marks them = Verified, Rejected, or Held for Document Update. This is described on = the following pages: - How to Report Errata http://www.rfc-editor.org/how_to_report.html - IESG Processing of RFC Errata for the IETF Stream http://www.ietf.org/iesg/statement/errata-processing.html Please let us know if you have further questions. Thank you. RFC Editor/ah On Jan 5, 2012, at 3:27 AM, Gokhale, Gandhar wrote: > Hello, >=20 > I've submitted 3 errata on RFC 6145 (eid: 3059, 3060 & 3061) on = December 23rd, 2011. They are in reported state. I wonder if something = needs to be done from my side for these to move to next state = (approved/rejected etc). Please let me know when these will be taken up = for conclusion. >=20 >=20 > Thanks and Regards, > Gandhar Gokhale > ________________________________________ > From: RFC Errata System [rfc-editor@rfc-editor.org] > Sent: Friday, December 23, 2011 4:49 PM > To: xing@cernet.edu.cn; congxiao@cernet.edu.cn; fred@cisco.com; = ietfdbh@comcast.net; wes@mti-systems.com; dthaler@microsoft.com; = dwing@cisco.com > Cc: Gokhale, Gandhar; behave@ietf.org; rfc-editor@rfc-editor.org > Subject: [Technical Errata Reported] RFC6145 (3061) >=20 > The following errata report has been submitted for RFC6145, > "IP/ICMP Translation Algorithm". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D6145&eid=3D3061 >=20 > -------------------------------------- > Type: Technical > Reported by: Gandhar Gokhale >=20 > Section: 5.1.1 >=20 > Original Text > ------------- > Fragment Offset: Copied from the Fragment Offset field of the IPv6 = Fragment Header. >=20 > Corrected Text > -------------- > Fragment Offset: If the Next Header field of the Fragment Header is = not an extension header (except ESP) then Fragment Offset MUST be copied = from the Fragment Offset field of the IPv6 Fragment Header. If the Next = Header field of the Fragment Header is an extension header (except ESP) = then the packet SHOULD be dropped and logged. >=20 >=20 >=20 >=20 >=20 > Notes > ----- > If the fragmentable part (as described in RFC 2460) of the original = unfragmented IPv6 packet had extension headers then the translator can = not calculate the offset of the IPv4 fragment for non-initial fragments. = If extension headers are present in the fragmentable part then the = fragment offset value of the IPv6 header includes length of the = extension headers also. Since translator strips of the IPv6 extension = headers the fragment offset value set by the sender of IPv6 fragments = can not match that received by the IPv4 receiver and the reassembly will = fail. For non-initial fragments the translator does not have the = knowledge of this delta when there is no state maintained. >=20 >=20 >=20 > The legth issue stated in erratum 2 is not in itself sufficient to = advocate packet drop. However, the offset issue is sufficient to = advocate packet drop as the reassembly is bound to fail. Therefore I'm = putting a SHOULD in both cases. >=20 > 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. >=20 > -------------------------------------- > RFC6145 (draft-ietf-behave-v6v4-xlate-23) > -------------------------------------- > Title : IP/ICMP Translation Algorithm > Publication Date : April 2011 > Author(s) : X. Li, C. Bao, F. Baker > Category : PROPOSED STANDARD > Source : Behavior Engineering for Hindrance Avoidance > Area : Transport > Stream : IETF > Verifying Party : IESG >=20 From dwing@cisco.com Thu Jan 5 17:07: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 EDB3121F859A for ; Thu, 5 Jan 2012 17:07:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.566 X-Spam-Level: X-Spam-Status: No, score=-106.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 PoTtuXaKfUVN for ; Thu, 5 Jan 2012 17:07:34 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 8872721F858D for ; Thu, 5 Jan 2012 17:07:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=960; q=dns/txt; s=iport; t=1325812054; x=1327021654; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=OtGxT/7hnZlFtfeDEQE5rQdu72fq5n9rJ2Ej+XgslYw=; b=aduEdsNMrKF+JQtEHBbU44UL63uO1XugT/9DZ1gKWs/Sa/Sgsrrb4rss wNE1rk1Vo8UYSg9E79qkFV5xZk6ZH3XR/leTkWcKmLg9FesCtcJuJPs/f YPMCjcBP3FzacMt/S82OSAW+F6S+M3AfEb9M8xS9P5FT3aM6voFOCL7pT M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFANRIBk+rRDoI/2dsb2JhbABCggWcG45hgQWBeQgKARcQPw0FGFAjHAEEHheHYJd8AZ4hiHeDGgSIOYR5AZop X-IronPort-AV: E=Sophos;i="4.71,464,1320624000"; d="scan'208";a="24049789" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 06 Jan 2012 01:07:33 +0000 Received: from dwingWS ([10.32.240.197]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q0617Vgp030750; Fri, 6 Jan 2012 01:07:33 GMT From: "Dan Wing" To: Date: Thu, 5 Jan 2012 17:07:33 -0800 Message-ID: <0ace01cccc0f$9249af20$b6dd0d60$@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: AczMD5IV4uwiuqavR363Rl5NSWOWMQ== Content-Language: en-us Cc: 'Dave Thaler' Subject: [BEHAVE] BEHAVE interim: January 26, 7am Pacific Time 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, 06 Jan 2012 01:07:35 -0000 We would like to have an interim BEHAVE meeting on January 26 at 7am Pacific Time for 1.5 hours. WebEx and dial-in details and agenda are posted at http://trac.tools.ietf.org/wg/behave/trac/wiki/WikiStart This interim meeting is intended to discuss (at least, but not limited to) the MIB as well as the rfc4787-5382-5508 drafts, and will also be used by the chairs to determine if a face-to-face BEHAVE meeting is necessary at IETF83. If you have anything to discuss specific to BEHAVE, please send email to the chairs requesting a slot at the interim. An Internet-Draft is not necessary. Things like "My -00 draft will be edited to say ____" are what we are looking for. That is, we want to know of progress happening with various drafts, ongoing activity, etc. Most important is to bring to the interim meeting any problems where consensus may be necessary. -Dan and Dave From dean.cheng@huawei.com Thu Jan 5 20:34: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 649321F0C59 for ; Thu, 5 Jan 2012 20:34:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 huFcICQOjjW7 for ; Thu, 5 Jan 2012 20:34:32 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id D58661F0C56 for ; Thu, 5 Jan 2012 20:34:31 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LXD00FHG0J12L@szxga05-in.huawei.com> for behave@ietf.org; Fri, 06 Jan 2012 12:30:37 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LXD008Y10IE3Z@szxga05-in.huawei.com> for behave@ietf.org; Fri, 06 Jan 2012 12:30:37 +0800 (CST) Received: from szxeml206-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGG20995; Fri, 06 Jan 2012 12:30:37 +0800 Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by szxeml206-edg.china.huawei.com (172.24.2.58) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 06 Jan 2012 12:30:34 +0800 Received: from SZXEML523-MBX.china.huawei.com ([169.254.3.222]) by szxeml402-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Fri, 06 Jan 2012 12:30:20 +0800 Date: Fri, 06 Jan 2012 04:30:20 +0000 From: Dean cheng X-Originating-IP: [10.212.244.193] To: "behave@ietf.org" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_0WgNc9XiRU7nTb38EnExMA)" Content-language: en-US Accept-Language: en-US, zh-CN Thread-topic: New Version Notification for draft-cheng-behave-cgn-cfg-radius-ext-02.txt Thread-index: AQHMzBMkdAT6GWwY5kGNynNoyFp9W5X+nEEg X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected Cc: jouni korhonen Subject: [BEHAVE] FW: New Version Notification for draft-cheng-behave-cgn-cfg-radius-ext-02.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 04:34:34 -0000 --Boundary_(ID_0WgNc9XiRU7nTb38EnExMA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT We've just posted a new revision for the draft-cheng-behave-cgn-cfg-radius-ext-02, with a few editing corrections. We presented this draft the first time in BEHAVE/Taipei where the conclusion was to "take it to the list", so this message is to encourage some discussion to see if the proposed is useful when deploying a CGN (NAT44, NAT64) in an access/broadband network. The problem and the proposed solution from this draft are as follows (for details, please refer to the draft): Today in an access/broadband network where BNG/BRAS (which contains a NAS component) deployed, RADIUS protocol is used for communication between the BNG/BRAS and the RADIUS server, so that some user based configuration (such as user's credential, IP address, etc.) that pre-configured on the RADIUS server can be conveyed to the BNG/BRAS at the time when the user signs on to the Internet service. In deploying CGN, there would also be some individual user based parameters (such as port limit. address/port mapping that needs to be statically configured for port forwarding), which needs to be made known to the CGN, which can then operate correctly on individual traffic. When a CGN is co-located with the BNG/BRAS, the new configuration problem/requirement can be resolved by pre-configuring user based CGN parameters on the RADIUS server, and those parameters can be transferred to the CGN along with others as in today's operation. This solution does not need new protocol or any change in the operation, but only proposes some new RADIUS attributes and the key advantage is the solution leverages the existing access/broadband network's infrastructure and operation. Note however that the proposed only aims at the deployment where the CGN is co-located with the BNG/BRAS, which is a real case but not always (e.g., a CGN may be deployed as a stand-alone device away from BNG/BRAS sometimes). Cheers Dean -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Sent: Thursday, January 05, 2012 5:33 PM To: Dean cheng Cc: Dean cheng; jouni.nospam@gmail.com Subject: New Version Notification for draft-cheng-behave-cgn-cfg-radius-ext-02.txt A new version of I-D, draft-cheng-behave-cgn-cfg-radius-ext-02.txt has been successfully submitted by Dean Cheng and posted to the IETF repository. Filename: draft-cheng-behave-cgn-cfg-radius-ext Revision: 02 Title: Radius Extensions for CGN Configurations Creation date: 2012-01-06 WG ID: Individual Submission Number of pages: 22 Abstract: This document defines new RADIUS attributes that can be used by a Carried Grade NAT device to communicate with a RADIUS server using RADIUS protocol to configure or report TCP/UDP ports and ICMP identifiers mapping behavior for specific Internet subscribers. The IETF Secretariat --Boundary_(ID_0WgNc9XiRU7nTb38EnExMA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

We’ve just posted a new revision for the

draft-cheng-behave-cgn-cfg-radius-ext-02, with a few

editing corrections.

 

We presented this draft the first time in BEHAVE/Taipei

where the conclusion was to “take it to the list”, so this

message is to encourage some discussion to see if the proposed

is useful when deploying a CGN (NAT44, NAT64) in an

access/broadband network.

 

The problem and the proposed solution from this draft

are as follows (for details, please refer to the draft):

 

Today in an access/broadband network where BNG/BRAS

(which contains a NAS component) deployed,  RADIUS

protocol is used for communication between the BNG/BRAS

and the RADIUS server, so that some user based configuration

(such as user’s credential, IP address, etc.) that pre-configured

on the RADIUS server can be conveyed to the BNG/BRAS at

the time when the user signs on to the Internet service.

 

In deploying CGN, there would also be some individual user

based parameters (such as port limit. address/port mapping that

needs to be statically configured for port forwarding), which

needs to be made known to the CGN, which can then operate

correctly on individual traffic.

 

When a CGN is co-located with the BNG/BRAS, the new

configuration problem/requirement can be resolved by pre-configuring

user based CGN parameters on the RADIUS server, and those

parameters can be transferred to the CGN along with others as in today’s

operation. This solution does not need new protocol or any change in

the operation, but only proposes some new RADIUS attributes

and the key advantage is the solution leverages the existing

access/broadband network’s infrastructure and operation. 

 

Note however that the proposed only aims at the deployment where the

CGN is co-located with the BNG/BRAS, which is a real case but not

always (e.g., a CGN may be deployed as a stand-alone device away from

BNG/BRAS sometimes).

 

Cheers

Dean

 

-----Original Message-----
From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: Thursday, January 05, 2012 5:33 PM
To: Dean cheng
Cc: Dean cheng; jouni.nospam@gmail.com
Subject: New Version Notification for draft-cheng-behave-cgn-cfg-radius-ext-02.txt

 

A new version of I-D, draft-cheng-behave-cgn-cfg-radius-ext-02.txt has been successfully submitted by Dean Cheng and posted to the IETF repository.

 

Filename:   draft-cheng-behave-cgn-cfg-radius-ext

Revision:   02

Title:            Radius Extensions for CGN Configurations

Creation date:    2012-01-06

WG ID:            Individual Submission

Number of pages: 22

 

Abstract:

   This document defines new RADIUS attributes that can be used by a

   Carried Grade NAT device to communicate with a RADIUS server using

   RADIUS protocol to configure or report TCP/UDP ports and ICMP

   identifiers mapping behavior for specific Internet subscribers.

 

 

                                                                                 

 

 

The IETF Secretariat

--Boundary_(ID_0WgNc9XiRU7nTb38EnExMA)-- From teemu.savolainen@nokia.com Thu Jan 12 01:05: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 6A15521F8565 for ; Thu, 12 Jan 2012 01:05:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.724 X-Spam-Level: X-Spam-Status: No, score=-2.724 tagged_above=-999 required=5 tests=[AWL=-0.125, 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 sV0edzC8HfHR for ; Thu, 12 Jan 2012 01:05:53 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id BE3F021F849D for ; Thu, 12 Jan 2012 01:05:53 -0800 (PST) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q0C95KqS001438 for ; Thu, 12 Jan 2012 11:05:49 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.58]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 12 Jan 2012 11:05:21 +0200 Received: from 008-AM1MPN1-053.mgdnok.nokia.com ([169.254.3.196]) by 008-AM1MMR1-003.mgdnok.nokia.com ([65.54.30.58]) with mapi id 14.01.0355.003; Thu, 12 Jan 2012 10:05:20 +0100 From: To: Thread-Topic: Question about heuristic discovery and connectivity tests Thread-Index: AczRBpsjXOg/zVvYQyKaRBwBX7L07g== Date: Thu, 12 Jan 2012 09:05:20 +0000 Message-ID: <916CE6CF87173740BC8A2CE443096962042B085B@008-AM1MPN1-053.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Nokia Internal Use Only;Project=None; x-titus-version: 3.3.8.1 x-headerinfofordlp: None x-tituslabs-classificationhash-30: 4lI8lld/Cs6gJozBIdd2wMiJuS9qT8GilyZAtFStG4NQYrvH49B7nuSPEjYv5uLvdINuys254KNMz7YQM50SMo3T+5l282NMA9cuE7PC9GauP9tVZd3CUt7wQadkMIJth8Vu19oMLUoDckeFX1iLwLfpe3AidrElqdFEpIPLtbX6vipbE4fws6Bgt3BSnMpJ519p5aExnBcLs9F4NYzKjB7AByBAxkJWNYDBfetamwwpztaAkehxY12T0kc3D2+G5Jka9tRChpCCqd+JKwKsTg== x-originating-ip: [10.162.89.107] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 12 Jan 2012 09:05:21.0676 (UTC) FILETIME=[502A44C0:01CCD109] X-Nokia-AV: Clean Subject: [BEHAVE] Question about heuristic discovery and connectivity tests X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 09:05:54 -0000 Hi, The current -04 version of heuristic discovery says in section 3.2 "Connect= ivity test": -- The host MUST NOT perform connectivity test against the IPv4 address of the well-known name, but instead use some other destination such as host vendor's servers. In many scenarios separate connectivity test is not really required as an application may just try to connect to the IPv4-only destination with synthetic IPv6 address and see if a connection is successfully established or not. -- Dan suggested me to initiate discussions about this in order to improve the= section. The reason why it currently says MUST NOT is to avoid all (and especially e= xcess) traffic towards the IPv4 address(es) used by the "ipv4only.arpa" (to= avoid unwanted global traffic). I can clarify that for sure. However, the question is then whether we should have "connectivity test" se= ction at all and if yes, whether host actually needs to perform separate co= nnectivity test at first place, and if yes, to what destination the connect= ivity test could be made by the host. One option could be to state that separate connectivity test SHOULD NOT be = done: it should be enough to just try the synthetic IPv6 address whenever o= ne is needed and if connection fails to set up, well, then destination is u= nreachable. Optionally host might be able to learn that synthetic addresses= are systematically failing and hence maybe the prefix discovery has failed= .. Another option could be to state that OS/application MAY perform a separate= connectivity test, if the OS/application finds that useful and has a desti= nation that is happy to receive connectivity test messages from said OS/app= lication. This destination could be OS/application vendor's dedicated inter= net connectivity test server, vendor's homepage, OS/application's software = update repository or similar. It might also be possible to "bundle" the con= nectivity test with some other communications OS/application initiates anyw= ay, for example, contact to software update repository through NAT64 *on pu= rpose*, even if the repository would be directly IPv6 reachable. Any thoughts? Best regards, Teemu From cb.list6@gmail.com Thu Jan 12 08: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 D269721F84C5 for ; Thu, 12 Jan 2012 08:35:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DSGgBy0fj6Bf for ; Thu, 12 Jan 2012 08:35:07 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id DEEBA21F8471 for ; Thu, 12 Jan 2012 08:35:07 -0800 (PST) Received: by pbbb2 with SMTP id b2so574166pbb.31 for ; Thu, 12 Jan 2012 08:35:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YQ3rLoGJqxFMZ458gg/nDygDdU/yyw+82wHZCR0PR8k=; b=fSvLQpZQR4eNvvB8snIEsvljoFKNG/BJ4nvJ7ZSB3Rclft0ZE3tNm/Ik/hdjEF2RV6 iJ4AHVWtpBK6of2m631PJslIP4Sjd4psqFp4qpcEml5y+R2RSiITrgIopnTbg1Fnzabf S7Z4RacdEHo+lmTANQJZfEoAEiynhXA9aQzpk= MIME-Version: 1.0 Received: by 10.68.189.103 with SMTP id gh7mr9362057pbc.98.1326386107580; Thu, 12 Jan 2012 08:35:07 -0800 (PST) Received: by 10.142.161.6 with HTTP; Thu, 12 Jan 2012 08:35:07 -0800 (PST) Received: by 10.142.161.6 with HTTP; Thu, 12 Jan 2012 08:35:07 -0800 (PST) In-Reply-To: <916CE6CF87173740BC8A2CE443096962042B085B@008-AM1MPN1-053.mgdnok.nokia.com> References: <916CE6CF87173740BC8A2CE443096962042B085B@008-AM1MPN1-053.mgdnok.nokia.com> Date: Thu, 12 Jan 2012 08:35:07 -0800 Message-ID: From: Cameron Byrne To: teemu.savolainen@nokia.com Content-Type: multipart/alternative; boundary=e89a8ff1c870c6ff4404b65754ba Cc: behave@ietf.org Subject: Re: [BEHAVE] Question about heuristic discovery and connectivity tests X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 16:35:08 -0000 --e89a8ff1c870c6ff4404b65754ba Content-Type: text/plain; charset=ISO-8859-1 On Jan 12, 2012 1:06 AM, wrote: > > Hi, > > The current -04 version of heuristic discovery says in section 3.2 "Connectivity test": > -- > The host MUST NOT perform connectivity test against the IPv4 address > of the well-known name, but instead use some other destination such > as host vendor's servers. > > In many scenarios separate connectivity test is not really required > as an application may just try to connect to the IPv4-only > destination with synthetic IPv6 address and see if a connection is > successfully established or not. > -- > > Dan suggested me to initiate discussions about this in order to improve the section. > > The reason why it currently says MUST NOT is to avoid all (and especially excess) traffic towards the IPv4 address(es) used by the "ipv4only.arpa" (to avoid unwanted global traffic). I can clarify that for sure. > > However, the question is then whether we should have "connectivity test" section at all and if yes, whether host actually needs to perform separate connectivity test at first place, and if yes, to what destination the connectivity test could be made by the host. > I do not believe a connectivity check language is required. As your example states, ipv4only.arpa will never respond to a connection, so it would be unlikely that something is deployed at scale like this since no connection yields no information. Fyi. There is beta code of this draft that references ipv4.t-mobile.com. I look forward to the advancement of this draft and the official reference name. Cb > One option could be to state that separate connectivity test SHOULD NOT be done: it should be enough to just try the synthetic IPv6 address whenever one is needed and if connection fails to set up, well, then destination is unreachable. Optionally host might be able to learn that synthetic addresses are systematically failing and hence maybe the prefix discovery has failed.. > > Another option could be to state that OS/application MAY perform a separate connectivity test, if the OS/application finds that useful and has a destination that is happy to receive connectivity test messages from said OS/application. This destination could be OS/application vendor's dedicated internet connectivity test server, vendor's homepage, OS/application's software update repository or similar. It might also be possible to "bundle" the connectivity test with some other communications OS/application initiates anyway, for example, contact to software update repository through NAT64 *on purpose*, even if the repository would be directly IPv6 reachable. > > Any thoughts? > > Best regards, > > Teemu > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave --e89a8ff1c870c6ff4404b65754ba Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Jan 12, 2012 1:06 AM, <= teemu.savolainen@nokia.com> wrote:
>
> Hi,
>
> The current -04 version of heuristic discovery says in section 3.2 &qu= ot;Connectivity test":
> --
> =A0 The host MUST NOT perform connectivity test against the IPv4 addre= ss
> =A0 of the well-known name, but instead use some other destination suc= h
> =A0 as host vendor's servers.
>
> =A0 In many scenarios separate connectivity test is not really require= d
> =A0 as an application may just try to connect to the IPv4-only
> =A0 destination with synthetic IPv6 address and see if a connection is=
> =A0 successfully established or not.
> --
>
> Dan suggested me to initiate discussions about this in order to improv= e the section.
>
> The reason why it currently says MUST NOT is to avoid all (and especia= lly excess) traffic towards the IPv4 address(es) used by the "ipv4only= .arpa" (to avoid unwanted global traffic). I can clarify that for sure= .
>
> However, the question is then whether we should have "connectivit= y test" section at all and if yes, whether host actually needs to perf= orm separate connectivity test at first place, and if yes, to what destinat= ion the connectivity test could be made by the host.
>

I do not believe a connectivity check=A0 language is required.=A0 As you= r example states, ipv4only.arpa will never respond to a connection, so it w= ould be unlikely that something is deployed at scale like this since no con= nection yields no information.

Fyi. There is beta code of this draft that references ipv4.t-mobile.com.=A0 I look forward to the advancem= ent of this draft and the official reference name.

Cb
> One option could be to state that separate connectivity test SHOULD NO= T be done: it should be enough to just try the synthetic IPv6 address whene= ver one is needed and if connection fails to set up, well, then destination= is unreachable. Optionally host might be able to learn that synthetic addr= esses are systematically failing and hence maybe the prefix discovery has f= ailed..
>
> Another option could be to state that OS/application MAY perform a sep= arate connectivity test, if the OS/application finds that useful and has a = destination that is happy to receive connectivity test messages from said O= S/application. This destination could be OS/application vendor's dedica= ted internet connectivity test server, vendor's homepage, OS/applicatio= n's software update repository or similar. It might also be possible to= "bundle" the connectivity test with some other communications OS= /application initiates anyway, for example, contact to software update repo= sitory through NAT64 *on purpose*, even if the repository would be directly= IPv6 reachable.
>
> Any thoughts?
>
> Best regards,
>
> =A0 =A0 =A0 =A0Teemu
>
>
> _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www.i= etf.org/mailman/listinfo/behave

--e89a8ff1c870c6ff4404b65754ba-- From internet-drafts@ietf.org Mon Jan 16 00:49: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 7130521F8589; Mon, 16 Jan 2012 00:49:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.557 X-Spam-Level: X-Spam-Status: No, score=-102.557 tagged_above=-999 required=5 tests=[AWL=0.042, 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 yXnIN90AzdE8; Mon, 16 Jan 2012 00:49:22 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AE5F21F8581; Mon, 16 Jan 2012 00:49:22 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120116084922.3092.55620.idtracker@ietfa.amsl.com> Date: Mon, 16 Jan 2012 00:49:22 -0800 Cc: behave@ietf.org Subject: [BEHAVE] I-D Action: draft-ietf-behave-v4v6-bih-09.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, 16 Jan 2012 08:49:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Behavior Engineering for Hindrance Av= oidance Working Group of the IETF. Title : Dual Stack Hosts Using "Bump-in-the-Host" (BIH) Author(s) : Bill Huang Hui Deng Teemu Savolainen Filename : draft-ietf-behave-v4v6-bih-09.txt Pages : 29 Date : 2012-01-16 Bump-In-the-Host (BIH) is a host-based IPv4 to IPv6 protocol translation mechanism that allows a class of IPv4-only applications that work through NATs to communicate with IPv6-only peers. The host on which applications are running may be connected to IPv6-only or dual-stack access networks. BIH hides IPv6 and makes the IPv4-only applications think they are talking with IPv4 peers by local synthesis of IPv4 addresses. This document obsoletes RFC 2767 and RFC 3338. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-v4v6-bih-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-behave-v4v6-bih-09.txt From ietfdbh@comcast.net Wed Jan 18 10:14: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 1DB5421F8585 for ; Wed, 18 Jan 2012 10:14:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.411 X-Spam-Level: X-Spam-Status: No, score=-102.411 tagged_above=-999 required=5 tests=[AWL=0.188, 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 u7cG1J+xpf3S for ; Wed, 18 Jan 2012 10:14:37 -0800 (PST) Received: from qmta09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [76.96.30.96]) by ietfa.amsl.com (Postfix) with ESMTP id A3AB721F8709 for ; Wed, 18 Jan 2012 10:14:37 -0800 (PST) Received: from omta17.emeryville.ca.mail.comcast.net ([76.96.30.73]) by qmta09.emeryville.ca.mail.comcast.net with comcast id P4MA1i0061afHeLA96Ed52; Wed, 18 Jan 2012 18:14:37 +0000 Received: from davidPC ([12.217.162.130]) by omta17.emeryville.ca.mail.comcast.net with comcast id P6EG1i00u2p6oTw8d6EN8l; Wed, 18 Jan 2012 18:14:32 +0000 From: "David Harrington" To: Date: Wed, 18 Jan 2012 10:14:15 -0800 Message-ID: <601CD36BD08A483B903F77D678EEEFB3@davidPC> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.1.7601.17609 Thread-Index: AczWDPyf6/r/cuKQQUqz4za3DZ2CLg== Subject: [BEHAVE] approved: draft-ietf-behave-v4v6-bih 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, 18 Jan 2012 18:14:38 -0000 Hi, This draft has been approved. Thanks to all involved. David Harrington Director, IETF Transport Area ietfdbh@comcast.net (preferred for ietf) dbharrington@huaweisymantec.com +1 603 828 1401 (cell) From iesg-secretary@ietf.org Wed Jan 18 10:48: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 BCFF621F869E; Wed, 18 Jan 2012 10:48:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nXYbkIUK0bMp; Wed, 18 Jan 2012 10:48:03 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2222111E80A5; Wed, 18 Jan 2012 10:48:03 -0800 (PST) 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: 3.64p1 Message-ID: <20120118184803.8746.18775.idtracker@ietfa.amsl.com> Date: Wed, 18 Jan 2012 10:48:03 -0800 Cc: behave mailing list , behave chair , RFC Editor Subject: [BEHAVE] Protocol Action: 'Dual Stack Hosts Using "Bump-in-the-Host" (BIH)' to Proposed Standard (draft-ietf-behave-v4v6-bih-09.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, 18 Jan 2012 18:48:03 -0000 The IESG has approved the following document: - 'Dual Stack Hosts Using "Bump-in-the-Host" (BIH)' (draft-ietf-behave-v4v6-bih-09.txt) as a Proposed Standard This document is the product of the Behavior Engineering for Hindrance Avoidance Working Group. The IESG contact persons are David Harrington and Wesley Eddy. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-behave-v4v6-bih/ Technical Summary Bump-In-the-Host (BIH) is a host-based IPv4 to IPv6 protocol translation mechanism that allows a class of IPv4-only applications that work through NATs to communicate with IPv6-only peers. The host on which applications are running may be connected to IPv6-only or dual-stack access networks. BIH hides IPv6 and makes the IPv4-only applications think they are talking with IPv4 peers by local synthesis of IPv4 addresses. This draft obsoletes RFC 2767 and RFC 3338. Working Group Summary The primary point of earlier contention was with respect to whether this NAT46-in-a-host could be placed behind a NAT64 and achieve NAT464. The WG consensus was that that case should be disallowed, and the present document reflects that consensus. Document Quality This document obsoletes two previous RFCs on implementation, and updates them based on implementation experience. At least one implementation is in progress for the new document, and others are expected. Personnel Document Shepherd: Dave Thaler Responsible Area Director: David Harrington From C.Grundemann@cablelabs.com Wed Jan 18 13:22: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 63E9C11E80A0 for ; Wed, 18 Jan 2012 13:22:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.332 X-Spam-Level: X-Spam-Status: No, score=0.332 tagged_above=-999 required=5 tests=[AWL=0.795, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] 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 CKvBRn8Zzzj7 for ; Wed, 18 Jan 2012 13:22:52 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id DE34811E809D for ; Wed, 18 Jan 2012 13:22:51 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id q0ILMoDX023688 for ; Wed, 18 Jan 2012 14:22:50 -0700 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Wed, 18 Jan 2012 14:22:50 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Wed, 18 Jan 2012 14:22:51 -0700 From: Chris Grundemann To: "behave@ietf.org" Date: Wed, 18 Jan 2012 14:22:47 -0700 Thread-Topic: New Version Notification for draft-donley-behave-deterministic-cgn-01.txt Thread-Index: AczWJ1SHI7KTZ/Q1T4CsP3RhZCbTzw== Message-ID: In-Reply-To: <20120118211331.27685.10724.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Subject: [BEHAVE] FW: New Version Notification for draft-donley-behave-deterministic-cgn-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: Wed, 18 Jan 2012 21:22:52 -0000 For the group's information: We have just submitted a new version of draft-donley-behave-deterministic-cgn which I believe addresses all feedback received so far. Cheers, ~Chris On 1/18/12 2:13 PM, "internet-drafts@ietf.org" wrote: >A new version of I-D, draft-donley-behave-deterministic-cgn-01.txt has >been successfully submitted by Chris Grundemann and posted to the IETF >repository. > >Filename: draft-donley-behave-deterministic-cgn >Revision: 01 >Title: Deterministic Address Mapping to Reduce Logging in Carrier Grade >NAT Deployments >Creation date: 2012-01-18 >WG ID: Individual Submission >Number of pages: 12 > >Abstract: > Many Carrier Grade NAT solutions require per-connection logging. > Unfortunately, such logging is not scalable to many residential > broadband services. This document suggests a way to manage Carrier > Grade NAT translations in such a way as to significantly reduce the > amount of logging required while providing traceability for abuse > response. > > > =20 > =20 > > >The IETF Secretariat From Gandhar.Gokhale@lsi.com Wed Jan 18 04:04: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 A518621F874C for ; Wed, 18 Jan 2012 04:04:07 -0800 (PST) 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 Bzg6Pj8g2nH7 for ; Wed, 18 Jan 2012 04:04:07 -0800 (PST) Received: from na3sys009aog113.obsmtp.com (na3sys009aog113.obsmtp.com [74.125.149.209]) by ietfa.amsl.com (Postfix) with ESMTP id 87CB921F8739 for ; Wed, 18 Jan 2012 04:04:06 -0800 (PST) Received: from paledge01.lsi.com ([192.19.193.42]) (using TLSv1) by na3sys009aob113.postini.com ([74.125.148.12]) with SMTP ID DSNKTxa1NUyPCVsjOxniqRex/FtA9YfU9uAZ@postini.com; Wed, 18 Jan 2012 04:04:06 PST Received: from PALHUB01.lsi.com (128.94.213.114) by PALEDGE01.lsi.com (192.19.193.42) with Microsoft SMTP Server (TLS) id 8.3.137.0; Wed, 18 Jan 2012 07:08:02 -0500 Received: from inbexch01.lsi.com (135.36.98.37) by PALHUB01.lsi.com (128.94.213.114) with Microsoft SMTP Server (TLS) id 8.3.106.1; Wed, 18 Jan 2012 07:04:04 -0500 Received: from inbmail01.lsi.com ([135.36.98.64]) by inbexch01.lsi.com ([135.36.98.37]) with mapi; Wed, 18 Jan 2012 17:34:01 +0530 From: "Gokhale, Gandhar" To: Alice Hagens Date: Wed, 18 Jan 2012 17:33:53 +0530 Thread-Topic: [Technical Errata Reported] RFC6145 (3061) Thread-Index: AczLvry/YFcF00qbRLuZdChaDrBNZgKGipkg Message-ID: <9181E99F41C081478B455A70FC1D01CB0D8BAF6DF2@inbmail01.lsi.com> References: <20111223111948.9759872E008@rfc-editor.org> <9181E99F41C081478B455A70FC1D01CB0D8B9DCEA2@inbmail01.lsi.com> <1A8E3EBB-E6BC-453C-9A26-5DD31CC3EA14@amsl.com> In-Reply-To: <1A8E3EBB-E6BC-453C-9A26-5DD31CC3EA14@amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 19 Jan 2012 10:17:29 -0800 Cc: "behave@ietf.org" , RFC Editor Subject: Re: [BEHAVE] [Technical Errata Reported] RFC6145 (3061) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2012 12:04:07 -0000 Hi Alice, I notice that these errata are still in the Reported state only. I'm wonder= ing why no attention is being given to them. Is there any process to raise = the visibility of? Our implementation is dependent on these changes. Thanks and regards, Gandhar Gokhale -----Original Message----- From: Alice Hagens [mailto:ahagens@amsl.com]=20 Sent: Thursday, 05 January, 2012 8:59 PM To: Gokhale, Gandhar Cc: behave@ietf.org; RFC Editor Subject: Re: [Technical Errata Reported] RFC6145 (3061) Greetings, On your side, there is no further action beyond participating (via email) i= f there is discussion of the errata triggered by the initial mail.=20 For RFCs from the IETF stream, the IESG reviews errata and marks them Verif= ied, Rejected, or Held for Document Update. This is described on the follow= ing pages: - How to Report Errata http://www.rfc-editor.org/how_to_report.html - IESG Processing of RFC Errata for the IETF Stream http://www.ietf.org/iesg/statement/errata-processing.html Please let us know if you have further questions. Thank you. RFC Editor/ah On Jan 5, 2012, at 3:27 AM, Gokhale, Gandhar wrote: > Hello, >=20 > I've submitted 3 errata on RFC 6145 (eid: 3059, 3060 & 3061) on December = 23rd, 2011. They are in reported state. I wonder if something needs to be d= one from my side for these to move to next state (approved/rejected etc). P= lease let me know when these will be taken up for conclusion. >=20 >=20 > Thanks and Regards, > Gandhar Gokhale > ________________________________________ > From: RFC Errata System [rfc-editor@rfc-editor.org] > Sent: Friday, December 23, 2011 4:49 PM > To: xing@cernet.edu.cn; congxiao@cernet.edu.cn; fred@cisco.com; ietfdbh@c= omcast.net; wes@mti-systems.com; dthaler@microsoft.com; dwing@cisco.com > Cc: Gokhale, Gandhar; behave@ietf.org; rfc-editor@rfc-editor.org > Subject: [Technical Errata Reported] RFC6145 (3061) >=20 > The following errata report has been submitted for RFC6145, > "IP/ICMP Translation Algorithm". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D6145&eid=3D3061 >=20 > -------------------------------------- > Type: Technical > Reported by: Gandhar Gokhale >=20 > Section: 5.1.1 >=20 > Original Text > ------------- > Fragment Offset: Copied from the Fragment Offset field of the IPv6 Fragm= ent Header. >=20 > Corrected Text > -------------- > Fragment Offset: If the Next Header field of the Fragment Header is not = an extension header (except ESP) then Fragment Offset MUST be copied from t= he Fragment Offset field of the IPv6 Fragment Header. If the Next Header fi= eld of the Fragment Header is an extension header (except ESP) then the pac= ket SHOULD be dropped and logged. >=20 >=20 >=20 >=20 >=20 > Notes > ----- > If the fragmentable part (as described in RFC 2460) of the original unfra= gmented IPv6 packet had extension headers then the translator can not calcu= late the offset of the IPv4 fragment for non-initial fragments. If extensio= n headers are present in the fragmentable part then the fragment offset val= ue of the IPv6 header includes length of the extension headers also. Since = translator strips of the IPv6 extension headers the fragment offset value s= et by the sender of IPv6 fragments can not match that received by the IPv4 = receiver and the reassembly will fail. For non-initial fragments the transl= ator does not have the knowledge of this delta when there is no state maint= ained. >=20 >=20 >=20 > The legth issue stated in erratum 2 is not in itself sufficient to advoca= te packet drop. However, the offset issue is sufficient to advocate packet = drop as the reassembly is bound to fail. Therefore I'm putting a SHOULD in = both cases. >=20 > 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. >=20 > -------------------------------------- > RFC6145 (draft-ietf-behave-v6v4-xlate-23) > -------------------------------------- > Title : IP/ICMP Translation Algorithm > Publication Date : April 2011 > Author(s) : X. Li, C. Bao, F. Baker > Category : PROPOSED STANDARD > Source : Behavior Engineering for Hindrance Avoidance > Area : Transport > Stream : IETF > Verifying Party : IESG >=20 From dthaler@microsoft.com Thu Jan 19 12:11: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 D999421F864D for ; Thu, 19 Jan 2012 12:11:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.841 X-Spam-Level: X-Spam-Status: No, score=-103.841 tagged_above=-999 required=5 tests=[AWL=-0.242, 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 tyz-DmpUYdza for ; Thu, 19 Jan 2012 12:10:59 -0800 (PST) Received: from AM1EHSOBE005.bigfish.com (am1ehsobe005.messaging.microsoft.com [213.199.154.208]) by ietfa.amsl.com (Postfix) with ESMTP id 69AFA21F8554 for ; Thu, 19 Jan 2012 12:10:59 -0800 (PST) Received: from mail23-am1-R.bigfish.com (10.3.201.240) by AM1EHSOBE005.bigfish.com (10.3.204.25) with Microsoft SMTP Server id 14.1.225.23; Thu, 19 Jan 2012 20:10:57 +0000 Received: from mail23-am1 (localhost [127.0.0.1]) by mail23-am1-R.bigfish.com (Postfix) with ESMTP id 144EB60335 for ; Thu, 19 Jan 2012 20:10:50 +0000 (UTC) X-SpamScore: -8 X-BigFish: VS-8(zz936eK11fbMzz1202hzzz2fhc1bhc31hc1ah2a8h668h839h944h) 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 Received-SPF: pass (mail23-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=TK5EX14HUBC102.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail23-am1 (localhost.localdomain [127.0.0.1]) by mail23-am1 (MessageSwitch) id 1327003848618471_3137; Thu, 19 Jan 2012 20:10:48 +0000 (UTC) Received: from AM1EHSMHS002.bigfish.com (unknown [10.3.201.254]) by mail23-am1.bigfish.com (Postfix) with ESMTP id 932B0220046 for ; Thu, 19 Jan 2012 20:10:48 +0000 (UTC) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS002.bigfish.com (10.3.207.102) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 19 Jan 2012 20:10:53 +0000 Received: from TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com (157.54.24.14) by TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) with Microsoft SMTP Server (TLS) id 14.2.247.5; Thu, 19 Jan 2012 12:10:45 -0800 Received: from TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.90]) by TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com ([157.54.24.14]) with mapi id 14.01.0355.003; Thu, 19 Jan 2012 12:10:45 -0800 From: Dave Thaler To: "behave@ietf.org" Thread-Topic: BEHAVE WG errata review Thread-Index: AczW5mx+8jtugezTRsyZi0tOD+Amow== Date: Thu, 19 Jan 2012 20:10:44 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B39DF3C@TK5EX14MBXW603.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.43] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: [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: Thu, 19 Jan 2012 20:11:01 -0000 Below is my review of the 6 Behave errata currently in the reported state. Note that changing the state of errata is something only the IESG can do. The WG just makes recommendations. | RFC5780 | 2939 | 2011-08-17 | John Selbie | behave | Techn= ical |=20 Verified. But not worth opening the doc for in my opinion. The doc contradicts itself, one place saying that OTHER-ADDRESS has the same value as CHANGED-ADDRESS did, and the other place giving a new value, which matches the IANA registry. The statement explaining why it=20 has the same value (which it doesn't) should be removed. Propose to move to "Hold for Document update" per guideline=20 "Things that are clearly wrong but could not cause an implementation or deployment problem should be Hold for Document Update." | RFC5389 | 2972 | 2011-09-16 | Jack Bates | behave | Edito= rial | Verified. But not worth opening the doc for since as the reporter states, the intent is already quite clear. This is trivial where the lines in the = bit diagram don't line up (the fields shown are 17 and 15 bits instead of 16 and 16, where the text says 16). Propose to move to "Hold for Document update" per guideline=20 "Things that are clearly wrong but could not cause an implementation or deployment problem should be Hold for Document Update." | RFC6147 | 2975 | 2011-09-18 | Libor Polcak | behave | Techn= ical |=20 Verified. But not worth opening the doc for since the intent is already clear in my view. The sentence preceding the quoted one mentions=20 "::ffff:0:0/96" and then the quoted sentence says "::ffff/96" when it=20 means the former. This is similar to treating "192.168.0.0/16" and "192.168/16" as synonymous, but the "::" makes it more confusing. Propose to move to "Hold for Document update" per guideline=20 "Things that are clearly wrong but could not cause an implementation or deployment problem should be Hold for Document Update." | RFC6145 | 3060 | 2011-12-23 | Gandhar Gokhale | behave | Techn= ical |=20 I believe the filer is correct. The RFC does not contain the right stateme= nt with respect to handling of IPv6 extension headers. It says they're skipped wh= en=20 filling in the payload but it doesn't say they're skipped when filling in t= he length field. Propose to move to "Approved" per guideline "Only errors that could cause=20 implementation or deployment problems or significant confusion should be Approved." However, since the filer proposes what the "corrected" behavior is, I belie= ve we need WG consensus to approve that statement. | RFC6145 | 3059 | 2011-12-23 | Gandhar Gokhale | behave | Techn= ical |=20 I believe the filer is correct. Although the intent might be clear from Se= ction 4: " As with [RFC2765], the translating function specified in this document does not translate any IPv4 options, and it does not translate IPv6 extension headers except the Fragment Header." Although the Length portion of the omitted paragraph is actually covered by errata ID 3060 above (and we don't need 2 technical errata for the same thi= ng) the omitted paragraph does contain a statement about how to fill in the=20 Protocol field when IPv6 extension headers were present, which is nowhere=20 else in the doc and might not be obvious to an implementer from the=20 section 4 text. As such, propose to move to "Approved" per guideline "Only errors that=20 could cause implementation or deployment problems or significant confusion should be Approved." | RFC6145 | 3061 | 2011-12-23 | Gandhar Gokhale | behave | Techn= ical | The filer proposes to add a SHOULD to drop a fragment that couldn't be=20 reassembled at the destination (and proposes language that isn't tight,=20 since it doesn't say what the alternative to the SHOULD is, so I would not want to move it to Approved). I think this falls into the guideline "Changes that modify the working of a protocol to something that might be different from the intended consensus when the document was approved should be either Hold for Document Update or Rejected. Deciding between these two depends on judgment. Changes that are clearly modifications to the intended consensus, or involve large textual changes, should be=20 Rejected. In unclear situations, small changes can be Hold for Document=20 Update." Hence propose "Hold for Document Update". -Dave From dwing@cisco.com Thu Jan 19 14:36: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 51E6221F86B1; Thu, 19 Jan 2012 14:36:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.575 X-Spam-Level: X-Spam-Status: No, score=-106.575 tagged_above=-999 required=5 tests=[AWL=0.024, 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 iO-WHUwCu8oj; Thu, 19 Jan 2012 14:36:20 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id A57BA21F86A2; Thu, 19 Jan 2012 14:36:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1700; q=dns/txt; s=iport; t=1327012580; x=1328222180; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=CxDC4Hc3hp73U+jk+hvP2BlDl1Q9tsPmlDJpUOawScg=; b=II6X2YpFthIvwu1yw4ZoMo8osTk3q9kCTArUo+dxP6jBwc/byBcb9kmq yN+ybx9iSRnRR9nD+OsS5z16vnx+qnJjCBoWDReqgtUKUaoBnRr27hTzH fhABuq2kSzqzKOtvw4kKPePwsrP/VEyxmbX+wjSfhndNq22zI6ncEpYd+ A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFAAeaGE+rRDoI/2dsb2JhbABEnxmNX4EAgQWBeQgKARcQPw0FGFAjHAEEHheHYppUAZ4ziH0NAQQCAQEEAQQBAQEJAQQBAQMGAQEwAgEBCw8KARsHFhABAgEBBQMBAQEBAgEBAYMCKAQCAgsBCTuDHASIO4UDmkQ X-IronPort-AV: E=Sophos;i="4.71,538,1320624000"; d="scan'208";a="26261556" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 19 Jan 2012 22:36:20 +0000 Received: from dwingWS ([10.32.240.195]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q0JMaKGN024910; Thu, 19 Jan 2012 22:36:20 GMT From: "Dan Wing" To: Date: Thu, 19 Jan 2012 14:36:20 -0800 Message-ID: <07df01ccd6fa$c42cf330$4c86d990$@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: AczMD5IV4uwiuqavR363Rl5NSWOWMQ== Content-Language: en-us Cc: 'David B Harrington' , iesg-secretary@ietf.org, 'Dave Thaler' Subject: [BEHAVE] rescheduled BEHAVE interim: Friday, February 3, 7am Pacific Time (new date) 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, 19 Jan 2012 22:36:21 -0000 (Sorry, we have to reschedule this interim because I neglected to CC iesg-secretary. The interim meeting announced for January 26 is cancelled and replaced with this new February 3 meeting.) We would like to have an interim BEHAVE meeting on Friday, February 3, at 7am Pacific Time for 1.5 hours. WebEx and dial-in details and agenda are posted at http://trac.tools.ietf.org/wg/behave/trac/wiki/WikiStart This interim meeting is intended to discuss (at least, but not limited to) the MIB as well as the rfc4787-5382-5508 drafts, and will also be used by the chairs to determine if a face-to-face BEHAVE meeting is necessary at IETF83. Due to timing, we have requested a slot at IETF83, but may cancel it or request a shorter slot if there are not sufficient topics for a face-to-face meeting. If you have anything to discuss specific to BEHAVE, please send email to the chairs requesting a slot at the interim. An Internet-Draft is not necessary. Things like "My -00 draft will be edited to say ____" are what we are looking for. That is, we want to know of progress happening with various drafts, ongoing activity, etc. Most important is to bring to the interim meeting any problems where consensus may be necessary. Currently on the agenda, with updates to appear on our Wiki page (linked above): * CGN NAT MIB, draft-perreault-opsawg-natmib-bis, Simon Perreault, 20 minutes * Updates to NAT behavior standards, draft-penno-behave-rfc4787-5382-5508-bis, Reinaldo Penno, 30 minutes * Updates to CGN logging, draft-sivakumar-behave-nat-logging, Senthil Sivakumar, 20 minutes -Dan and Dave From wwwrun@ietfa.amsl.com Thu Jan 19 15:08:02 2012 Return-Path: X-Original-To: behave@ietf.org Delivered-To: behave@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 30) id 5983B21F8690; Thu, 19 Jan 2012 15:08:02 -0800 (PST) From: IESG Secretary To: IETF Announcement list Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20120119230802.5983B21F8690@ietfa.amsl.com> Date: Thu, 19 Jan 2012 15:08:02 -0800 (PST) Cc: behave@ietf.org Subject: [BEHAVE] BEHAVE WG Virtual Interim Meeting: Friday, February 3, 7am Pacific Time 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, 19 Jan 2012 23:08:02 -0000 We would like to have an interim BEHAVE meeting on Friday, February 3, at 7am Pacific Time for 1.5 hours. WebEx and dial-in details and agenda are posted at http://trac.tools.ietf.org/wg/behave/trac/wiki/WikiStart This interim meeting is intended to discuss (at least, but not limited to) the MIB as well as the rfc4787-5382-5508 drafts, and will also be used by the chairs to determine if a face-to-face BEHAVE meeting is necessary at IETF83. Due to timing, we have requested a slot at IETF83, but may cancel it or request a shorter slot if there are not sufficient topics for a face-to-face meeting. If you have anything to discuss specific to BEHAVE, please send email to the chairs requesting a slot at the interim. An Internet-Draft is not necessary. Things like "My -00 draft will be edited to say ____" are what we are looking for. That is, we want to know of progress happening with various drafts, ongoing activity, etc. Most important is to bring to the interim meeting any problems where consensus may be necessary. Currently on the agenda, with updates to appear on our Wiki page (linked above): * CGN NAT MIB, draft-perreault-opsawg-natmib-bis, Simon Perreault, 20 minutes * Updates to NAT behavior standards, draft-penno-behave-rfc4787-5382-5508-bis, Reinaldo Penno, 30 minutes * Updates to CGN logging, draft-sivakumar-behave-nat-logging, Senthil Sivakumar, 20 minutes -Dan and Dave From Tina.Tsou.Zouting@huawei.com Thu Jan 19 15: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 8DCBA21F84FE for ; Thu, 19 Jan 2012 15:24:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.576 X-Spam-Level: X-Spam-Status: No, score=-6.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 d3AUIGiz7pN4 for ; Thu, 19 Jan 2012 15:24:09 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id CBF7D21F84FD for ; Thu, 19 Jan 2012 15:24:08 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LY2004IFJNY3D@szxga05-in.huawei.com> for behave@ietf.org; Fri, 20 Jan 2012 07:23:58 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LY200B6KJNYOZ@szxga05-in.huawei.com> for behave@ietf.org; Fri, 20 Jan 2012 07:23:58 +0800 (CST) Received: from szxeml213-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGN16644; Fri, 20 Jan 2012 07:23:57 +0800 Received: from SZXEML411-HUB.china.huawei.com (10.82.67.138) by szxeml213-edg.china.huawei.com (172.24.2.30) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 20 Jan 2012 07:23:49 +0800 Received: from SZXEML526-MBS.china.huawei.com ([169.254.7.225]) by szxeml411-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Fri, 20 Jan 2012 07:23:37 +0800 Date: Thu, 19 Jan 2012 23:23:36 +0000 From: Tina TSOU X-Originating-IP: [10.212.244.172] To: Behave WG Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: Comments on draft-penno-behave-rfc4787-5382-5508-bis-02 Thread-index: AczXAVxqeBpYxp36RcGhFo8/3C2omA== X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: AK9r AUv9 BZLc CVFT C4tF Fu3m Gnx3 GoQk Hsgb HyiB IMa6 Ic40 JGJd JGUf JpCC Kuti; 1; YgBlAGgAYQB2AGUAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {4D90CBC2-75F7-4E36-A026-23D74AF4F3A9}; dABpAG4AYQAuAHQAcwBvAHUALgB6AG8AdQB0AGkAbgBnAEAAaAB1AGEAdwBlAGkALgBjAG8AbQA=; Thu, 19 Jan 2012 23:23:33 GMT; QwBvAG0AbQBlAG4AdABzACAAbwBuACAAZAByAGEAZgB0AC0AcABlAG4AbgBvAC0AYgBlAGgAYQB2AGUALQByAGYAYwA0ADcAOAA3AC0ANQAzADgAMgAtADUANQAwADgALQBiAGkAcwAtADAAMgA= x-cr-puzzleid: {4D90CBC2-75F7-4E36-A026-23D74AF4F3A9} X-CFilter-Loop: Reflected Subject: [BEHAVE] Comments on draft-penno-behave-rfc4787-5382-5508-bis-02 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, 19 Jan 2012 23:24:09 -0000 8. EIM Protocol Independent [RFC4787] [RFC5382]: REQ-1 Current RFCs do not specify whether EIM are protocol independent. In other words, if a outbound TCP SYN creates a mapping it is left undefined whether outbound UDP can reuse such mapping and create session. On the other hand, Stateful NAT64 [RFC6146] clearly specifies three binding information bases (TCP, UDP, ICMP). This document clarifies that EIM mappings SHOULD be protocol dependent . A knob MAY be provided in order allow protocols that multiplex TCP and UDP over the same source IP and port to use a single mapping. Would it be more accurate changing the title to "EIM Protocol Dependent", since "This document clarifies that EIM mappings SHOULD be protocol dependent ."? BTW, there is a redundant space after "dependent". Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html From rpenno@juniper.net Thu Jan 19 22:29:58 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 C033E21F8591 for ; Thu, 19 Jan 2012 22:29:58 -0800 (PST) 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 tuIJ4No-a-3z for ; Thu, 19 Jan 2012 22:29:58 -0800 (PST) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by ietfa.amsl.com (Postfix) with ESMTP id C1C2721F85D2 for ; Thu, 19 Jan 2012 22:29:56 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKTxkJ1QTizUrrybG3URr0+NjNJ/+is0+i@postini.com; Thu, 19 Jan 2012 22:29:57 PST Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 19 Jan 2012 22:27:38 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Fri, 20 Jan 2012 01:27:35 -0500 From: Reinaldo Penno To: Tina TSOU , Behave WG Date: Fri, 20 Jan 2012 01:27:32 -0500 Thread-Topic: [BEHAVE] Comments on draft-penno-behave-rfc4787-5382-5508-bis-02 Thread-Index: AczXAVxqeBpYxp36RcGhFo8/3C2omAAOzqxc Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.11.0.110726 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [BEHAVE] Comments on draft-penno-behave-rfc4787-5382-5508-bis-02 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, 20 Jan 2012 06:29:58 -0000 Good catch, yes I will change it. On 1/19/12 3:23 PM, "Tina TSOU" wrote: > 8. EIM Protocol Independent >=20 > [RFC4787] [RFC5382]: REQ-1 Current RFCs do not specify whether EIM > are protocol independent. In other words, if a outbound TCP SYN > creates a mapping it is left undefined whether outbound UDP can reuse > such mapping and create session. On the other hand, Stateful NAT64 > [RFC6146] clearly specifies three binding information bases (TCP, > UDP, ICMP). This document clarifies that EIM mappings SHOULD be > protocol dependent . A knob MAY be provided in order allow protocols > that multiplex TCP and UDP over the same source IP and port to use a > single mapping. >=20 > Would it be more accurate changing the title to "EIM Protocol Dependent", > since "This document clarifies that EIM mappings SHOULD be protocol depen= dent > ."? > BTW, there is a redundant space after "dependent". >=20 >=20 > Best Regards, > Tina TSOU > http://tinatsou.weebly.com/contact.html >=20 >=20 >=20 > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From internet-drafts@ietf.org Wed Jan 25 13:15: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 8F7F421F8627; Wed, 25 Jan 2012 13:15:13 -0800 (PST) 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.010, 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 c6wF2sm+eCXG; Wed, 25 Jan 2012 13:15:13 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BE8A21F851B; Wed, 25 Jan 2012 13:15:13 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120125211513.19306.92848.idtracker@ietfa.amsl.com> Date: Wed, 25 Jan 2012 13:15:13 -0800 Cc: behave@ietf.org Subject: [BEHAVE] I-D Action: draft-ietf-behave-nat64-discovery-heuristic-05.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 21:15:13 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Behavior Engineering for Hindrance Av= oidance Working Group of the IETF. Title : Discovery of a Network-Specific NAT64 Prefix using a Wel= l-Known Name Author(s) : Teemu Savolainen Jouni Korhonen Dan Wing Filename : draft-ietf-behave-nat64-discovery-heuristic-05.txt Pages : 14 Date : 2012-01-25 This document describes a method for detecting presence of DNS64 and for learning IPv6 prefix used for protocol translation on an access network without explicit support from the access network. The method depends on existence of a well-known IPv4-only domain name "ipv4only.arpa". The information learned enables applications and hosts to perform local IPv6 address synthesis and on dual-stack accesses avoid traversal through NAT64. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-nat64-discovery-heuri= stic-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-behave-nat64-discovery-heuris= tic-05.txt From teemu.savolainen@nokia.com Wed Jan 25 13:19: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 195F621F8628 for ; Wed, 25 Jan 2012 13:19:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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 4-bO9arhlD-T for ; Wed, 25 Jan 2012 13:19:45 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 5A13421F8627 for ; Wed, 25 Jan 2012 13:19:44 -0800 (PST) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q0PLJfiZ012134 for ; Wed, 25 Jan 2012 23:19:42 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.24]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 25 Jan 2012 23:19:40 +0200 Received: from 008-AM1MPN1-053.mgdnok.nokia.com ([169.254.3.196]) by 008-AM1MMR1-008.mgdnok.nokia.com ([65.54.30.24]) with mapi id 14.01.0355.003; Wed, 25 Jan 2012 22:19:39 +0100 From: To: Thread-Topic: [BEHAVE] I-D Action: draft-ietf-behave-nat64-discovery-heuristic-05.txt Thread-Index: AczbpruQwz+Z3pnhRXKe8oNhOKSr7g== Date: Wed, 25 Jan 2012 21:19:39 +0000 Message-ID: <916CE6CF87173740BC8A2CE443096962042B6DB0@008-AM1MPN1-053.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Nokia Internal Use Only;Project=None; x-titus-version: 3.3.8.1 x-headerinfofordlp: None x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7IiK+ntKbo4xPTApCTPxRn9XGhbBnmCVqn5Q5Oymo/pQG4Q2g2yALHK/AW/m+afozOvOn+8bMVc7Zy6+hIsveiaLrKfAYg/LFJNlWnUE4EN3n57Q4RlH0BP4Rhl+xCQqcmwrDdSYYDhryESE2ljP2ea67ktvm7IodwFM2P3sU7ezkJIXfmo+4/0EKYPSxpnkfl6yDrOo13tuA6bTs0IOHqvERJQl6zUCSWZmpPZTRS8+VbmmhOXSVSkFWYIkPat7oFRLQa9ZHRYz5ldsv5Q5junY= x-originating-ip: [10.162.89.107] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 25 Jan 2012 21:19:40.0483 (UTC) FILETIME=[0CA17130:01CCDBA7] X-Nokia-AV: Clean Subject: Re: [BEHAVE] I-D Action: draft-ietf-behave-nat64-discovery-heuristic-05.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 21:19:46 -0000 Hi all, Please see a revisited version with changes mostly focusing on the connecti= vity check section and on the DNSSEC section (improved descriptions for bot= h hosts and network - also an example configuration in the Appendix). All comments are very welcome so that we could get into WGLC in near future= . Best regards, Teemu > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of ext internet-drafts@ietf.org > Sent: 25. tammikuuta 2012 23:15 > To: i-d-announce@ietf.org > Cc: behave@ietf.org > Subject: [BEHAVE] I-D Action: draft-ietf-behave-nat64-discovery-heuristic= - > 05.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 a Network-Specific NAT64 Prefix usin= g a > Well-Known Name > Author(s) : Teemu Savolainen > Jouni Korhonen > Dan Wing > Filename : draft-ietf-behave-nat64-discovery-heuristic-05.tx= t > Pages : 14 > Date : 2012-01-25 > > This document describes a method for detecting presence of DNS64 and > for learning IPv6 prefix used for protocol translation on an access > network without explicit support from the access network. The method > depends on existence of a well-known IPv4-only domain name > "ipv4only.arpa". The information learned enables applications and > hosts to perform local IPv6 address synthesis and on dual-stack > accesses avoid traversal through NAT64. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-behave-nat64-discovery- > heuristic-05.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-behave-nat64-discovery-heur= istic- > 05.txt > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From cb.list6@gmail.com Thu Jan 26 20:56: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 1572E21F8631 for ; Thu, 26 Jan 2012 20:56:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QUusk-wAmBAS for ; Thu, 26 Jan 2012 20:56:05 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 567A221F862F for ; Thu, 26 Jan 2012 20:56:05 -0800 (PST) Received: by obbwc12 with SMTP id wc12so1567795obb.31 for ; Thu, 26 Jan 2012 20:56:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QR7/slxiE9u2kPkt885gVWT0yddQQA7wBjoUdhAS0aE=; b=EBc71YwpC9gCKPC7vYUrAInXTiB7w6knmqGFstARHxSpXGx9312aJiRjHfxI6ESbgV QfJfzuUBvVWzKJhCrs7M1BglrrG61hBntfxjjc2CT6shLqQ/1boHg0AkZ74HmTL3laBX R8H37x/cLS8CKtWa6gJF4Ow3/DQk6+sNnRTLc= MIME-Version: 1.0 Received: by 10.182.74.102 with SMTP id s6mr4934539obv.46.1327640164979; Thu, 26 Jan 2012 20:56:04 -0800 (PST) Received: by 10.182.171.10 with HTTP; Thu, 26 Jan 2012 20:56:04 -0800 (PST) In-Reply-To: <916CE6CF87173740BC8A2CE443096962042B6DB0@008-AM1MPN1-053.mgdnok.nokia.com> References: <916CE6CF87173740BC8A2CE443096962042B6DB0@008-AM1MPN1-053.mgdnok.nokia.com> Date: Thu, 26 Jan 2012 20:56:04 -0800 Message-ID: From: Cameron Byrne To: teemu.savolainen@nokia.com Content-Type: text/plain; charset=ISO-8859-1 Cc: behave@ietf.org Subject: Re: [BEHAVE] I-D Action: draft-ietf-behave-nat64-discovery-heuristic-05.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 04:56:06 -0000 Teemu and team, Thanks again for working on this. It is very useful work. To that end, it is cited in our 464XLAT work http://tools.ietf.org/html/draft-mawatari-v6ops-464xlat-00 , and the ideas have been included in 464XLAT Android code http://code.google.com/p/android-clat/ I am glad the DNSsec work is evolving, it think this be a very meaningful contribution. My comments are as follows: 1. "the information learned enables applications and hosts to perform local IPv6 address synthesis and on dual-stack accesses avoid traversal through NAT64." Can we generalize this further? You say applications and host, but i am thinking home gateways as well. Perhaps say "enables software to perform local IPv6 address synthesis..." ? You also use the term "node" in the draft, that may be a good fit. 2. "Furthermore, the host SHOULD cache the replies it receives and honor TTLs." Which TTL? The TTL or ipv4only.arpa that is used for discovery? Are you saying the discover of the PREF64 is bounded by a TTL? 3. The term NAT64 Prefix is used in this draft. Would it be better to use the term Pref64 that is used in RFC 6146 and 6147? Is NAT64 FQDN in section 3.1.1 the same thing? 4. Do you see any challenges for validating ULAs as the Pref64 with DNSsec? 5. "The host then does an A query of that hostname, which returns one or more A resource records, which are the IPv4-facing IP addresses of that NAT64." What IPv4 address of the NAT64? RFC 6146 refers to IPv4 transport address, which i believe are commonly known as the "NAT pool"... do you mean those addresses? Since they are tied into the state table, they are not going to respond to ICMP IPv4 packets. Also, i dont think any network operators wants you (or 30,000,000 cell phones) pinging their NAT box. There are much cheaper boxes to ping. This text needs to be pulled or completely reworked. I suggest not treating the topic of connectivity checks at all. 6. 3.1.1 #1 is not clear. Please elaborate on what that FQDN is supposed to be. 7. Perhaps a state diagram for how DNSSEC validation works with PREF64 would help. CB From teemu.savolainen@nokia.com Fri Jan 27 04:42: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 5DA1621F84D1 for ; Fri, 27 Jan 2012 04:42:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.182 X-Spam-Level: X-Spam-Status: No, score=-3.182 tagged_above=-999 required=5 tests=[AWL=0.417, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5TiYEwGBzRBs for ; Fri, 27 Jan 2012 04:42:28 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id DF32221F84CD for ; Fri, 27 Jan 2012 04:42:27 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q0RCgCsY023723; Fri, 27 Jan 2012 14:42:22 +0200 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); Fri, 27 Jan 2012 14:42:15 +0200 Received: from 008-AM1MPN1-053.mgdnok.nokia.com ([169.254.3.155]) by 008-AM1MMR1-010.mgdnok.nokia.com ([65.54.30.26]) with mapi id 14.01.0355.003; Fri, 27 Jan 2012 13:42:15 +0100 From: To: Thread-Topic: [BEHAVE] I-D Action: draft-ietf-behave-nat64-discovery-heuristic-05.txt Thread-Index: AczbpruQwz+Z3pnhRXKe8oNhOKSr7gBANuMAABGJ3GA= Date: Fri, 27 Jan 2012 12:42:14 +0000 Message-ID: <916CE6CF87173740BC8A2CE443096962042C1ADE@008-AM1MPN1-053.mgdnok.nokia.com> References: <916CE6CF87173740BC8A2CE443096962042B6DB0@008-AM1MPN1-053.mgdnok.nokia.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-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+/nZJb9Kg7IiK+ntKbo4xPTApCTPxRn9XGhbBnmCVqn5Q5Oymo/pQG4Q2g2yALHK/AW/m+afozOvOn+8bMVc7Zy6+hIsveiaLrKfAYg/LFJNlWnUE4EN3n57Q4RlH0BP4Rhl+xCQqcmwrDdSYYDhryESE2ljP2ea67ktvm7IodwFM2P3sU7ezkJIXfmo+4/0EKYPSxpnkfl6yDrOo13tuA6bTs0IOHqvERJQl6zUCSWZmpPZTRS8+VbmmhOXSVSkFWYIkPat7oFRLQa9ZHRYz5ldsv5Q5junY= x-originating-ip: [10.162.89.107] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 27 Jan 2012 12:42:15.0955 (UTC) FILETIME=[1979E630:01CCDCF1] X-Nokia-AV: Clean Cc: behave@ietf.org Subject: Re: [BEHAVE] I-D Action: draft-ietf-behave-nat64-discovery-heuristic-05.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 12:42:29 -0000 Cameron,=20 Thanks again for reviewing the document:) Replies inline: > To that end, it is cited in our 464XLAT work > http://tools.ietf.org/html/draft-mawatari-v6ops-464xlat-00 , and the idea= s > have been included in 464XLAT Android code > http://code.google.com/p/android-clat/ Very nice:-)=20 > 1. "the information learned enables applications and > hosts to perform local IPv6 address synthesis and on dual-stack > accesses avoid traversal through NAT64." >=20 > Can we generalize this further? You say applications and host, but i am > thinking home gateways as well. Perhaps say "enables software to perform > local IPv6 address synthesis..." ? You also use the term "node" in the d= raft, > that may be a good fit. We can, will think for better wording. =20 > 2. "Furthermore, the host SHOULD cache the replies it > receives and honor TTLs." Which TTL? The TTL or ipv4only.arpa that i= s > used for discovery? Are you saying the discover of the PREF64 is bounded= by > a TTL? Can be - the discovered Pref64::/n should remain valid at least for the dur= ation of TTL that was used by network's DNS64 to synthetize the AAAA record= . Hence node does not have to repeat discovery until the expiration of time= r. This can be clarified if you are ok with the idea. (The TTL of ipv4only.arpa is probably longer than of Pref64::/n, and the TT= L of Pref64::/n should not be longer than of ipv4only.arpa). > 3. The term NAT64 Prefix is used in this draft. Would it be better to u= se the > term Pref64 that is used in RFC 6146 and 6147? Is NAT64 FQDN in section > 3.1.1 the same thing? Good point, the RFC6052 didn't use this (only NSP and WKP), but Pref64::/n = is fine. Similar term for the NAT64 FQDN term probably is not used in these other do= cuments? I.e. other documents do not ask for naming the NAT64, while we do = for DNSSEC reasons. > 4. Do you see any challenges for validating ULAs as the Pref64 with DNSs= ec? Reverse lookup might be difficult, i.e. step 2 of 3.1.2, as there is no cen= trally managed ULA's yet... But I wonder if you could locally (in your DNS6= 4) catch PTR queries for "ULA".ip6.arpa and return NAT64 FQDN as a response= ? If so, maybe it would work? > 5. "The host then does an > A query of that hostname, which returns one or more A resource > records, which are the IPv4-facing IP addresses of that NAT64." > What IPv4 address of the NAT64? =20 External Internet facing IPv4 address of NAT64, any that is able to respond= to ICMP Echo Req. >RFC 6146 refers to IPv4 transport address, > which i believe are commonly known as the "NAT pool"... do you mean those >addresses? =20 Well, not if NAT64 drops ICMP echo requests sent to those addresses or if i= t forwards them to other nodes... I.e. preferably some other external IPv4 address NAT64 has.=20 Please note that this address can be any IPv4 address, for example as of de= dicated "ping server". But we thought it might be nice to keep the connecti= vity test "inside" NAT64 system. > Also, i dont think any network operators > wants you (or 30,000,000 cell phones) pinging their NAT box. There are > much cheaper boxes to ping. This text needs to be pulled or completely > reworked. I suggest not treating the topic of connectivity checks at all= . After ping they all send data through the NAT box:) But individual devices = should not send these ping tests too often - at most when learning Pref64::= /n and not again until TTL timeout or reconnect. But as written, connectivity test is not always required or useful: it may = unnecessarily increase latency if done only at the time when user's transpo= rt sessions is already starting - in which case it might be wiser just to p= roceed with transport session and see if it makes through or not.=20 Then again in some cases it might be useful, for example in the home gatewa= y scenario you introduced: if the home gateway does not perform connectivit= y test, it would be synthesizing AAAA records for local hosts using discove= red prefix without any knowledge if the prefix discovery was successful... = If it was not, clients behind home gateway would be trying connections with= broken IPv6 addresses.. So I'm not quite ready to remove the connectivity check, but we can try to = fine tune it. > 6. 3.1.1 #1 is not clear. Please elaborate on what that FQDN is supposed= to > be. Any Fully Qualified Domain Name, the exact name should not matter much. E.g= . "nat64.example.com".=20 > 7. Perhaps a state diagram for how DNSSEC validation works with > PREF64 would help. The numbered lists on 3.1.1 and 3.1.2 try to show it already.. and the DNSS= EC procedures should be described in DNSSEC specifications. Hence I'm not s= ure I understand what diagram would you like to see? Best regards, Teemu From stephan.lagerholm@secure64.com Fri Jan 27 08:11: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 D0BCB21F85FD for ; Fri, 27 Jan 2012 08:11:41 -0800 (PST) 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 52wankCYw9fQ for ; Fri, 27 Jan 2012 08:11:41 -0800 (PST) Received: from zimbra.secure64.com (unknown [64.92.221.189]) by ietfa.amsl.com (Postfix) with ESMTP id 1DAC821F85F3 for ; Fri, 27 Jan 2012 08:11:41 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.secure64.com (Postfix) with ESMTP id 56808B846E; Fri, 27 Jan 2012 09:11:40 -0700 (MST) 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 dymL7rRsakUf; Fri, 27 Jan 2012 09:11:39 -0700 (MST) Received: from exchange.secure64.com (exchange.secure64.com [192.168.254.250]) by zimbra.secure64.com (Postfix) with ESMTPSA id C9C53B8442; Fri, 27 Jan 2012 09:11:39 -0700 (MST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=secure64.com; s=2010; t=1327680699; bh=LBSjwWToLRQM8Wo9K+PlZNRxAnOn1DZl0KrKfZYyNzU=; h=MIME-Version:Content-Type:Content-Transfer-Encoding:Subject:Date: Message-ID:In-Reply-To:References:From:To:Cc; b=hJjdM6c4E5MyVZqK5o k0qcHlZHc2eLoZRUI0a9t0w/nR0YHUoeQEl01F/ObZzKLuColo6famiJtnQiPZMMZJP Wvz69Rk3BDUo4fp4ojxqSZmotUeT7bh1Le5k5vUvTP0zecMWK/ALNGsD9+n0dbqCqQG A+Oe8Vka+6jxsWeZxQA= Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 27 Jan 2012 09:11:44 -0700 Message-ID: In-Reply-To: <916CE6CF87173740BC8A2CE443096962042C1ADE@008-AM1MPN1-053.mgdnok.nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] I-D Action: draft-ietf-behave-nat64-discovery-heuristic-05.txt Thread-Index: AczbpruQwz+Z3pnhRXKe8oNhOKSr7gBANuMAABGJ3GAACBSmIA== References: <916CE6CF87173740BC8A2CE443096962042B6DB0@008-AM1MPN1-053.mgdnok.nokia.com> <916CE6CF87173740BC8A2CE443096962042C1ADE@008-AM1MPN1-053.mgdnok.nokia.com> From: "Stephan Lagerholm" To: Cc: behave@ietf.org Subject: Re: [BEHAVE] I-D Action: draft-ietf-behave-nat64-discovery-heuristic-05.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 16:11:41 -0000 Hi Teemu, I have some questions/comments on the draft: ------------ Introduction, third part: Additionally, DNS64 is not able to do IPv6 address synthesis for hosts running validating DNSSEC enabled resolvers, but instead the synthesis must be done by the hosts themselves. =20 How is the service provider's DNS64 able to distinguish between hosts running validating DNSSEC enabled resolvers and hosts that are not? Is the idea to simply stop the synthesis whenever a host sends a query with the DO bit set? ------------------------------ Host behavior, second part: When sending AAAA query for the well-known name a host MUST set "Checking Disabled (CD)" bit to zero, as otherwise the DNS64 will not perform IPv6 address synthesis hence does not reveal the IPv6 prefix(es) used for protocol translation. Where is it defined that CD should force the DNS server to stop DNS64 synthesis?=20 ------------------------------ Requirements for the network, bullet 3: Each NAT64 prefix MUST HAVE PTR record that points to corresponding NAT64 FQDN. Can somebody give me an example on how this PTR record would look like? How do you put PTR for a prefix? Is the idea to use the first address (0.0.0.0.0.0.0.[PREF64].ip6.arpa.)? ------------------------ Requirements for the network, bullet 5: 5. Have access network's authoritative nameservers to respond to DNS queries for the NAT64 FQDNs only when the queries have been originated from the network domain the NAT64 is serving. If the NAT64's AAAA records are made resolvable throughout the Internet, a possible misuse vector of the NAT64 prefixes and NAT64 FQDNs in other networks is enabled: an attacker in other access network may lure a host on that network to think it is configuring NAT64 prefix in secure manner, while in reality it is not as the node would be configuring NAT64 prefix in a network where the NAT64 prefix should not be used. I don't like this requirement because it is forcing the DNS server to support views. Additionally, you will have to update the authoritative DNS every time you start provisioning your clients with new addresses from new IPv6 networks. ------------------- Exit strategy: A day will come when this tool is no longer needed. At that point best suited techniques for implementing exit strategy will be documented. In the global scope the exit strategy may include sending NXDOMAIN replies by the authoritative name server of the well-known name with a very long TTL. The negative TTL is determined by the SOA record. If you are removing the ipv4only.arpa then you will get whatever negative TTL .arpa. is signaling today. It might not be that easy to convince the .arpa maintainers to increase the negative TTL. It would be better if something like ipv4.only.arpa is used, then the negative TTL can be changed independently. From cb.list6@gmail.com Fri Jan 27 08:24: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 98D9D21F85F0 for ; Fri, 27 Jan 2012 08:24:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.464 X-Spam-Level: X-Spam-Status: No, score=-3.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pfHKta3+-+kS for ; Fri, 27 Jan 2012 08:24:53 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 88E6721F85CD for ; Fri, 27 Jan 2012 08:24:53 -0800 (PST) Received: by dado14 with SMTP id o14so1810822dad.31 for ; Fri, 27 Jan 2012 08:24:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=OyelHPZHc2E+WswF4JkQJdfwy1OvDodvOsr5cKORwE4=; b=bliRACPFQeoMDfE/VHJaqbqyLS6dmdSSrAvV5/KlBtHZBX4o+LuXaE1SdrmTszTibU 59HCc2bnsg38BasR8knve0Ygs7Ut+DsOUG0qN9dYyqlOeMX3iRPB2HDhSJPXkQAGtzFb Uw5l4xcgDuZZMi9idXuCbUh6jbo/Nkff1XvwY= MIME-Version: 1.0 Received: by 10.68.217.230 with SMTP id pb6mr15187475pbc.70.1327681492931; Fri, 27 Jan 2012 08:24:52 -0800 (PST) Received: by 10.143.78.7 with HTTP; Fri, 27 Jan 2012 08:24:52 -0800 (PST) In-Reply-To: <916CE6CF87173740BC8A2CE443096962042C1ADE@008-AM1MPN1-053.mgdnok.nokia.com> References: <916CE6CF87173740BC8A2CE443096962042B6DB0@008-AM1MPN1-053.mgdnok.nokia.com> <916CE6CF87173740BC8A2CE443096962042C1ADE@008-AM1MPN1-053.mgdnok.nokia.com> Date: Fri, 27 Jan 2012 08:24:52 -0800 Message-ID: From: Cameron Byrne To: teemu.savolainen@nokia.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: behave@ietf.org Subject: Re: [BEHAVE] I-D Action: draft-ietf-behave-nat64-discovery-heuristic-05.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 16:24:55 -0000 Resending to the list -- in line On Jan 27, 2012 4:42 AM, wrote: > > Cameron, > > Thanks again for reviewing the document:) > > Replies inline: > > > To that end, it is cited in our 464XLAT work > > http://tools.ietf.org/html/draft-mawatari-v6ops-464xlat-00 , and the id= eas > > have been included in 464XLAT Android code > > http://code.google.com/p/android-clat/ > > Very nice:-) > > > 1. "the information learned enables applications and > > hosts to perform local IPv6 address synthesis and on dual-stack > > accesses avoid traversal through NAT64." > > > > Can we generalize this further? You say applications and host, but i a= m > > thinking home gateways as well. Perhaps say "enables software to perfor= m > > local IPv6 address synthesis..." ? You also use the term "node" in the= draft, > > that may be a good fit. > > We can, will think for better wording. > > > 2. "Furthermore, the host SHOULD cache the replies it > > receives and honor TTLs." Which TTL? The TTL or ipv4only.arpa that= is > > used for discovery? Are you saying the discover of the PREF64 is bound= ed by > > a TTL? > > Can be - the discovered Pref64::/n should remain valid at least for the d= uration of TTL that was used by network's DNS64 to synthetize the AAAA reco= rd. Hence node does not have to repeat discovery until the expiration of ti= mer. > > This can be clarified if you are ok with the idea. > > (The TTL of ipv4only.arpa is probably longer than of Pref64::/n, and the = TTL of Pref64::/n should not be longer than of ipv4only.arpa). > Well, in the draft, the only guidance for ipv4only.arpa ttl is that it not exceed 1 year... which does not help in this situation. The draft would benefit from explicitly stating discovered pref64 ttl =3D pref64 fqdn ttl. That way the ttl is completely in control of the network operator. > > 3. The term NAT64 Prefix is used in this draft. Would it be better to= use the > > term Pref64 that is used in RFC 6146 and 6147? Is NAT64 FQDN in sectio= n > > 3.1.1 the same thing? > > Good point, the RFC6052 didn't use this (only NSP and WKP), but Pref64::/= n is fine. > > Similar term for the NAT64 FQDN term probably is not used in these other = documents? I.e. other documents do not ask for naming the NAT64, while we d= o for DNSSEC reasons. > How about nat64 node fqdn? that is descriptive and specific. But really, this concept is not acceptable as i will discuss below. > > 4. Do you see any challenges for validating ULAs as the Pref64 with DN= Ssec? > > Reverse lookup might be difficult, i.e. step 2 of 3.1.2, as there is no c= entrally managed ULA's yet... But I wonder if you could locally (in your DN= S64) catch PTR queries for "ULA".ip6.arpa and return NAT64 FQDN as a respon= se? If so, maybe it would work? > I can likely make that work > > 5. "The host then does an > > A query of that hostname, which returns one or more A resource > > records, which are the IPv4-facing IP addresses of that NAT64." > > What IPv4 address of the NAT64? > > External Internet facing IPv4 address of NAT64, any that is able to respo= nd to ICMP Echo Req. > It does not need to be this way, right? What you really want is a pairing of dns records, right? If that is what is needed, then lets say that. I would much rather pair the pref64 fqdn with a dummy fqdn for this purpose. It is not acceptable to network operators to have a name for an interface we do not want traffic to be destine to. > >RFC 6146 refers to IPv4 transport address, > > which i believe are commonly known as the "NAT pool"... do you mean tho= se > >addresses? > > Well, not if NAT64 drops ICMP echo requests sent to those addresses or if= it forwards them to other nodes... > > I.e. preferably some other external IPv4 address NAT64 has. > > Please note that this address can be any IPv4 address, for example as of = dedicated "ping server". But we thought it might be nice to keep the connec= tivity test "inside" NAT64 system. > Not nice. Cgn boxes are lots of asics / fpga / blah and relatively weak control plane processors that explicitly rate limit icmp to avoid control plane resource attacks. You cannot prescribe how this can be treated, the existing text is not acceptable. It may be acceptable if you think NAT64 is a Linux box, but in may large deployments, it is a very different case. > > Also, i dont think any network operators > > wants you (or 30,000,000 cell phones) pinging their NAT box. There are > > much cheaper boxes to ping. This text needs to be pulled or completely > > reworked. I suggest not treating the topic of connectivity checks at a= ll. > > After ping they all send data through the NAT box:) But individual device= s should not send these ping tests too often - at most when learning Pref64= ::/n and not again until TTL timeout or reconnect. > Icmp to the cgn and icmp via the cgn/nat64 are treated very differently. The same can be said for core ip routers....and some vendors think cgn is a blade on a core router ... those core routers definately rate limit ICMP destine to the router itself. This cannot be changed. > But as written, connectivity test is not always required or useful: it ma= y unnecessarily increase latency if done only at the time when user's trans= port sessions is already starting - in which case it might be wiser just to= proceed with transport session and see if it makes through or not. > Yes. > Then again in some cases it might be useful, for example in the home gate= way scenario you introduced: if the home gateway does not perform connectiv= ity test, it would be synthesizing AAAA records for local hosts using disco= vered prefix without any knowledge if the prefix discovery was successful..= . If it was not, clients behind home gateway would be trying connections wi= th broken IPv6 addresses.. > Fine. But the method described is not acceptable. > So I'm not quite ready to remove the connectivity check, but we can try t= o fine tune it. > Ack > > 6. 3.1.1 #1 is not clear. Please elaborate on what that FQDN is suppos= ed to > > be. > > Any Fully Qualified Domain Name, the exact name should not matter much. E= .g. "nat64.example.com". > > > 7. Perhaps a state diagram for how DNSSEC validation works with > > PREF64 would help. > > The numbered lists on 3.1.1 and 3.1.2 try to show it already.. and the DN= SSEC procedures should be described in DNSSEC specifications. Hence I'm not= sure I understand what diagram would you like to see? > Since I was fuzzy on the taxonomy, the pieces were not fitting. Net net, this draft, IMHO, needs to define a procedure based on fqdn and optional connectivity checks. And. It is not acceptable to expect any interface on the nat64 node to have an fqdn or to send icmp connectivity checks to the nat64 node. The pref64 may have an fqdn, that does make sense to me. This draft would benefit from describing "what" needs to be done, not "how" it will be done. Cb > Best regards, > > Teemu From dwing@cisco.com Fri Jan 27 09:19: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 0AE1B21F859E for ; Fri, 27 Jan 2012 09:19:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.577 X-Spam-Level: X-Spam-Status: No, score=-106.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 KNDoc3JyPPhh for ; Fri, 27 Jan 2012 09:19:38 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 207F921F8592 for ; Fri, 27 Jan 2012 09:19:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=5002; q=dns/txt; s=iport; t=1327684778; x=1328894378; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=ZtbU2u5dfi6tsxZ7rbzzkbWzSHGG6U8Vx7lWTmLcVLo=; b=fo73PK1qjOQIIvtYj3kkMkmpSN0spj5++oTqicb8ytxPSEChGiFoBY7b tYchJbhSIL8a/5J6Htabv/e4b4lgpljOj/3LCiXcbkI14VCAGIez9tBgi OHR5PDDJ6RsNZMHfjHe/rFFJFLdOh2bshxY9xMJnCRjbkpUa5FIScIFmK Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFACPcIk+rRDoI/2dsb2JhbABCAZ9cjnWBBYFyAQEBBAgKARcQLRIMAQMCGAIEAQEaAggEBxkjCgkIAQEEARILF4dimWcBnkKJCQcBJAsnEQIPhBMgBRINIwGDCgSIP4UEmkU X-IronPort-AV: E=Sophos;i="4.71,581,1320624000"; d="scan'208";a="27499579" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 27 Jan 2012 17:19:38 +0000 Received: from dwingWS ([10.32.240.197]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q0RHJbMg017398; Fri, 27 Jan 2012 17:19:37 GMT From: "Dan Wing" To: "'Stephan Lagerholm'" , References: <916CE6CF87173740BC8A2CE443096962042B6DB0@008-AM1MPN1-053.mgdnok.nokia.com> <916CE6CF87173740BC8A2CE443096962042C1ADE@008-AM1MPN1-053.mgdnok.nokia.com> In-Reply-To: Date: Fri, 27 Jan 2012 09:19:37 -0800 Message-ID: <158001ccdd17$d8c00170$8a400450$@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: AczbpruQwz+Z3pnhRXKe8oNhOKSr7gBANuMAABGJ3GAACBSmIAABw7+Q Content-Language: en-us Cc: behave@ietf.org Subject: [BEHAVE] DNSSEC and NAT64 Discovery Heuristic [was RE: I-D Action: draft-ietf-behave-nat64-discovery-heuristic-05.txt] X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 17:19:39 -0000 > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of Stephan Lagerholm > Sent: Friday, January 27, 2012 8:12 AM > To: teemu.savolainen@nokia.com > Cc: behave@ietf.org > Subject: Re: [BEHAVE] I-D Action: draft-ietf-behave-nat64-discovery- > heuristic-05.txt > > Hi Teemu, > > I have some questions/comments on the draft: > > > ------------ > Introduction, third part: > > Additionally, DNS64 is not able to do IPv6 address synthesis for > hosts running validating DNSSEC enabled resolvers, but instead the > synthesis must be done by the hosts themselves. > > How is the service provider's DNS64 able to distinguish between hosts > running validating DNSSEC enabled resolvers and hosts that are not? Is > the idea to simply stop the synthesis whenever a host sends a query > with the DO bit set? AAAA synthesis has to be skipped of CD is set, http://tools.ietf.org/html/rfc6147#page-8, ... If a query arrives at a vDNS64 device with the "Checking Disabled" (CD) bit set, it is an indication that the querying agent wants all the validation data so it can do checking itself. ... > ------------------------------ > Host behavior, second part: > When sending AAAA query for the well-known name a host MUST set > "Checking Disabled (CD)" bit to zero, as otherwise the DNS64 will > not > perform IPv6 address synthesis hence does not reveal the IPv6 > prefix(es) used for protocol translation. > > Where is it defined that CD should force the DNS server to stop DNS64 > synthesis? RFC6147. The DNSSEC text is all mine, and I believe it's correct and aligned with RFC6147. If there is a mistake, we will get it fixed. > ------------------------------ > Requirements for the network, bullet 3: > Each NAT64 prefix MUST HAVE PTR record that points to > corresponding NAT64 FQDN. > > Can somebody give me an example on how this PTR record would look like? > How do you put PTR for a prefix? Is the idea to use the first address > (0.0.0.0.0.0.0.[PREF64].ip6.arpa.)? http://tools.ietf.org/html/draft-ietf-behave-nat64-discovery-heuristic-05#ap pendix-A If there is a better format for showing that example, let me know. I just used a BIND example configuration that I had laying around. > ------------------------ > Requirements for the network, bullet 5: > 5. Have access network's authoritative nameservers to respond to > DNS > queries for the NAT64 FQDNs only when the queries have been > originated from the network domain the NAT64 is serving. If the > NAT64's AAAA records are made resolvable throughout the > Internet, > a possible misuse vector of the NAT64 prefixes and NAT64 FQDNs > in > other networks is enabled: an attacker in other access network > may lure a host on that network to think it is configuring NAT64 > prefix in secure manner, while in reality it is not as the node > would be configuring NAT64 prefix in a network where the NAT64 > prefix should not be used. > > I don't like this requirement because it is forcing the DNS server to > support views. Additionally, you will have to update the authoritative > DNS every time you start provisioning your clients with new addresses > from new IPv6 networks. Fair point. Teemu, Jouni, thoughts on this? > ------------------- > Exit strategy: > > A day will come when this tool is no longer needed. At that point > best suited techniques for implementing exit strategy will be > documented. In the global scope the exit strategy may include > sending NXDOMAIN replies by the authoritative name server of the > well-known name with a very long TTL. > > The negative TTL is determined by the SOA record. If you are removing > the ipv4only.arpa then you will get whatever negative TTL .arpa. is > signaling today. It might not be that easy to convince the .arpa > maintainers to increase the negative TTL. It would be better if > something like ipv4.only.arpa is used, then the negative TTL can be > changed independently. Myself, I don't think we could ever reach Internet-wide consensus that NXDOMAIN should be returned; there is always legacy equipment running somewhere. Some folks still have active X.25 networks, for example, and horses and carriages. Within a network, I could see someone (e.g., a mobile operator) deciding that their equipment shouldn't use draft-ietf-behave-nat64-discovery-heuristic and they might become authoritative for ipv4only.arpa (yes, I know that is frowned upon by DNS purists. But we all know it happens. It would work as long as ipv4-only.arpa But you bring up a tangential point, that "ipv4only.arpa" isn't the best choice of name -- we could benefit from a zone below the top- level arpa domain so the SOA can be self-contained for just this heuristic. -d From stephan.lagerholm@secure64.com Fri Jan 27 12:49: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 E3F7321F8664 for ; Fri, 27 Jan 2012 12:49:08 -0800 (PST) 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=[AWL=-0.001, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, NORMAL_HTTP_TO_IP=0.001, 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 Gj+e0yBjomyI for ; Fri, 27 Jan 2012 12:49:08 -0800 (PST) Received: from zimbra.secure64.com (unknown [64.92.221.189]) by ietfa.amsl.com (Postfix) with ESMTP id 357A521F8643 for ; Fri, 27 Jan 2012 12:49:08 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.secure64.com (Postfix) with ESMTP id A807DB8483; Fri, 27 Jan 2012 13:49:07 -0700 (MST) 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 uSHnj+7fRG5h; Fri, 27 Jan 2012 13:49:06 -0700 (MST) Received: from exchange.secure64.com (exchange.secure64.com [192.168.254.250]) by zimbra.secure64.com (Postfix) with ESMTPSA id 97D75B8478; Fri, 27 Jan 2012 13:49:06 -0700 (MST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=secure64.com; s=2010; t=1327697346; bh=3uzSC6uFBpppHjyB/n4AkDkbeCglg4cvj4hMZFDffUI=; h=MIME-Version:Content-Type:Content-Transfer-Encoding:Subject:Date: Message-ID:In-Reply-To:References:From:To:Cc; b=PZ+6Fi9EPq+cIzQoPK YlFj72CN3sBGPYQ3K2Fz+3CqIG6D+daEItCQoK8Dc/UWDM1C43P7Cno934vblnoVs06 k0ANMMFlLljeCIl9y++auOl5eC8VNZ0IwVRtV6iZxObuRWxjsScU5ODcwmji91JIZF9 G367zOOf1zVluxao7h8= Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 27 Jan 2012 13:45:32 -0700 Message-ID: In-Reply-To: <158001ccdd17$d8c00170$8a400450$@com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] DNSSEC and NAT64 Discovery Heuristic [was RE: I-D Action:draft-ietf-behave-nat64-discovery-heuristic-05.txt] Thread-Index: AczbpruQwz+Z3pnhRXKe8oNhOKSr7gBANuMAABGJ3GAACBSmIAABw7+QAAanLaA= References: <916CE6CF87173740BC8A2CE443096962042B6DB0@008-AM1MPN1-053.mgdnok.nokia.com> <916CE6CF87173740BC8A2CE443096962042C1ADE@008-AM1MPN1-053.mgdnok.nokia.com> <158001ccdd17$d8c00170$8a400450$@com> From: "Stephan Lagerholm" To: "Dan Wing" , Cc: behave@ietf.org Subject: Re: [BEHAVE] DNSSEC and NAT64 Discovery Heuristic [was RE: I-D Action:draft-ietf-behave-nat64-discovery-heuristic-05.txt] X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 20:49:09 -0000 Hi Dan and thanks for the reply, See inline. > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of Dan Wing > Sent: Friday, January 27, 2012 11:20 AM > To: Stephan Lagerholm; teemu.savolainen@nokia.com > Cc: behave@ietf.org > Subject: [BEHAVE] DNSSEC and NAT64 Discovery Heuristic [was RE: I-D > Action:draft-ietf-behave-nat64-discovery-heuristic-05.txt] >=20 > > -----Original Message----- > > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > > Behalf Of Stephan Lagerholm > > Sent: Friday, January 27, 2012 8:12 AM > > To: teemu.savolainen@nokia.com > > Cc: behave@ietf.org > > Subject: Re: [BEHAVE] I-D Action: draft-ietf-behave-nat64-discovery- > > heuristic-05.txt > > > > Hi Teemu, > > > > I have some questions/comments on the draft: > > > > > > ------------ > > Introduction, third part: > > > > Additionally, DNS64 is not able to do IPv6 address synthesis for > > hosts running validating DNSSEC enabled resolvers, but instead the > > synthesis must be done by the hosts themselves. > > > > How is the service provider's DNS64 able to distinguish between hosts > > running validating DNSSEC enabled resolvers and hosts that are not? > Is > > the idea to simply stop the synthesis whenever a host sends a query > > with the DO bit set? >=20 > AAAA synthesis has to be skipped of CD is set, > http://tools.ietf.org/html/rfc6147#page-8, Your assuming that a validating DNS server sets the CD bit on all upstream queries. That might not be true, at least not until draft-ietf-dnsext-dnssec-bis-updates section 5.9 is hammered out. People are still arguing if always setting CD is the right behavior or not.=20 (I guess that is more of a problem for RFC6147 than it is for this draft) > > ------------------------------ > > Requirements for the network, bullet 3: > > Each NAT64 prefix MUST HAVE PTR record that points to > > corresponding NAT64 FQDN. > > > > Can somebody give me an example on how this PTR record would look > like? > > How do you put PTR for a prefix? Is the idea to use the first address > > (0.0.0.0.0.0.0.[PREF64].ip6.arpa.)? >=20 > http://tools.ietf.org/html/draft-ietf-behave-nat64-discovery-heuristic- > 05#ap > pendix-A >=20 > If there is a better format for showing that example, let me know. I > just > used a BIND example configuration that I had laying around. Thanks for pointing me to Appendix A. How will the current wording in the draft harmonize with RFC6147 option 2 that says that the DNS64 server should respond to that query with: 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.IP6.ARPA. CNAME 0.0.0.0.in-addr.arpa.=09 The query will in other words not reach the server authoritative for 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.IP6.ARPA Or am I missing something? Thanks /Stephan From ajs@anvilwalrusden.com Fri Jan 27 13:16: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 C3D0C21F86B7 for ; Fri, 27 Jan 2012 13:16:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.652 X-Spam-Level: X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[AWL=-0.053, 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 38V3gUn3BrRb for ; Fri, 27 Jan 2012 13:16:03 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 2BA6A21F86B0 for ; Fri, 27 Jan 2012 13:16:03 -0800 (PST) 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 499BB1ECB41F for ; Fri, 27 Jan 2012 21:16:02 +0000 (UTC) Date: Fri, 27 Jan 2012 16:15:58 -0500 From: Andrew Sullivan To: behave@ietf.org Message-ID: <20120127211558.GG17728@mail.yitter.info> References: <916CE6CF87173740BC8A2CE443096962042B6DB0@008-AM1MPN1-053.mgdnok.nokia.com> <916CE6CF87173740BC8A2CE443096962042C1ADE@008-AM1MPN1-053.mgdnok.nokia.com> <158001ccdd17$d8c00170$8a400450$@com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [BEHAVE] DNSSEC and NAT64 Discovery Heuristic [was RE: I-D Action:draft-ietf-behave-nat64-discovery-heuristic-05.txt] X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 21:16:03 -0000 On Fri, Jan 27, 2012 at 01:45:32PM -0700, Stephan Lagerholm wrote: > > > > AAAA synthesis has to be skipped of CD is set, > > http://tools.ietf.org/html/rfc6147#page-8, > > Your assuming that a validating DNS server sets the CD bit on all > upstream queries. That might not be true, at least not until > draft-ietf-dnsext-dnssec-bis-updates section 5.9 is hammered out. People > are still arguing if always setting CD is the right behavior or not. > (I guess that is more of a problem for RFC6147 than it is for this > draft) That isn't the assumption there. The assumption in there is that, if you want to do DNSSEC behind a NAT64, then you have to do your own validation. Moreover, if you want to do your own validation, then you MUST set the CD bit, because otherwise you will get an unvalidatable answer (from the DNS64). This does mean that, in the presence of a DNS64, you can never do validation where you know you have only a partial TA list. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From dwing@cisco.com Fri Jan 27 13:29: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 9748B21F8685 for ; Fri, 27 Jan 2012 13:29:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.562 X-Spam-Level: X-Spam-Status: No, score=-106.562 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, NORMAL_HTTP_TO_IP=0.001, 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 2guP4NO5y2Rw for ; Fri, 27 Jan 2012 13:29:34 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id A468821F865C for ; Fri, 27 Jan 2012 13:29:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=5039; q=dns/txt; s=iport; t=1327699774; x=1328909374; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=blgLYPITJTyYYXZPdzgVXOUHL5OYNMDT3YNQeF9u0Rs=; b=A7CKAwOhH5PzewYyNsvC7DtEn/YnwuHmwTjzQ6Kxq323wZ3GfCGyDL4v 2XaaOr56ZghGD9FlxBGuO0kizsS5Xt6n1q8GWW4njuJI397wcMoHv0am7 g7wt/rZCYfH/6tnKCD/gCZLedLbduzMFwlbsnNJXhr4SXJ/LBZJ+bMDiC c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFALoWI0+rRDoJ/2dsb2JhbABEniiBNo4jU4EFgXIBAQEDAQgKARcQEQEtBQcBAwIJDwICAgEBJAQHGQwXCgkIAgQBEgsXh1oImV0BkQ4BjSyJEAEkCycRAg+EEzcNgy4EiD+FBJpF X-IronPort-AV: E=Sophos;i="4.71,582,1320624000"; d="scan'208";a="27541417" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 27 Jan 2012 21:29:34 +0000 Received: from dwingWS ([10.32.240.197]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q0RLTX99022703; Fri, 27 Jan 2012 21:29:34 GMT From: "Dan Wing" To: "'Stephan Lagerholm'" , References: <916CE6CF87173740BC8A2CE443096962042B6DB0@008-AM1MPN1-053.mgdnok.nokia.com> <916CE6CF87173740BC8A2CE443096962042C1ADE@008-AM1MPN1-053.mgdnok.nokia.com> <158001ccdd17$d8c00170$8a400450$@com> In-Reply-To: Date: Fri, 27 Jan 2012 13:29:33 -0800 Message-ID: <170301ccdd3a$c3563430$4a029c90$@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: AczbpruQwz+Z3pnhRXKe8oNhOKSr7gBANuMAABGJ3GAACBSmIAABw7+QAAanLaAAAhdj4A== Content-Language: en-us Cc: behave@ietf.org Subject: Re: [BEHAVE] DNSSEC and NAT64 Discovery Heuristic [was RE: I-D Action:draft-ietf-behave-nat64-discovery-heuristic-05.txt] X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 21:29:35 -0000 > -----Original Message----- > From: Stephan Lagerholm [mailto:stephan.lagerholm@secure64.com] > Sent: Friday, January 27, 2012 12:46 PM > To: Dan Wing; teemu.savolainen@nokia.com > Cc: behave@ietf.org > Subject: RE: [BEHAVE] DNSSEC and NAT64 Discovery Heuristic [was RE: I-D > Action:draft-ietf-behave-nat64-discovery-heuristic-05.txt] > > Hi Dan and thanks for the reply, See inline. > > > -----Original Message----- > > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > > Behalf Of Dan Wing > > Sent: Friday, January 27, 2012 11:20 AM > > To: Stephan Lagerholm; teemu.savolainen@nokia.com > > Cc: behave@ietf.org > > Subject: [BEHAVE] DNSSEC and NAT64 Discovery Heuristic [was RE: I-D > > Action:draft-ietf-behave-nat64-discovery-heuristic-05.txt] > > > > > -----Original Message----- > > > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > > > Behalf Of Stephan Lagerholm > > > Sent: Friday, January 27, 2012 8:12 AM > > > To: teemu.savolainen@nokia.com > > > Cc: behave@ietf.org > > > Subject: Re: [BEHAVE] I-D Action: draft-ietf-behave-nat64- > discovery- > > > heuristic-05.txt > > > > > > Hi Teemu, > > > > > > I have some questions/comments on the draft: > > > > > > > > > ------------ > > > Introduction, third part: > > > > > > Additionally, DNS64 is not able to do IPv6 address synthesis for > > > hosts running validating DNSSEC enabled resolvers, but instead > the > > > synthesis must be done by the hosts themselves. > > > > > > How is the service provider's DNS64 able to distinguish between > hosts > > > running validating DNSSEC enabled resolvers and hosts that are not? > > Is > > > the idea to simply stop the synthesis whenever a host sends a query > > > with the DO bit set? > > > > AAAA synthesis has to be skipped of CD is set, > > http://tools.ietf.org/html/rfc6147#page-8, > > Your assuming that a validating DNS server sets the CD bit on all > upstream queries. That might not be true, at least not until > draft-ietf-dnsext-dnssec-bis-updates section 5.9 is hammered out. > People > are still arguing if always setting CD is the right behavior or not. > (I guess that is more of a problem for RFC6147 than it is for this > draft) RFC6147 probably tacitly expects the validating DNS server is also the DNS64 (that is, the same box). If they are the same box I believe there isn't a problem with CD being propagated. If they are separate DNS servers (i.e., the DNS64 forwards the query to a DNSSEC-validating DNS server), then I agree RFC6147 creates a requirement that the DNS64 has to set CD if CD was set on the query it received. Thanks for referencing draft-ietf-dnsext-dnssec-bis-updates; I had not been tracking it. > > > ------------------------------ > > > Requirements for the network, bullet 3: > > > Each NAT64 prefix MUST HAVE PTR record that points to > > > corresponding NAT64 FQDN. > > > > > > Can somebody give me an example on how this PTR record would look > > like? > > > How do you put PTR for a prefix? Is the idea to use the first > address > > > (0.0.0.0.0.0.0.[PREF64].ip6.arpa.)? > > > > > http://tools.ietf.org/html/draft-ietf-behave-nat64-discovery-heuristic- > > 05#ap > > pendix-A > > > > If there is a better format for showing that example, let me know. I > > just > > used a BIND example configuration that I had laying around. > > Thanks for pointing me to Appendix A. How will the current wording in > the draft harmonize with RFC6147 option 2 You're referring to Option 2 in Section 5.3.1 of RFC6147, http://tools.ietf.org/html/rfc6147#section-5.3-1 > that says that the DNS64 > server should respond to that query with: > 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.IP6.ARPA. CNAME > 0.0.0.0.in-addr.arpa. > > The query will in other words not reach the server authoritative for > 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.IP6.ARPA > Or am I missing something? If that network is using the IANA-assigned Well Known Prefix for its NAT64, we are relying on Option 1 of Section 5.3.1 when it is responding to queries for that network's NAT64 prefix. So, if that network is using the IPv6 example address as its NSP, then for that ip6.arpa, it would need to use Option 1 -- and respond authoritatively for that prefix. Also, if trying to use Option 2, the ip6.arpa query won't have a valid IPv4 address so it can't query in-addr.arpa. If, for other prefixes, the DNS64 wants to do Option 2, it can do that (as allowed by the text in the paragraph immediately above Option 1 and Option 2). If that network is using its own prefix for its NAT64, I believe the DNS64 also needs to do Option 1 for that prefix. This is because Option 2 requires the ip6.arpa query has a an IPv4 address in the query (to query in-addr.arpa). Assuming I got that right, and I hope I did, I'll make a note to point this out in draft-ietf-behave-nat64-discovery-heuristic. -d From marka@isc.org Fri Jan 27 16:14: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 1707121F851D for ; Fri, 27 Jan 2012 16:14:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[AWL=0.104, 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 Un-S4ZjcSWWg for ; Fri, 27 Jan 2012 16:14:07 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 8F98021F851C for ; Fri, 27 Jan 2012 16:14:07 -0800 (PST) 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 "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id D64D8C9463; Sat, 28 Jan 2012 00:13:54 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:2d63:f876:b008:591a]) (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 98A2C216C6A; Sat, 28 Jan 2012 00:13:54 +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 926C91C2F84A; Sat, 28 Jan 2012 11:13:49 +1100 (EST) To: "Stephan Lagerholm" From: Mark Andrews References: <916CE6CF87173740BC8A2CE443096962042B6DB0@008-AM1MPN1-053.mgdnok.nokia.com> <916CE6CF87173740BC8A2CE443096962042C1ADE@008-AM1MPN1-053.mgdnok.nokia.com> In-reply-to: Your message of "Fri, 27 Jan 2012 09:11:44 PDT." Date: Sat, 28 Jan 2012 11:13:49 +1100 Message-Id: <20120128001349.926C91C2F84A@drugs.dv.isc.org> Cc: behave@ietf.org Subject: Re: [BEHAVE] I-D Action: draft-ietf-behave-nat64-discovery-heuristic-05.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jan 2012 00:14:08 -0000 In message , "Ste phan Lagerholm" writes: > Hi Teemu, > > I have some questions/comments on the draft: > > > ------------ > Introduction, third part: > > Additionally, DNS64 is not able to do IPv6 address synthesis for > hosts running validating DNSSEC enabled resolvers, but instead the > synthesis must be done by the hosts themselves. > > How is the service provider's DNS64 able to distinguish between hosts > running validating DNSSEC enabled resolvers and hosts that are not? Is > the idea to simply stop the synthesis whenever a host sends a query with > the DO bit set? > > > ------------------------------ > Host behavior, second part: > When sending AAAA query for the well-known name a host MUST set > "Checking Disabled (CD)" bit to zero, as otherwise the DNS64 will not > perform IPv6 address synthesis hence does not reveal the IPv6 > prefix(es) used for protocol translation. > > Where is it defined that CD should force the DNS server to stop DNS64 > synthesis? As a DNS server vendor if DO=1 and the anwser is signed you do not do synthesis as the client can detect it. CD=1 is *not* a indication that a client wants to validate. RFC 6147 is just plain wrong with this assertion. 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 Fri Jan 27 16:57: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 CCCA421F84F7 for ; Fri, 27 Jan 2012 16:57:39 -0800 (PST) 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 I1C9La8gHe2k for ; Fri, 27 Jan 2012 16:57:39 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 1E4C721F84D2 for ; Fri, 27 Jan 2012 16:57:38 -0800 (PST) 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 "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id 558A4C942D; Sat, 28 Jan 2012 00:57:17 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:2d63:f876:b008:591a]) (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 187DA216C6B; Sat, 28 Jan 2012 00:57:17 +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 BF0431C2FE52; Sat, 28 Jan 2012 11:57:14 +1100 (EST) To: Andrew Sullivan From: Mark Andrews References: <916CE6CF87173740BC8A2CE443096962042B6DB0@008-AM1MPN1-053.mgdnok.nokia.com> <916CE6CF87173740BC8A2CE443096962042C1ADE@008-AM1MPN1-053.mgdnok.nokia.com> <158001ccdd17$d8c00170$8a400450$@com> <20120127211558.GG17728@mail.yitter.info> In-reply-to: Your message of "Fri, 27 Jan 2012 16:15:58 CDT." <20120127211558.GG17728@mail.yitter.info> Date: Sat, 28 Jan 2012 11:57:14 +1100 Message-Id: <20120128005714.BF0431C2FE52@drugs.dv.isc.org> Cc: behave@ietf.org Subject: Re: [BEHAVE] DNSSEC and NAT64 Discovery Heuristic [was RE: I-D Action:draft-ietf-behave-nat64-discovery-heuristic-05.txt] X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jan 2012 00:57:39 -0000 In message <20120127211558.GG17728@mail.yitter.info>, Andrew Sullivan writes: > On Fri, Jan 27, 2012 at 01:45:32PM -0700, Stephan Lagerholm wrote: > > > > > > AAAA synthesis has to be skipped of CD is set, > > > http://tools.ietf.org/html/rfc6147#page-8, > > > > Your assuming that a validating DNS server sets the CD bit on all > > upstream queries. That might not be true, at least not until > > draft-ietf-dnsext-dnssec-bis-updates section 5.9 is hammered out. People > > are still arguing if always setting CD is the right behavior or not. > > (I guess that is more of a problem for RFC6147 than it is for this > > draft) > > That isn't the assumption there. > > The assumption in there is that, if you want to do DNSSEC behind a > NAT64, then you have to do your own validation. Moreover, if you want > to do your own validation, then you MUST set the CD bit, because > otherwise you will get an unvalidatable answer (from the DNS64). Which is not correct from a DNSSEC perspective. The *only* requirement to do your own validation is that DO=1. If you want to disable upstream validation you set CD=1. These are two independent operations. I really do expect applications to do DO=1/CD=0 and if that returns SERVFAIL to make a second DO=1/CD=1 query to remove upstream validation failures from the equation. The DO=1/CD=0 is needed so that the retry algorithms in the recursive resolver kick in on stale data from authoritative sources. The DO=1/CD=0 is needed for the case where the recusive server has a bad clock/stale trust anchors. RFC 6147 is just plain *wrong* with respect to DNSSEC and its statement that CD=1 indicates the client intends to validate. If the answer to the AAAA query is signed and the client made a DO=1 query you pass the answer back as is otherwise you can synthesis. We apply this to all forms of synthesis we do in named. NXDOMAIN redirection / DNS64 / AAAA filtering / RPZ (there is a bug fix for RPZ in the next maintenance release). -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From ajs@anvilwalrusden.com Sun Jan 29 08:45: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 7F2B821F85EF for ; Sun, 29 Jan 2012 08:45:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.646 X-Spam-Level: X-Spam-Status: No, score=-3.646 tagged_above=-999 required=5 tests=[AWL=0.953, BAYES_00=-2.599, GB_I_LETTER=-2] 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 S2tIKJWfhZ5Z for ; Sun, 29 Jan 2012 08:45:43 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id C8AC121F84EC for ; Sun, 29 Jan 2012 08:45:43 -0800 (PST) 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 F178D1ECB41C for ; Sun, 29 Jan 2012 16:45:42 +0000 (UTC) Date: Sun, 29 Jan 2012 11:45:54 -0500 From: Andrew Sullivan To: behave@ietf.org Message-ID: <20120129164553.GC19634@mail.yitter.info> References: <916CE6CF87173740BC8A2CE443096962042B6DB0@008-AM1MPN1-053.mgdnok.nokia.com> <916CE6CF87173740BC8A2CE443096962042C1ADE@008-AM1MPN1-053.mgdnok.nokia.com> <158001ccdd17$d8c00170$8a400450$@com> <20120127211558.GG17728@mail.yitter.info> <20120128005714.BF0431C2FE52@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120128005714.BF0431C2FE52@drugs.dv.isc.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [BEHAVE] DNSSEC and NAT64 Discovery Heuristic [was RE: I-D Action:draft-ietf-behave-nat64-discovery-heuristic-05.txt] X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jan 2012 16:45:44 -0000 On Sat, Jan 28, 2012 at 11:57:14AM +1100, Mark Andrews wrote: > > In message <20120127211558.GG17728@mail.yitter.info>, Andrew Sullivan writes: > > The assumption in there is that, if you want to do DNSSEC behind a > > NAT64, then you have to do your own validation. Moreover, if you > > want to do your own validation, then you MUST set the CD bit, > > because otherwise you will get an unvalidatable answer (from the > > DNS64). > > Which is not correct from a DNSSEC perspective. The *only* requirement > to do your own validation is that DO=1. If you want to disable > upstream validation you set CD=1. These are two independent > operations. That is true from a DNSSEC perspective when you are using the real DNS. But DNS64 _isn't_ the real DNS. It's a forked DNS tree: the DNS64 function systematically lies about what the answers from the DNS are. The only way to cope with that and still validate is to do the lying to yourself, and the only way to do the lying to yourself is to set the CD bit. Therefore, > I really do expect applications to do DO=1/CD=0 and if that returns > SERVFAIL to make a second DO=1/CD=1 query to remove upstream > validation failures from the equation. if you do this behind a DNS64, it's guaranteed to fail the first step every time. If you really expect applications to do that, what you're committing to is double the queries for zero benefit any time a DNS64 is involved. > RFC 6147 is just plain *wrong* with respect to DNSSEC and its statement > that CD=1 indicates the client intends to validate. I don't beleve RFC6147 makes that statement, but here are two pieces that I think could be read as implying such a statement. I agree that they ought to be clarified in a future revision of DNS64. I've given them letters in order to talk abotut them below. A If a query arrives at a vDNS64 device with the "Checking Disabled" (CD) bit set, it is an indication that the querying agent wants all the validation data so it can do checking itself. B 3. A security-aware and non-validating DNS64 receives a query with the DO bit set and the CD bit clear. Such a resolver is not validating responses, likely due to local policy (see [RFC4035], Section 4.2). For that reason, this case amounts to the same as the previous case, and no validation happens. (A) doesn't say that CD=1 indicates that the client intends to validate; it says that it means the querying agent wants the upstream to pass everything along. If you think that could be stated more clearly (and on re-reading it, I think it could be), then perhaps you can contribute such text for a future revision of DNS64. (B) says that CD=0 is an indication that a resolver "is not" validating; that is clearly an overstatement of the case, and should have been written as "might not be" validating. That said, note that RFC 4035 section 4.9.2 says this: A validating security-aware stub resolver SHOULD set the CD bit, because otherwise the security-aware recursive name server will answer the query using the name server's local policy, which may prevent the stub resolver from receiving data that would be acceptable to the stub resolver's local policy. > If the answer to the AAAA query is signed and the client made a > DO=1 query you pass the answer back as is otherwise you can synthesis. > We apply this to all forms of synthesis we do in named. NXDOMAIN > redirection / DNS64 / AAAA filtering / RPZ (there is a bug fix for > RPZ in the next maintenance release). The signed AAAA query from the global DNS is simply irrelevant here: in DNS64 that's supposed to work as you do it. The question is what happens when you need to synthesize AAAA from the (signed) A record, and in that case the _only_ reliable way to validate at the end point in DNS64 is to use CD=1. Anything else is automatically going to fail validation. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From marka@isc.org Sun Jan 29 15:08: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 4217A21F8532 for ; Sun, 29 Jan 2012 15:08:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.51 X-Spam-Level: X-Spam-Status: No, score=-3.51 tagged_above=-999 required=5 tests=[AWL=1.089, BAYES_00=-2.599, GB_I_LETTER=-2] 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 mZ8DbRhml1+A for ; Sun, 29 Jan 2012 15:08:49 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id E12C921F8531 for ; Sun, 29 Jan 2012 15:08:48 -0800 (PST) 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 "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id 970955F9865; Sun, 29 Jan 2012 23:08:28 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6d48:c4cd:82ef:670]) (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 54454216C6A; Sun, 29 Jan 2012 23:08:26 +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 4FE1B1C3B476; Mon, 30 Jan 2012 10:08:24 +1100 (EST) To: Andrew Sullivan From: Mark Andrews References: <916CE6CF87173740BC8A2CE443096962042B6DB0@008-AM1MPN1-053.mgdnok.nokia.com> <916CE6CF87173740BC8A2CE443096962042C1ADE@008-AM1MPN1-053.mgdnok.nokia.com> <158001ccdd17$d8c00170$8a400450$@com> <20120127211558.GG17728@mail.yitter.info> <20120128005714.BF0431C2FE52@drugs.dv.isc.org> <20120129164553.GC19634@mail.yitter.info> In-reply-to: Your message of "Sun, 29 Jan 2012 11:45:54 CDT." <20120129164553.GC19634@mail.yitter.info> Date: Mon, 30 Jan 2012 10:08:24 +1100 Message-Id: <20120129230824.4FE1B1C3B476@drugs.dv.isc.org> Cc: behave@ietf.org Subject: Re: [BEHAVE] DNSSEC and NAT64 Discovery Heuristic [was RE: I-D Action:draft-ietf-behave-nat64-discovery-heuristic-05.txt] X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jan 2012 23:08:50 -0000 In message <20120129164553.GC19634@mail.yitter.info>, Andrew Sullivan writes: > On Sat, Jan 28, 2012 at 11:57:14AM +1100, Mark Andrews wrote: > > > > In message <20120127211558.GG17728@mail.yitter.info>, Andrew Sullivan write > s: > > > > The assumption in there is that, if you want to do DNSSEC behind a > > > NAT64, then you have to do your own validation. Moreover, if you > > > want to do your own validation, then you MUST set the CD bit, > > > because otherwise you will get an unvalidatable answer (from the > > > DNS64). > > > > Which is not correct from a DNSSEC perspective. The *only* requirement > > to do your own validation is that DO=1. If you want to disable > > upstream validation you set CD=1. These are two independent > > operations. > > That is true from a DNSSEC perspective when you are using the real > DNS. But DNS64 _isn't_ the real DNS. It's a forked DNS tree: the > DNS64 function systematically lies about what the answers from the DNS > are. The only way to cope with that and still validate is to do the > lying to yourself, Good up to here > and the only way to do the lying to yourself is to > set the CD bit. Total rubbish. It is pointless to lie to a DO=1/CD=0 query as the client can detect the lie. > Therefore, > > I really do expect applications to do DO=1,CD=0 and if that returns > > SERVFAIL to make a second DO=1,CD=1 query to remove upstream > > validation failures from the equation. > > if you do this behind a DNS64, it's guaranteed to fail the first step > every time. If you really expect applications to do that, what you're > committing to is double the queries for zero benefit any time a DNS64 > is involved. A plain DNSSEC client is stuffed if DNS64 is applied to a response from a signed zone regardless of the state of CD. It is pointless to apply DNS64 synthesis, with a DO=1 query, to a answer from a signed zone regardless of what CD is set to even if you do understand DNS64. By *not* saying to disable DNS64 processing on DO=1, the working has made trouble shooting/working with DNSSEC issues harder, on validation failure the DNS64+DNSSEC aware client has to then ask a DO=1,CD=0 query, to cause the DNS64 recusive server to make upstream queries to get a good answer can be cached (ttl=0 is a problem here), which will just have to be discarded as it won't validate, then it will need to re-make the DO=1,CD=1 query to get the answer from the cache (assuming that it hasn't got flushed). What this WG should do is to define a EDNS option so that DNS64+DNSSEC aware clients can get the DNS64 prefix/suffix returned. Here is one that will work. DNS64 [ ] .... prefix + suffix is always 96 bits. If DNS64 does not apply then a empty set of prefixes is returned. The set of prefixes returned is specfic to this query. Alternatively a DNS64 DHCPv6 option should be defined and the DNS64+DNSSEC client can retrieve that. > > RFC 6147 is just plain *wrong* with respect to DNSSEC and its statement > > that CD=1 indicates the client intends to validate. > > I don't beleve RFC6147 makes that statement, but here are two pieces > that I think could be read as implying such a statement. I agree that > they ought to be clarified in a future revision of DNS64. I've given > them letters in order to talk abotut them below. > > A > If a query arrives at a vDNS64 device with the "Checking Disabled" > (CD) bit set, it is an indication that the querying agent wants all > the validation data so it can do checking itself. > > B > 3. A security-aware and non-validating DNS64 receives a query with > the DO bit set and the CD bit clear. Such a resolver is not > validating responses, likely due to local policy (see [RFC4035], > Section 4.2). For that reason, this case amounts to the same as > the previous case, and no validation happens. > > > (A) doesn't say that CD=1 indicates that the client intends to > validate; it says that it means the querying agent wants the upstream > to pass everything along. If you think that could be stated more > clearly (and on re-reading it, I think it could be), then perhaps you > can contribute such text for a future revision of DNS64. All CD=1 says to a validating resolver is to not validate any answers to queries you make to answer this query, but instead pass them along without validation. It does NOT prevent the upstream returning answers that have already been validated and cached. > (B) says that CD=0 is an indication that a resolver "is not" > validating; that is clearly an overstatement of the case, and should > have been written as "might not be" validating. That said, note that > RFC 4035 section 4.9.2 says this: DO=1 is "the client may be validating". CD=0 say *nothing* about whether the client is validating or not. > A validating security-aware stub resolver SHOULD set the CD bit, > because otherwise the security-aware recursive name server will > answer the query using the name server's local policy, which may > prevent the stub resolver from receiving data that would be > acceptable to the stub resolver's local policy. And as has been pointed out on dnsext that is only half of the argument. There is a equally good argument for setting CD=0 when talking upstream to deal with a different lot of mismanagement. It's a case of pick you poison or try the other way on failure. > > If the answer to the AAAA query is signed and the client made a > > DO=1 query you pass the answer back as is otherwise you can synthesis. > > We apply this to all forms of synthesis we do in named. NXDOMAIN > > redirection / DNS64 / AAAA filtering / RPZ (there is a bug fix for > > RPZ in the next maintenance release). > > The signed AAAA query from the global DNS is simply irrelevant here: > in DNS64 that's supposed to work as you do it. The question is what > happens when you need to synthesize AAAA from the (signed) A record, > and in that case the _only_ reliable way to validate at the end point > in DNS64 is to use CD=1. Anything else is automatically going to fail > validation. If the A record is signed then the AAAA response is also signed so I fail to see how it can be irrelevent. The rest is simply not true. > 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 ajs@anvilwalrusden.com Sun Jan 29 16: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 3116E21F8531 for ; Sun, 29 Jan 2012 16:39:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.667 X-Spam-Level: X-Spam-Status: No, score=-2.667 tagged_above=-999 required=5 tests=[AWL=-0.068, 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 g8km5zO0fGvx for ; Sun, 29 Jan 2012 16:39:53 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 9BC0721F852B for ; Sun, 29 Jan 2012 16:39:53 -0800 (PST) Received: from shinkuro.com (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 46A261ECB41C for ; Mon, 30 Jan 2012 00:39:50 +0000 (UTC) Date: Sun, 29 Jan 2012 19:39:44 -0500 From: Andrew Sullivan To: behave@ietf.org Message-ID: <20120130003943.GA89537@shinkuro.com> References: <916CE6CF87173740BC8A2CE443096962042B6DB0@008-AM1MPN1-053.mgdnok.nokia.com> <916CE6CF87173740BC8A2CE443096962042C1ADE@008-AM1MPN1-053.mgdnok.nokia.com> <158001ccdd17$d8c00170$8a400450$@com> <20120127211558.GG17728@mail.yitter.info> <20120128005714.BF0431C2FE52@drugs.dv.isc.org> <20120129164553.GC19634@mail.yitter.info> <20120129230824.4FE1B1C3B476@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120129230824.4FE1B1C3B476@drugs.dv.isc.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [BEHAVE] DNSSEC and NAT64 Discovery Heuristic [was RE: I-D Action:draft-ietf-behave-nat64-discovery-heuristic-05.txt] X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 00:39:54 -0000 On Mon, Jan 30, 2012 at 10:08:24AM +1100, Mark Andrews wrote: > If the A record is signed then the AAAA response is also signed so I fail > to see how it can be irrelevent. The rest is simply not true. The only case where DNS64 does anything is when there's no AAAA in the first place. If there were AAAA, we wouldn't need DNS64 at all. I started to respond to the rest of your message, but the above suggests a deep confusion in what we're talking about. DNS64 only does anything at all when you have a node that wants a AAAA, and a some other node for which there is only an A record. There can't possibly be a signed AAAA for that, unless the AAAA is being generated and signed on the fly in which case it is indistinguishable from native v6. This is why the funny handling of CD is appropriate in DNS64 but not in DNS generally, and attempting to treat DNS64 as though it's more or less the real DNS is a mistake. A -- Andrew Sullivan ajs@anvilwalrusden.com From marka@isc.org Sun Jan 29 17:33: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 9A94721F8489 for ; Sun, 29 Jan 2012 17:33:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 y2MtBVS35ccT for ; Sun, 29 Jan 2012 17:33:23 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 579CC21F8473 for ; Sun, 29 Jan 2012 17:33:23 -0800 (PST) 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 "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id BAD81C9427; Mon, 30 Jan 2012 01:33:09 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6d48:c4cd:82ef:670]) (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 32540216C6B; Mon, 30 Jan 2012 01:33:09 +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 95BA31C402EE; Mon, 30 Jan 2012 12:33:04 +1100 (EST) To: Andrew Sullivan From: Mark Andrews References: <916CE6CF87173740BC8A2CE443096962042B6DB0@008-AM1MPN1-053.mgdnok.nokia.com> <916CE6CF87173740BC8A2CE443096962042C1ADE@008-AM1MPN1-053.mgdnok.nokia.com> <158001ccdd17$d8c00170$8a400450$@com> <20120127211558.GG17728@mail.yitter.info> <20120128005714.BF0431C2FE52@drugs.dv.isc.org> <20120129164553.GC19634@mail.yitter.info> <20120129230824.4FE1B1C3B476@drugs.dv.isc.org> <20120130003943.GA89537@shinkuro.com> In-reply-to: Your message of "Sun, 29 Jan 2012 19:39:44 CDT." <20120130003943.GA89537@shinkuro.com> Date: Mon, 30 Jan 2012 12:33:04 +1100 Message-Id: <20120130013304.95BA31C402EE@drugs.dv.isc.org> Cc: behave@ietf.org Subject: Re: [BEHAVE] DNSSEC and NAT64 Discovery Heuristic [was RE: I-D Action:draft-ietf-behave-nat64-discovery-heuristic-05.txt] X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 01:33:24 -0000 In message <20120130003943.GA89537@shinkuro.com>, Andrew Sullivan writes: > On Mon, Jan 30, 2012 at 10:08:24AM +1100, Mark Andrews wrote: > > > If the A record is signed then the AAAA response is also signed so I fail > > to see how it can be irrelevent. The rest is simply not true. > > The only case where DNS64 does anything is when there's no AAAA in the > first place. If there were AAAA, we wouldn't need DNS64 at all. > > I started to respond to the rest of your message, but the above > suggests a deep confusion in what we're talking about. DNS64 only > does anything at all when you have a node that wants a AAAA, and a > some other node for which there is only an A record. "Signed AAAA response" != "Signed AAAA RRset". Below is a "signed AAAA response". Note there are no AAAA records. There are however signed a signed A RRSet (also below). Both answers are cryptographically verifiable. Neither answer required CD=1 to be set. Appling DNS64 processing to the first query would be a waste of time as the client can detect the DNS64 substitution. ; <<>> DiG 9.7.3-P3 <<>> aaaa calendar.isc.org +dnssec ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 221 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;calendar.isc.org. IN AAAA ;; AUTHORITY SECTION: isc.org. 3587 IN SOA ns-int.isc.org. hostmaster.isc.org. 2012012900 7200 3600 24796800 3600 isc.org. 3587 IN RRSIG SOA 5 2 7200 20120227233235 20120128233235 21693 isc.org. Rilw+0NYXFg94XVcSNHGEnqTVlDNIvis85+cAJrvW9NvZHOx6s/GyWZM ar5TeKXDc16np8YNd9zBe3H08vq4bpUrRsN8biwybDXd/gZ890wkgtMV nxJUopy1515CJv/4UDVUN4g+N+6g1bntdNoDiLCR8gaoTjrHBU5xsgG9 aBs= calendar.isc.org. 3587 IN RRSIG NSEC 5 3 3600 20120227233235 20120128233235 21693 isc.org. BJBXu89OWOUfWmzTBI4iPELSCJrLz2zbwBBpcDTdeICwMaTkUoiPiLPt XBRandsR9UR5vKep1UayI8RVfmtcskm7e/aA5HNg999lrhIadf2s7qXO bfsP+yRBNSh9pC7CRFYC2nLKHifx9U/7f/q4BjPPFh8aVr5ZH74o/WrR FlU= calendar.isc.org. 3587 IN NSEC calendar2.isc.org. A RRSIG NSEC ;; Query time: 1 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Mon Jan 30 12:11:03 2012 ;; MSG SIZE rcvd: 472 ; <<>> DiG 9.7.3-P3 <<>> calendar.isc.org +dnssec ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59468 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 5, ADDITIONAL: 15 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;calendar.isc.org. IN A ;; ANSWER SECTION: calendar.isc.org. 7200 IN A 149.20.48.29 calendar.isc.org. 7200 IN RRSIG A 5 3 7200 20120227233235 20120128233235 21693 isc.org. mT1/Vb6Nczgcb1WnhHytO6HI3JnxrtN3O+KAmk0htCaVgShgPl/ff0eF TNpireRcO3zzlQl0MSFovc6GeeCr4JfBuKsRXiM1TPZlFyhD0QXH2vS6 MdwppXqh0eCUoXnVq44ihkaj19EvASsVN9JMT9292fFWQna5r+CJYg3W YDw= ;; AUTHORITY SECTION: isc.org. 6213 IN NS ord.sns-pb.isc.org. isc.org. 6213 IN NS sfba.sns-pb.isc.org. isc.org. 6213 IN NS ams.sns-pb.isc.org. isc.org. 6213 IN NS ns.isc.afilias-nst.info. isc.org. 6213 IN RRSIG NS 5 2 7200 20120227233235 20120128233235 21693 isc.org. tmpOdZj5kL58KjLehl2hsmGKT+C9Pm62LNXdhmw6RD8fKhJIl82EV1s5 FbaCod70y1utteFnUIxooMamt8FB+h6wBmPk6oeamNIDUQPJG/++997w O7W3Q4wxNLXljNSx8IjeHLgUJP5Nu7iuMtQjGCaRUVb3MRUuJxD7o3gJ IQU= ;; ADDITIONAL SECTION: ns.isc.afilias-nst.info. 45272 IN A 199.254.63.254 ns.isc.afilias-nst.info. 3237 IN AAAA 2001:500:2c::254 ams.sns-pb.isc.org. 85413 IN A 199.6.1.30 ams.sns-pb.isc.org. 78202 IN AAAA 2001:500:60::30 ord.sns-pb.isc.org. 85413 IN A 199.6.0.30 ord.sns-pb.isc.org. 78202 IN AAAA 2001:500:71::30 sfba.sns-pb.isc.org. 85413 IN A 149.20.64.3 sfba.sns-pb.isc.org. 78202 IN AAAA 2001:4f8:0:2::19 ams.sns-pb.isc.org. 7200 IN RRSIG A 5 4 7200 20120227233235 20120128233235 21693 isc.org. AgPtohr7vlYwYnGhPELyHya7ZEC7WaLnlOiQM4eMAwR2LJkqT9NY9Gg1 jUB6jdSSM8E+UKOdYxi6OWZyMfRdajsvvKBo3bpevz0xsgGoYc9v2bjR M6pEfE9c9WAYfJQ+bARF4cTtcVXzfP7TusdY8uqnav0Zah8Hf3PH9paA 5VI= ams.sns-pb.isc.org. 7200 IN RRSIG AAAA 5 4 7200 20120227233235 20120128233235 21693 isc.org. Rj7/OOo4KxH0ofSpy3rDR/fN9mm9wM5Ez/DLGUf5LI2wc6J+cyRqdfYl LRE6NEa6H4PkXmAVL1/Iq78WdD02OqT0qugn/CV9nSwk0TqnuM0ORvXS N5MU/VKogMU9DMhqb1TLWJ1UMGlfQv3DdhaBtzCd0vJ7reKs+SahgPK6 YKw= ord.sns-pb.isc.org. 7200 IN RRSIG A 5 4 7200 20120227233235 20120128233235 21693 isc.org. j5LUwsHOhMCR0KuToauX5QwMiFLZBU8CgbytTMpEFnNaSPPAXfdLO7m6 ZVSaMV6WQbefxPL+7LGnmJkU5zHL1VEtrrVaX27j1wyaXtQHeBnGKHnS u4C6ww9LfyhvKevpkpX6q1YJuHp7WJHKttthI0MdlSQWMnPNUDoLi6mR nBI= ord.sns-pb.isc.org. 7200 IN RRSIG AAAA 5 4 7200 20120227233235 20120128233235 21693 isc.org. KmU6kBpGMTfjKpYWMtvPvyhGiSIYvKbNrXebYVk41lFGbZtrgzoNpYZR WQRXEthTxua1uH/UXQsTXfEN0/XBe+ZQYZRQNlwAO2meWT5+xUOYC5i8 QesHurfwJdX1nofJ/T/emXUwe9MTxcuCR7Vgj5py9ENgBd+PsxveZFpz PjA= sfba.sns-pb.isc.org. 7200 IN RRSIG A 5 4 7200 20120227233235 20120128233235 21693 isc.org. AyWxyYKgBa5Z8G5/YnBeN/riKaJOfS6AT5RznWaLGxAx54OcM0ZD8ae6 ED+5x6SsnOmC5Dyc+KtxjH/Jqsyzy9EqQCSOkjExuJg/D8ujNON4+KeP lgpgsI0TU2evP1D9Lm+RUApRrQvXLex9BAsgfx7n66yliymHeacXk7vS Yag= sfba.sns-pb.isc.org. 7200 IN RRSIG AAAA 5 4 7200 20120227233235 20120128233235 21693 isc.org. BDaejZw5Fve5+ZF8pik9oQcCyXmTtGpJR+EKaMYo9x/Dt9m5TQlFtluz zXYHsGRKIHuB7rjTk+Ajc6dO9MTjcAWlKE8zCg/+bsyL7vYNySEm19ki 78+pclgRB2bTQiBfIyyKB1/Jpj+D9r+5PEwwy+Jwls+W22G51MOnLDAG QEQ= ;; Query time: 252 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Mon Jan 30 12:11:29 2012 ;; MSG SIZE rcvd: 1672 > There can't > possibly be a signed AAAA for that, unless the AAAA is being generated > and signed on the fly in which case it is indistinguishable from > native v6. This is why the funny handling of CD is appropriate in > DNS64 but not in DNS generally, and attempting to treat DNS64 as > though it's more or less the real DNS is a mistake. And if I add CD=1 to the query the only thing that changes, other than the ttls, is "cd" added to the flags. ; <<>> DiG 9.7.3-P3 <<>> aaaa calendar.isc.org +dnssec +cd ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43138 ;; flags: qr rd ra ad cd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;calendar.isc.org. IN AAAA ;; AUTHORITY SECTION: isc.org. 3073 IN SOA ns-int.isc.org. hostmaster.isc.org. 2012012900 7200 3600 24796800 3600 isc.org. 3073 IN RRSIG SOA 5 2 7200 20120227233235 20120128233235 21693 isc.org. Rilw+0NYXFg94XVcSNHGEnqTVlDNIvis85+cAJrvW9NvZHOx6s/GyWZM ar5TeKXDc16np8YNd9zBe3H08vq4bpUrRsN8biwybDXd/gZ890wkgtMV nxJUopy1515CJv/4UDVUN4g+N+6g1bntdNoDiLCR8gaoTjrHBU5xsgG9 aBs= calendar.isc.org. 3073 IN RRSIG NSEC 5 3 3600 20120227233235 20120128233235 21693 isc.org. BJBXu89OWOUfWmzTBI4iPELSCJrLz2zbwBBpcDTdeICwMaTkUoiPiLPt XBRandsR9UR5vKep1UayI8RVfmtcskm7e/aA5HNg999lrhIadf2s7qXO bfsP+yRBNSh9pC7CRFYC2nLKHifx9U/7f/q4BjPPFh8aVr5ZH74o/WrR FlU= calendar.isc.org. 3073 IN NSEC calendar2.isc.org. A RRSIG NSEC ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Mon Jan 30 12:19:37 2012 ;; MSG SIZE rcvd: 472 DNS64 is using the wrong bit to disable DNS64 processing. DO is the correct bit. Now if I just set CD=1 it would be perfectly fine to apply DNS64 processing to that answer as the client cannot detect the substitution. ; <<>> DiG 9.7.3-P3 <<>> aaaa calendar.isc.org +cd ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25289 ;; flags: qr rd ra cd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;calendar.isc.org. IN AAAA ;; AUTHORITY SECTION: isc.org. 2834 IN SOA ns-int.isc.org. hostmaster.isc.org. 2012012900 7200 3600 24796800 3600 ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Mon Jan 30 12:23:36 2012 ;; MSG SIZE rcvd: 88 -- 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 Jan 29 18:01: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 6856421F851A for ; Sun, 29 Jan 2012 18:01:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[AWL=0.048, 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 lOmqg+LwpOuR for ; Sun, 29 Jan 2012 18:01:59 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id D710121F8516 for ; Sun, 29 Jan 2012 18:01:58 -0800 (PST) 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 "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id 6628F5F984C; Mon, 30 Jan 2012 02:01:46 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6d48:c4cd:82ef:670]) (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 20ADC216C6A; Mon, 30 Jan 2012 02:01: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 0F0D81C403B8; Mon, 30 Jan 2012 13:01:42 +1100 (EST) To: Andrew Sullivan From: Mark Andrews References: <916CE6CF87173740BC8A2CE443096962042B6DB0@008-AM1MPN1-053.mgdnok.nokia.com> <916CE6CF87173740BC8A2CE443096962042C1ADE@008-AM1MPN1-053.mgdnok.nokia.com> <158001ccdd17$d8c00170$8a400450$@com> <20120127211558.GG17728@mail.yitter.info> <20120128005714.BF0431C2FE52@drugs.dv.isc.org> <20120129164553.GC19634@mail.yitter.info> <20120129230824.4FE1B1C3B476@drugs.dv.isc.org> <20120130003943.GA89537@shinkuro.com> In-reply-to: Your message of "Sun, 29 Jan 2012 19:39:44 CDT." <20120130003943.GA89537@shinkuro.com> Date: Mon, 30 Jan 2012 13:01:41 +1100 Message-Id: <20120130020142.0F0D81C403B8@drugs.dv.isc.org> Cc: behave@ietf.org Subject: Re: [BEHAVE] DNSSEC and NAT64 Discovery Heuristic [was RE: I-D Action:draft-ietf-behave-nat64-discovery-heuristic-05.txt] X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 02:01:59 -0000 Attempting to determine intent from DO and CD as section 3 of RFC6147 does is "just not possible". DNSSEC does not have the "I intend to validate" bit and no combination of bits means "I intended to validate". Pretending that there is such a combination does no-one any favours. DO=1 means I want the DNSSEC records. CD=1 means pass through answers and don't validate if you make upstream queries (recurse) to answer this query. Neither indicates intent to validate however validation is only possible if DO=1. -- 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 Jan 30 04:34: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 3D6AB21F8559 for ; Mon, 30 Jan 2012 04:34:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.742 X-Spam-Level: X-Spam-Status: No, score=-2.742 tagged_above=-999 required=5 tests=[AWL=-0.143, 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 bqF5dwm6kLzf for ; Mon, 30 Jan 2012 04:33:59 -0800 (PST) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id 34D1221F854E for ; Mon, 30 Jan 2012 04:33:58 -0800 (PST) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-sa02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q0UCXsgB020594; Mon, 30 Jan 2012 14:33:54 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.25]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 30 Jan 2012 14:33:52 +0200 Received: from 008-AM1MPN1-051.mgdnok.nokia.com ([169.254.1.68]) by 008-AM1MMR1-009.mgdnok.nokia.com ([65.54.30.25]) with mapi id 14.01.0355.003; Mon, 30 Jan 2012 13:33:52 +0100 From: To: , Thread-Topic: DNSSEC and NAT64 Discovery Heuristic [was RE: [BEHAVE] I-D Action: draft-ietf-behave-nat64-discovery-heuristic-05.txt] Thread-Index: AQHM3RfdVEdgOoBqgki3VCG9yLTfQ5Yk1odw Date: Mon, 30 Jan 2012 12:33:51 +0000 Message-ID: <916CE6CF87173740BC8A2CE443096962042CAF87@008-AM1MPN1-051.mgdnok.nokia.com> References: <916CE6CF87173740BC8A2CE443096962042B6DB0@008-AM1MPN1-053.mgdnok.nokia.com> <916CE6CF87173740BC8A2CE443096962042C1ADE@008-AM1MPN1-053.mgdnok.nokia.com> <158001ccdd17$d8c00170$8a400450$@com> In-Reply-To: <158001ccdd17$d8c00170$8a400450$@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+/nZJb9Kg7IlSDqVeMlqSaP6UL9fE0nWFWxULiPDnUyKCt84ppnZTFqkIS1gyLYRy7F9/qTxQtwXWOJWWdrZ1DXMdbGqluU3uiPNxw9wUwcsiKGTxqhJJR7U9Kp70dWWPwoczbzW9xW9JEr+3cP+dKVpz6qeTxwv4QvMvaXrz3Hn/48NMyhNW5eKSWrBIXkcBfjxRkzxDwu72AF7S7nJnX7H8uSPfTtKvdn6JeL9AKLgYtGQuNT/7SOj+b9kRzFnCoRaONCNnm1cQU6mhyJVwa/WAGZpdAMw918yi8RnBoW+GTPECEn5G4cXR6spGIiXx8wo7927MEMoWzLiyAAg7OX0SOokWtWNs= x-originating-ip: [10.162.89.107] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 30 Jan 2012 12:33:52.0946 (UTC) FILETIME=[6CE61120:01CCDF4B] X-Nokia-AV: Clean Cc: behave@ietf.org Subject: Re: [BEHAVE] DNSSEC and NAT64 Discovery Heuristic [was RE: I-D Action: draft-ietf-behave-nat64-discovery-heuristic-05.txt] X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 12:34:00 -0000 > > 5. Have access network's authoritative nameservers to respond to > > DNS > > queries for the NAT64 FQDNs only when the queries have been > > originated from the network domain the NAT64 is serving. If the > > NAT64's AAAA records are made resolvable throughout the > > Internet, > > a possible misuse vector of the NAT64 prefixes and NAT64 FQDNs > > in > > other networks is enabled: an attacker in other access network > > may lure a host on that network to think it is configuring NAT64 > > prefix in secure manner, while in reality it is not as the node > > would be configuring NAT64 prefix in a network where the NAT64 > > prefix should not be used. > > > > I don't like this requirement because it is forcing the DNS server to > > support views. Additionally, you will have to update the authoritative > > DNS every time you start provisioning your clients with new addresses > > from new IPv6 networks. >=20 > Fair point. Teemu, Jouni, thoughts on this? =20 The text was attempting to tackle the following attack: - Legitimate network A is using NAT64 and related domain names are all secu= red with DNSSEC - Host is in hostile network B, where attacker has control over local DNS64= , NAT64 and routing services - Host performs AAAA query for the well-known name, which is replied by att= acker's DNS64 using network A's Pref64::/n - Host performs reverse query to find the FQDN for the prefix, and find's n= etwork A's NAT64's FQDN (attacker not involved in this query) - Host performs forward query for the learned name, validates response with= DNSSEC, and gets the same Pref64::/n as it got originally for the well-kno= wn name (attacker not involved in this query) - Host thinks it has learned Pref64::/n safely Except that the host has not, because even though the discovered Pref64::/n= was matching the NAT64 FQDN and all that just fine, the host is in a netwo= rk B that should not be using the network A's Pref64::/n and hence all host= 's packets could be routed to network B's NAT64 under control of attacker (= instead of NAT64 of network A - remember attacker has taken over routing to= Pref64::/n). Best regards, Teemu From teemu.savolainen@nokia.com Mon Jan 30 04:52: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 2EC8621F8522 for ; Mon, 30 Jan 2012 04:52:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.724 X-Spam-Level: X-Spam-Status: No, score=-2.724 tagged_above=-999 required=5 tests=[AWL=-0.125, 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 rq6M0pUHU67O for ; Mon, 30 Jan 2012 04:52:15 -0800 (PST) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id EE0E221F848B for ; Mon, 30 Jan 2012 04:52:14 -0800 (PST) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-sa01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q0UCq9Dt026118; Mon, 30 Jan 2012 14:52:11 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.21]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 30 Jan 2012 14:51:59 +0200 Received: from 008-AM1MPN1-051.mgdnok.nokia.com ([169.254.1.68]) by 008-AM1MMR1-012.mgdnok.nokia.com ([65.54.30.21]) with mapi id 14.01.0355.003; Mon, 30 Jan 2012 13:51:58 +0100 From: To: Thread-Topic: [BEHAVE] I-D Action: draft-ietf-behave-nat64-discovery-heuristic-05.txt Thread-Index: AczbpruQwz+Z3pnhRXKe8oNhOKSr7gBANuMAABGJ3GAABoR/AACQ64QQ Date: Mon, 30 Jan 2012 12:51:57 +0000 Message-ID: <916CE6CF87173740BC8A2CE443096962042CAFE3@008-AM1MPN1-051.mgdnok.nokia.com> References: <916CE6CF87173740BC8A2CE443096962042B6DB0@008-AM1MPN1-053.mgdnok.nokia.com> <916CE6CF87173740BC8A2CE443096962042C1ADE@008-AM1MPN1-053.mgdnok.nokia.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-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+/nZJb9Kg7IiK+ntKbo4xPTApCTPxRn9XGhbBnmCVqn5Q5Oymo/pQG4Q2g2yALHK/AW/m+afozOvOn+8bMVc7Zy6+hIsveiaLrKfAYg/LFJNlWnUE4EN3n57Q4RlH0BP4Rhl+xCQqcmwrDdSYYDhryESE2ljP2ea67ktvm7IodwFM2P3sU7ezkJIXfmo+4/0EKYPSxpnkfl6yDrOo13tuA6bTs0IOHqvERJQl6zUCSWZmpPZTRS8+VbmmhOXSVSkFWYIkPat7oFRLQa9ZHRYz5ldsv5Q5junY= x-originating-ip: [10.162.89.107] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 30 Jan 2012 12:51:59.0188 (UTC) FILETIME=[F4597140:01CCDF4D] X-Nokia-AV: Clean Cc: behave@ietf.org Subject: Re: [BEHAVE] I-D Action: draft-ietf-behave-nat64-discovery-heuristic-05.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 12:52:16 -0000 Hi Cameron, > Well, in the draft, the only guidance for ipv4only.arpa ttl is that it no= t exceed > 1 year... which does not help in this situation. >=20 > The draft would benefit from explicitly stating discovered pref64 ttl =3D= pref64 > fqdn ttl. That way the ttl is completely in control of the network operat= or. The operator is in control of TTL used in synthetic AAAA records operator's= DNS64 creates, or am I mistaken? And that TTL does not have to equal to re= lated A record TTL. I.e. even if ipv4only.arpa would have 1 year TTL, the D= NS64 that synthesizes IPv6 addresses can use much lower TTL, hence cause no= des to have much shorter TTL for the discovered prefix.=20 If the host performs PTR query and forward AAAA query as currently describe= d in DNSSEC section, then I guess the TTL used by node could be the NAT64 F= QDN TTL? > It does not need to be this way, right? What you really want is a pairing= of > dns records, right? If that is what is needed, then lets say that. I woul= d much > rather pair the pref64 fqdn with a dummy fqdn for this purpose. It is no= t > acceptable to network operators to have a name for an interface we do not > want traffic to be destine to. >=20 > Not nice. Cgn boxes are lots of asics / fpga / blah and relatively weak c= ontrol > plane processors that explicitly rate limit icmp to avoid control plane > resource attacks. You cannot prescribe how this can be treated, the exist= ing > text is not acceptable. It may be acceptable if you think NAT64 is a Lin= ux box, > but in may large deployments, it is a very different case. > > Net net, this draft, IMHO, needs to define a procedure based on fqdn and > optional connectivity checks. What we are looking here is to enable connectivity checks without mandating= developers to host connectivity check servers and to keep connectivity che= cks as local as possible.=20 > It is not acceptable to expect any interface on the nat64 node to have an > fqdn or to send icmp connectivity checks to the nat64 node. The > pref64 may have an fqdn, that does make sense to me. The IPv4 address found via described procedure does not really have to poin= t to NAT64, it can point to any IPv4 address chosen by the owner of NAT64's= FQDN, or be non-existent... I.e. you could disable connectivity checks by = not having A record (which is the case anyway currently as there's no stand= ard way for host to learn NAT64's FQDN, which does not necessarily even exi= st), or you could point the checks to separate server. So.. would it help if we would move all of the A record stuff from DNSSEC s= ection to the optional connectivity check section, and describe there that = network operator may help nodes on connectivity checks by having A record f= or the NAT64 FQDN that points to somewhere (be that NAT64 itself, or some d= edicated server)?=20 Best regards, Teemu From ajs@anvilwalrusden.com Mon Jan 30 05:32: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 EDD8221F86AA for ; Mon, 30 Jan 2012 05:32:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.666 X-Spam-Level: X-Spam-Status: No, score=-2.666 tagged_above=-999 required=5 tests=[AWL=-0.067, 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 jfdubnxPpcXZ for ; Mon, 30 Jan 2012 05:32:09 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 1DCDC21F84EB for ; Mon, 30 Jan 2012 05:32:09 -0800 (PST) Received: from shinkuro.com (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 D6CDE1ECB41C for ; Mon, 30 Jan 2012 13:32:07 +0000 (UTC) Date: Mon, 30 Jan 2012 08:32:05 -0500 From: Andrew Sullivan To: behave@ietf.org Message-ID: <20120130133205.GB91476@shinkuro.com> References: <916CE6CF87173740BC8A2CE443096962042C1ADE@008-AM1MPN1-053.mgdnok.nokia.com> <158001ccdd17$d8c00170$8a400450$@com> <20120127211558.GG17728@mail.yitter.info> <20120128005714.BF0431C2FE52@drugs.dv.isc.org> <20120129164553.GC19634@mail.yitter.info> <20120129230824.4FE1B1C3B476@drugs.dv.isc.org> <20120130003943.GA89537@shinkuro.com> <20120130020142.0F0D81C403B8@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120130020142.0F0D81C403B8@drugs.dv.isc.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [BEHAVE] DNSSEC and NAT64 Discovery Heuristic [was RE: I-D Action:draft-ietf-behave-nat64-discovery-heuristic-05.txt] X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 13:32:10 -0000 Mark, On Mon, Jan 30, 2012 at 01:01:41PM +1100, Mark Andrews wrote: > > Attempting to determine intent from DO and CD as section 3 of RFC6147 > does is "just not possible". DNSSEC does not have the "I intend > to validate" bit and no combination of bits means "I intended to > validate". Pretending that there is such a combination does no-one > any favours. I do not believe that RFC6147 is intending to determine intent at all. First, section 3 isn't normative; it's some background that is intended to motivate the decision to use CD as an extra signal. But anyway, as I already suggested in the previous message, section 3 number 3 is likely overstating its case. All of that said, you seem to be ignoring the use case for DNS64. Remember that DNS64 _is not_ DNS. It is a substitute protocol that systematically alters DNS packets and looks like ordinary DNS under some circumstances; but it's not the DNS. The whole point of DNS64 is that you can put it into an already-deployed network where network endpoints have IPv6 connectivity, and allow those endpoints to reach the IPv4 networks using the DNS64/NAT64 trick. Given that that is what we were trying to do, we clearly couldn't use DO=1 to signal that the end point needed the original, unmolested DNS packages, because a large number of resolvers that were shipped in the past set DO=1 regardless of whether they were planning to validate the records. This is fine: DO=1 just means "DNSSEC OK". But it is the very lack of a mechanism to signal, "I will validate this answer," that causes us a problem. The only reliable way to validate an answer yourself is to set CD=1. You have to hope that upstreams, if there are any, also set CD=1 when they send their queries along; but that instruction (which is contained in a dnsext document, as you know) isn't in scope for this WG nor for RFC6147. Now, given that DNS64 is intended to be used in environments where there are deployed systems, we had to make a decision about what to do for end points that wanted to do their own validation. And the answer there is twofold. First, since the only way to be sure you get all the necessary validation data is to set CD=1, RFC6147 insists that people behind a DNS64 who want to validate must set CD=1. Second, since we had to be able to deploy this in environments where there already were existing, DNS64-oblivious resolvers that always set DO=1, we could not use DO=1 as a signal to send an unmolested real DNS answer to such a query originator. At the time RFC6147 was written, validation at end points practically never happened; and even if it did, it was by people who were more technically clueful and therefore more likely to be able to upgrade their systems to support DNS64 as well. (It seems to me that both of these observations are still true today, FWIW.) This was the trade-off we made. We did not use the EDNS0 option approach because we decided to specify the mechanism for signalling the need for DNS64 awareness separately from DNS64 itself -- a decision I now regret, given the way we seem doomed to do it. But I'm not sure we would have made any progress if we'd argued about such signalling at the time. So yes, you are quite correct that there is no way to say, "I'm going to validate this." We agree about it. What we do not agree about, apparently, is what DNS64 should do in order to get around that. Given the purposes for which DNS64 was intended, it seems to me that the trade-off we made was the right one, even though I find it unsatisfying. You apparently would like a different one, but as nearly as I can tell your position would make DNS64 send many more queries in practice. > DO=1 means I want the DNSSEC records. I'm not sure I agree with you about that interpretation. When serving, DO=1 means, "Send the DNSSEC records." But when querying, DO=1 might not mean, "I want those records." It might mean "I am security-aware." For section 3.2.1 of RFC4035 says this: The resolver side of a security-aware recursive name server MUST set the DO bit when sending requests, regardless of the state of the DO bit in the initiating request received by the name server side. I suspect, in fact, that the above passage is exactly why we have so many ordinary DNS resolvers that set DO even though they're not validating: they're in non-validating, security-aware mode, and the above text suggests that they have to set DO. That fact is how we got to the behaviour in DNS64 in the first place. I'd like not to crowd this list with a lot of arguing about how DNS itself ought to handle these cases. I'm trying to respond to what you're suggesting for the narrow case of DNS64. What ordinary DNS resolvers ought to do is actually the subject of an ongoing last call in another working group. If you have something to say about that, I'd suggest you post your views in response to that WGLC (except that I note you already have done). Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From marka@isc.org Mon Jan 30 06:54: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 871F921F86A5 for ; Mon, 30 Jan 2012 06:54:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.045, 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 5-1jLnqhDIC4 for ; Mon, 30 Jan 2012 06:54:27 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 4539821F8633 for ; Mon, 30 Jan 2012 06:54:27 -0800 (PST) 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 "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id 9551A5F9899; Mon, 30 Jan 2012 14:54:10 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:24c0:fc2e:e7ac:ff35]) (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 450CF216C6B; Mon, 30 Jan 2012 14:54:08 +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 3A9CD1C5F1B0; Tue, 31 Jan 2012 01:54:02 +1100 (EST) To: Andrew Sullivan From: Mark Andrews References: <916CE6CF87173740BC8A2CE443096962042C1ADE@008-AM1MPN1-053.mgdnok.nokia.com> <158001ccdd17$d8c00170$8a400450$@com> <20120127211558.GG17728@mail.yitter.info> <20120128005714.BF0431C2FE52@drugs.dv.isc.org> <20120129164553.GC19634@mail.yitter.info> <20120129230824.4FE1B1C3B476@drugs.dv.isc.org> <20120130003943.GA89537@shinkuro.com> <20120130020142.0F0D81C403B8@drugs.dv.isc.org> <20120130133205.GB91476@shinkuro.com> In-reply-to: Your message of "Mon, 30 Jan 2012 08:32:05 CDT." <20120130133205.GB91476@shinkuro.com> Date: Tue, 31 Jan 2012 01:54:01 +1100 Message-Id: <20120130145402.3A9CD1C5F1B0@drugs.dv.isc.org> Cc: behave@ietf.org Subject: Re: [BEHAVE] DNSSEC and NAT64 Discovery Heuristic [was RE: I-D Action:draft-ietf-behave-nat64-discovery-heuristic-05.txt] X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 14:54:28 -0000 In message <20120130133205.GB91476@shinkuro.com>, Andrew Sullivan writes: > Mark, > > On Mon, Jan 30, 2012 at 01:01:41PM +1100, Mark Andrews wrote: > > > > Attempting to determine intent from DO and CD as section 3 of RFC6147 > > does is "just not possible". DNSSEC does not have the "I intend > > to validate" bit and no combination of bits means "I intended to > > validate". Pretending that there is such a combination does no-one > > any favours. > > I do not believe that RFC6147 is intending to determine intent at all. > First, section 3 isn't normative; it's some background that is > intended to motivate the decision to use CD as an extra signal. But > anyway, as I already suggested in the previous message, section 3 > number 3 is likely overstating its case. > > All of that said, you seem to be ignoring the use case for DNS64. > Remember that DNS64 _is not_ DNS. It is a substitute protocol that > systematically alters DNS packets and looks like ordinary DNS under > some circumstances; but it's not the DNS. The whole point of DNS64 is > that you can put it into an already-deployed network where network > endpoints have IPv6 connectivity, and allow those endpoints to reach > the IPv4 networks using the DNS64/NAT64 trick. > > Given that that is what we were trying to do, we clearly couldn't use > DO=1 to signal that the end point needed the original, unmolested DNS > packages, because a large number of resolvers that were shipped in the > past set DO=1 regardless of whether they were planning to validate the > records. This is fine: DO=1 just means "DNSSEC OK". But it is the > very lack of a mechanism to signal, "I will validate this answer," > that causes us a problem. And CD=1 will not help with this senario. The non-validating resolver will cache the DNS64 translated responses and will return those translated responses to DO=1,CD=1 queries which will then fail to validate. Or if the DO=1,CD=1 query is the first query then the non validating stub resolvers will get NODATA responses to AAAA queries instead of synthesised responses. The same will happen with a validating resolver and any signed answer that validates as insecure. Put a DNS64 recursive server (as described in RFC6147) in front of a non validating DO=1 recursive server in front of a validating recursive server. Then ask the non validating recursive server some questions which trigger DNS64 processing from a signed zone. Then ask the validating recursive server the same questions. > The only reliable way to validate an answer yourself is to set CD=1. > You have to hope that upstreams, if there are any, also set CD=1 when > they send their queries along; but that instruction (which is > contained in a dnsext document, as you know) isn't in scope for this > WG nor for RFC6147. But CD=1 does *not* say "make a new upstream query even if you have cached data". The validating stub resolver will not get good data. It will get DNS64 tainted data from the cache. > Now, given that DNS64 is intended to be used in environments where > there are deployed systems, we had to make a decision about what to do > for end points that wanted to do their own validation. And the answer > there is twofold. First, since the only way to be sure you get all > the necessary validation data is to set CD=1, Not true. > RFC6147 insists that > people behind a DNS64 who want to validate must set CD=1. Which won't help. > Second, > since we had to be able to deploy this in environments where there > already were existing, DNS64-oblivious resolvers that always set DO=1, > we could not use DO=1 as a signal to send an unmolested real DNS > answer to such a query originator. At the time RFC6147 was written, > validation at end points practically never happened; and even if it > did, it was by people who were more technically clueful and therefore > more likely to be able to upgrade their systems to support DNS64 as > well. (It seems to me that both of these observations are still true > today, FWIW.) > > This was the trade-off we made. We did not use the EDNS0 option > approach because we decided to specify the mechanism for signalling > the need for DNS64 awareness separately from DNS64 itself -- a > decision I now regret, given the way we seem doomed to do it. But I'm > not sure we would have made any progress if we'd argued about such > signalling at the time. > > So yes, you are quite correct that there is no way to say, "I'm going > to validate this." We agree about it. What we do not agree about, > apparently, is what DNS64 should do in order to get around that. > Given the purposes for which DNS64 was intended, it seems to me that > the trade-off we made was the right one, even though I find it > unsatisfying. You apparently would like a different one, but as > nearly as I can tell your position would make DNS64 send many more > queries in practice. > > > DO=1 means I want the DNSSEC records. > > I'm not sure I agree with you about that interpretation. When > serving, DO=1 means, "Send the DNSSEC records." But when querying, > DO=1 might not mean, "I want those records." It might mean "I am > security-aware." For section 3.2.1 of RFC4035 says this: > > The resolver side of a security-aware recursive name server MUST set > the DO bit when sending requests, regardless of the state of the DO > bit in the initiating request received by the name server side. > > I suspect, in fact, that the above passage is exactly why we have so > many ordinary DNS resolvers that set DO even though they're not > validating: they're in non-validating, security-aware mode, and the > above text suggests that they have to set DO. That fact is how we got > to the behaviour in DNS64 in the first place. > > I'd like not to crowd this list with a lot of arguing about how DNS > itself ought to handle these cases. I'm trying to respond to what > you're suggesting for the narrow case of DNS64. What ordinary DNS > resolvers ought to do is actually the subject of an ongoing last call > in another working group. If you have something to say about that, > I'd suggest you post your views in response to that WGLC (except that > I note you already have done). > > 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 ajs@anvilwalrusden.com Mon Jan 30 07:11:42 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 D0D9421F869E for ; Mon, 30 Jan 2012 07:11:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.664 X-Spam-Level: X-Spam-Status: No, score=-2.664 tagged_above=-999 required=5 tests=[AWL=-0.065, 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 IrSTwx93MUss for ; Mon, 30 Jan 2012 07:11:42 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id C64E521F8559 for ; Mon, 30 Jan 2012 07:11:41 -0800 (PST) Received: from shinkuro.com (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 BFA971ECB41C for ; Mon, 30 Jan 2012 15:11:12 +0000 (UTC) Date: Mon, 30 Jan 2012 10:10:54 -0500 From: Andrew Sullivan To: behave@ietf.org Message-ID: <20120130151048.GC91476@shinkuro.com> References: <158001ccdd17$d8c00170$8a400450$@com> <20120127211558.GG17728@mail.yitter.info> <20120128005714.BF0431C2FE52@drugs.dv.isc.org> <20120129164553.GC19634@mail.yitter.info> <20120129230824.4FE1B1C3B476@drugs.dv.isc.org> <20120130003943.GA89537@shinkuro.com> <20120130020142.0F0D81C403B8@drugs.dv.isc.org> <20120130133205.GB91476@shinkuro.com> <20120130145402.3A9CD1C5F1B0@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120130145402.3A9CD1C5F1B0@drugs.dv.isc.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [BEHAVE] DNSSEC and NAT64 Discovery Heuristic [was RE: I-D Action:draft-ietf-behave-nat64-discovery-heuristic-05.txt] X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 15:11:43 -0000 On Tue, Jan 31, 2012 at 01:54:01AM +1100, Mark Andrews wrote: > And CD=1 will not help with this senario. The non-validating > resolver will cache the DNS64 translated responses and will return > those translated responses to DO=1,CD=1 queries which will then > fail to validate. Or if the DO=1,CD=1 query is the first query > then the non validating stub resolvers will get NODATA responses > to AAAA queries instead of synthesised responses. Ah, wait. You are worried about the case where a caching security-aware non-validating dns64-oblivious recursive resolver is behind a DNS64, and providing service for other clients inside that network? Yeah, that won't work. There's a rather clumsy and too-short discussion of some (but not all) of these issues in RFC6147, section 6. > Put a DNS64 recursive server (as described in RFC6147) in front of > a non validating DO=1 recursive server in front of a validating > recursive server. No, don't. It won't work reliably, I agree. Basically, if the DNS64 isn't the last hop before the validation point, then you're screwed. At the same time, I'm a little alarmed at the prospect of caches that hand out queries discovered with CD=0 to clients querying with CD=1, regardless of whether they are a DNS64 or a DNS server. That should likely be taken up on another list, however. > > there is twofold. First, since the only way to be sure you get all > > the necessary validation data is to set CD=1, > > Not true. I think we are just talking with different implicit scope here, but that's a general DNS issue and not, I think, a subject for this list. I believe what I said, however, and I think a careful reading of RFC 4035 backs me up. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From cb.list6@gmail.com Mon Jan 30 08:14: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 E64EE21F8669 for ; Mon, 30 Jan 2012 08:14:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.476 X-Spam-Level: X-Spam-Status: No, score=-3.476 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oqptjmfsghsk for ; Mon, 30 Jan 2012 08:14:31 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id DA3EC21F86A0 for ; Mon, 30 Jan 2012 08:14:30 -0800 (PST) Received: by pbdu7 with SMTP id u7so4070825pbd.31 for ; Mon, 30 Jan 2012 08:14:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8yIP+qatxz/0f6OJNsMMapgNYb4imjUfGmTNLVVka0w=; b=clbqU+phySgTOIPCOXDeSJWQKVZxZSmMjZPjl+CS/eMQ3AldTnp+EDkNKcDtb2NE1c 2RYJ61clBSR/2cup3Z1oEk6OQyoubxFkOexVImwU/TFxwuXAjcKKuQlKmQpOyWwd91Js ZGjE2MhOyyRfVW1ObmNdWMkYBEEpmobTh04Yk= MIME-Version: 1.0 Received: by 10.68.225.73 with SMTP id ri9mr4704118pbc.70.1327940064422; Mon, 30 Jan 2012 08:14:24 -0800 (PST) Received: by 10.143.78.7 with HTTP; Mon, 30 Jan 2012 08:14:23 -0800 (PST) Received: by 10.143.78.7 with HTTP; Mon, 30 Jan 2012 08:14:23 -0800 (PST) In-Reply-To: <916CE6CF87173740BC8A2CE443096962042CAFE3@008-AM1MPN1-051.mgdnok.nokia.com> References: <916CE6CF87173740BC8A2CE443096962042B6DB0@008-AM1MPN1-053.mgdnok.nokia.com> <916CE6CF87173740BC8A2CE443096962042C1ADE@008-AM1MPN1-053.mgdnok.nokia.com> <916CE6CF87173740BC8A2CE443096962042CAFE3@008-AM1MPN1-051.mgdnok.nokia.com> Date: Mon, 30 Jan 2012 08:14:23 -0800 Message-ID: From: Cameron Byrne To: teemu.savolainen@nokia.com Content-Type: multipart/alternative; boundary=e89a8ff2437dd2ab2504b7c123b2 Cc: behave@ietf.org Subject: Re: [BEHAVE] I-D Action: draft-ietf-behave-nat64-discovery-heuristic-05.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 16:14:32 -0000 --e89a8ff2437dd2ab2504b7c123b2 Content-Type: text/plain; charset=ISO-8859-1 On Jan 30, 2012 4:52 AM, wrote: > > Hi Cameron, > > > Well, in the draft, the only guidance for ipv4only.arpa ttl is that it not exceed > > 1 year... which does not help in this situation. > > > > The draft would benefit from explicitly stating discovered pref64 ttl = pref64 > > fqdn ttl. That way the ttl is completely in control of the network operator. > > The operator is in control of TTL used in synthetic AAAA records operator's DNS64 creates, or am I mistaken? And that TTL does not have to equal to related A record TTL. I.e. even if ipv4only.arpa would have 1 year TTL, the DNS64 that synthesizes IPv6 addresses can use much lower TTL, hence cause nodes to have much shorter TTL for the discovered prefix. > I believe you are mistaken. Rfc 6147 says the original ttl is passed on, from the best of my reading. > If the host performs PTR query and forward AAAA query as currently described in DNSSEC section, then I guess the TTL used by node could be the NAT64 FQDN TTL? > > > It does not need to be this way, right? What you really want is a pairing of > > dns records, right? If that is what is needed, then lets say that. I would much > > rather pair the pref64 fqdn with a dummy fqdn for this purpose. It is not > > acceptable to network operators to have a name for an interface we do not > > want traffic to be destine to. > > > > Not nice. Cgn boxes are lots of asics / fpga / blah and relatively weak control > > plane processors that explicitly rate limit icmp to avoid control plane > > resource attacks. You cannot prescribe how this can be treated, the existing > > text is not acceptable. It may be acceptable if you think NAT64 is a Linux box, > > but in may large deployments, it is a very different case. > > > > Net net, this draft, IMHO, needs to define a procedure based on fqdn and > > optional connectivity checks. > > What we are looking here is to enable connectivity checks without mandating developers to host connectivity check servers and to keep connectivity checks as local as possible. > Pushing the burden to the operator is not acceptable without consent. I suppose having that fqdn implies consent > > It is not acceptable to expect any interface on the nat64 node to have an > > fqdn or to send icmp connectivity checks to the nat64 node. The > > pref64 may have an fqdn, that does make sense to me. > > The IPv4 address found via described procedure does not really have to point to NAT64, it can point to any IPv4 address chosen by the owner of NAT64's FQDN, or be non-existent... I.e. you could disable connectivity checks by not having A record (which is the case anyway currently as there's no standard way for host to learn NAT64's FQDN, which does not necessarily even exist), or you could point the checks to separate server. > > So.. would it help if we would move all of the A record stuff from DNSSEC section to the optional connectivity check section, and describe there that network operator may help nodes on connectivity checks by having A record for the NAT64 FQDN that points to somewhere (be that NAT64 itself, or some dedicated server)? > Yes. That would help. But, pinging the cgn is really a recipe for disaster that I would rather not see documented or suggested without caution. > Best regards, > > Teemu --e89a8ff2437dd2ab2504b7c123b2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Jan 30, 2012 4:52 AM, <= teemu.savolainen@nokia.com> wrote:
>
> Hi Cameron,
>
> > Well, in the draft, the only guidance for ipv4only.arpa ttl is th= at it not exceed
> > 1 year... which does not help in this situation.
> >
> > The draft would benefit from explicitly stating discovered pref64= ttl =3D pref64
> > fqdn ttl. That way the ttl is completely in control of the networ= k operator.
>
> The operator is in control of TTL used in synthetic AAAA records opera= tor's DNS64 creates, or am I mistaken? And that TTL does not have to eq= ual to related A record TTL. I.e. even if ipv4only.arpa would have 1 year T= TL, the DNS64 that synthesizes IPv6 addresses can use much lower TTL, hence= cause nodes to have much shorter TTL for the discovered prefix.
>

I believe you are mistaken. Rfc 6147 says the original ttl is passed on,= from the best of my reading.

> If the host performs PTR query and forward AAAA query as currently = described in DNSSEC section, then I guess the TTL used by node could be the= NAT64 FQDN TTL?
>
> > It does not need to be this way, right? What you really want is a= pairing of
> > dns records, right? If that is what is needed, then lets say that= . I would much
> > rather pair the pref64 fqdn with a dummy fqdn for this purpose. = =A0It is not
> > acceptable to network operators to have a name for an interface w= e do not
> > want traffic to be destine to.
> >
> > Not nice. Cgn boxes are lots of asics / fpga / blah and relativel= y weak control
> > plane processors that explicitly rate limit icmp to avoid control= plane
> > resource attacks. You cannot prescribe how this can be treated, t= he existing
> > text is not acceptable. =A0It may be acceptable if you think NAT6= 4 is a Linux box,
> > but in may large deployments, it is a very different case.
> >
> > Net net, this draft, IMHO, needs to define a procedure based on f= qdn and
> > optional connectivity checks.
>
> What we are looking here is to enable connectivity checks without mand= ating developers to host connectivity check servers and to keep connectivit= y checks as local as possible.
>

Pushing the burden to the operator is not acceptable without consent. I = suppose having that fqdn implies consent

> > It is not acceptable to expect any interface on the nat64 node= to have an
> > fqdn or to send icmp connectivity checks to the nat64 node. =A0Th= e
> > pref64 may have an fqdn, that does make sense to me.
>
> The IPv4 address found via described procedure does not really have to= point to NAT64, it can point to any IPv4 address chosen by the owner of NA= T64's FQDN, or be non-existent... I.e. you could disable connectivity c= hecks by not having A record (which is the case anyway currently as there&#= 39;s no standard way for host to learn NAT64's FQDN, which does not nec= essarily even exist), or you could point the checks to separate server.
>
> So.. would it help if we would move all of the A record stuff from DNS= SEC section to the optional connectivity check section, and describe there = that network operator may help nodes on connectivity checks by having A rec= ord for the NAT64 FQDN that points to somewhere (be that NAT64 itself, or s= ome dedicated server)?
>

Yes. That would help. But, pinging the cgn is really a recipe for disast= er that I would rather not see documented or suggested without caution.

> Best regards,
>
> Teemu

--e89a8ff2437dd2ab2504b7c123b2-- From teemu.savolainen@nokia.com Mon Jan 30 09:16: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 0519E21F85FB for ; Mon, 30 Jan 2012 09:16:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.21 X-Spam-Level: X-Spam-Status: No, score=-3.21 tagged_above=-999 required=5 tests=[AWL=0.388, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ry4mqGeFvOcf for ; Mon, 30 Jan 2012 09:16:05 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id D758D21F85F9 for ; Mon, 30 Jan 2012 09:16:04 -0800 (PST) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q0UHFSwt002037; Mon, 30 Jan 2012 19:16:01 +0200 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); Mon, 30 Jan 2012 19:15:52 +0200 Received: from 008-AM1MPN1-051.mgdnok.nokia.com ([169.254.1.68]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi id 14.01.0355.003; Mon, 30 Jan 2012 18:15:52 +0100 From: To: Thread-Topic: [BEHAVE] I-D Action: draft-ietf-behave-nat64-discovery-heuristic-05.txt Thread-Index: AczfctFX+LZXieIRQJ+cfQ7HEnKt2Q== Date: Mon, 30 Jan 2012 17:15:51 +0000 Message-ID: <1327943740.25487.18.camel@Nokia-N900> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_13279437402548718camelNokiaN900_" MIME-Version: 1.0 X-OriginalArrivalTime: 30 Jan 2012 17:15:52.0946 (UTC) FILETIME=[D2012D20:01CCDF72] X-Nokia-AV: Clean Cc: behave@ietf.org Subject: Re: [BEHAVE] I-D Action: draft-ietf-behave-nat64-discovery-heuristic-05.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: teemu.savolainen@nokia.com List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 17:16:06 -0000 --_000_13279437402548718camelNokiaN900_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T2ssIHdpbGwgY2hlY2sgdGhlIFRUTCwgYnV0IEkgdGhvdWdoIHRoZSBvYnZpb3VzIHdvdWxkIGhh dmUgYmVlbiB0byB1c2UgdGhlIHNob3J0ZXIgb2YgdGhlIHR3bzogQSByZWNvcmQgVFRMIG9yIHJl bWFpbmluZyBQcmVmNjQ6Oi9uIGxpZmV0aW1lIChtYXliZSBJJ20gbWFraW5nIGRhbmdlcm91cyBh c3N1bXB0aW9uIGFnYWluIHdoZW4gYXNzdW1pbmcgUHJlZjY0OjovbiBIQVMgYSBsaWZldGltZTop DQoNCkZvciBjb25uZWN0aXZpdHkgY2hlY2sgSSB3b3VsZCBsaWtlIHRvIGhlYXIgb3RoZXIgb3Bp bmlvbnMgYXMgd2VsbC4gSSBndWVzcyB3ZSBoYXZlIG9uIHRoZSB0YWJsZToNCi0gbm8gY2hlY2sg ZG9jdW1lbnRlZA0KLSBvcHRpb25hbCBmb3IgdmVuZG9yIHNwZWNpZmljIHNlcnZlcg0KLSBvcHRp b25hbCBmb3Igb3BlcmF0b3IgaG9zdGVkIHNlcnZlciAobGVhcm50IHZpYSBBIHJlY29yZCBvZiBO QVQ2NCBGUUROKQ0KDQpUZWVtdQ0KDQotLS0tLSBPcmlnaW5hbCBtZXNzYWdlIC0tLS0tDQo+DQo+ IE9uIEphbiAzMCwgMjAxMiA0OjUyIEFNLCA8dGVlbXUuc2F2b2xhaW5lbkBub2tpYS5jb208bWFp bHRvOnRlZW11LnNhdm9sYWluZW5Abm9raWEuY29tPj4gd3JvdGU6DQo+ID4NCj4gPiBIaSBDYW1l cm9uLA0KPiA+DQo+ID4gPiBXZWxsLCBpbiB0aGUgZHJhZnQsIHRoZSBvbmx5IGd1aWRhbmNlIGZv ciBpcHY0b25seS5hcnBhIHR0bCBpcyB0aGF0DQo+IGl0IG5vdCBleGNlZWQNCj4gPiA+IDEgeWVh ci4uLiB3aGljaCBkb2VzIG5vdCBoZWxwIGluIHRoaXMgc2l0dWF0aW9uLg0KPiA+ID4NCj4gPiA+ IFRoZSBkcmFmdCB3b3VsZCBiZW5lZml0IGZyb20gZXhwbGljaXRseSBzdGF0aW5nIGRpc2NvdmVy ZWQgcHJlZjY0DQo+IHR0bCA9IHByZWY2NA0KPiA+ID4gZnFkbiB0dGwuIFRoYXQgd2F5IHRoZSB0 dGwgaXMgY29tcGxldGVseSBpbiBjb250cm9sIG9mIHRoZSBuZXR3b3JrDQo+IG9wZXJhdG9yLg0K PiA+DQo+ID4gVGhlIG9wZXJhdG9yIGlzIGluIGNvbnRyb2wgb2YgVFRMIHVzZWQgaW4gc3ludGhl dGljIEFBQUEgcmVjb3Jkcw0KPiBvcGVyYXRvcidzIEROUzY0IGNyZWF0ZXMsIG9yIGFtIEkgbWlz dGFrZW4/IEFuZCB0aGF0IFRUTCBkb2VzIG5vdCBoYXZlDQo+IHRvIGVxdWFsIHRvIHJlbGF0ZWQg QSByZWNvcmQgVFRMLiBJLmUuIGV2ZW4gaWYgaXB2NG9ubHkuYXJwYSB3b3VsZCBoYXZlDQo+IDEg eWVhciBUVEwsIHRoZSBETlM2NCB0aGF0IHN5bnRoZXNpemVzIElQdjYgYWRkcmVzc2VzIGNhbiB1 c2UgbXVjaCBsb3dlcg0KPiBUVEwsIGhlbmNlIGNhdXNlIG5vZGVzIHRvIGhhdmUgbXVjaCBzaG9y dGVyIFRUTCBmb3IgdGhlIGRpc2NvdmVyZWQNCj4gcHJlZml4Lg0KPiA+DQo+DQo+IEkgYmVsaWV2 ZSB5b3UgYXJlIG1pc3Rha2VuLiBSZmMgNjE0NyBzYXlzIHRoZSBvcmlnaW5hbCB0dGwgaXMgcGFz c2VkIG9uLA0KPiBmcm9tIHRoZSBiZXN0IG9mIG15IHJlYWRpbmcuDQo+DQo+ID4gSWYgdGhlIGhv c3QgcGVyZm9ybXMgUFRSIHF1ZXJ5IGFuZCBmb3J3YXJkIEFBQUEgcXVlcnkgYXMgY3VycmVudGx5 DQo+IGRlc2NyaWJlZCBpbiBETlNTRUMgc2VjdGlvbiwgdGhlbiBJIGd1ZXNzIHRoZSBUVEwgdXNl ZCBieSBub2RlIGNvdWxkIGJlDQo+IHRoZSBOQVQ2NCBGUUROIFRUTD8NCj4gPg0KPiA+ID4gSXQg ZG9lcyBub3QgbmVlZCB0byBiZSB0aGlzIHdheSwgcmlnaHQ/IFdoYXQgeW91IHJlYWxseSB3YW50 IGlzIGENCj4gcGFpcmluZyBvZg0KPiA+ID4gZG5zIHJlY29yZHMsIHJpZ2h0PyBJZiB0aGF0IGlz IHdoYXQgaXMgbmVlZGVkLCB0aGVuIGxldHMgc2F5IHRoYXQuIEkNCj4gd291bGQgbXVjaA0KPiA+ ID4gcmF0aGVyIHBhaXIgdGhlIHByZWY2NCBmcWRuIHdpdGggYSBkdW1teSBmcWRuIGZvciB0aGlz IHB1cnBvc2UuICBJdA0KPiBpcyBub3QNCj4gPiA+IGFjY2VwdGFibGUgdG8gbmV0d29yayBvcGVy YXRvcnMgdG8gaGF2ZSBhIG5hbWUgZm9yIGFuIGludGVyZmFjZSB3ZQ0KPiBkbyBub3QNCj4gPiA+ IHdhbnQgdHJhZmZpYyB0byBiZSBkZXN0aW5lIHRvLg0KPiA+ID4NCj4gPiA+IE5vdCBuaWNlLiBD Z24gYm94ZXMgYXJlIGxvdHMgb2YgYXNpY3MgLyBmcGdhIC8gYmxhaCBhbmQgcmVsYXRpdmVseQ0K PiB3ZWFrIGNvbnRyb2wNCj4gPiA+IHBsYW5lIHByb2Nlc3NvcnMgdGhhdCBleHBsaWNpdGx5IHJh dGUgbGltaXQgaWNtcCB0byBhdm9pZCBjb250cm9sDQo+IHBsYW5lDQo+ID4gPiByZXNvdXJjZSBh dHRhY2tzLiBZb3UgY2Fubm90IHByZXNjcmliZSBob3cgdGhpcyBjYW4gYmUgdHJlYXRlZCwgdGhl DQo+IGV4aXN0aW5nDQo+ID4gPiB0ZXh0IGlzIG5vdCBhY2NlcHRhYmxlLiAgSXQgbWF5IGJlIGFj Y2VwdGFibGUgaWYgeW91IHRoaW5rIE5BVDY0IGlzDQo+IGEgTGludXggYm94LA0KPiA+ID4gYnV0 IGluIG1heSBsYXJnZSBkZXBsb3ltZW50cywgaXQgaXMgYSB2ZXJ5IGRpZmZlcmVudCBjYXNlLg0K PiA+ID4NCj4gPiA+IE5ldCBuZXQsIHRoaXMgZHJhZnQsIElNSE8sIG5lZWRzIHRvIGRlZmluZSBh IHByb2NlZHVyZSBiYXNlZCBvbiBmcWRuDQo+IGFuZA0KPiA+ID4gb3B0aW9uYWwgY29ubmVjdGl2 aXR5IGNoZWNrcy4NCj4gPg0KPiA+IFdoYXQgd2UgYXJlIGxvb2tpbmcgaGVyZSBpcyB0byBlbmFi bGUgY29ubmVjdGl2aXR5IGNoZWNrcyB3aXRob3V0DQo+IG1hbmRhdGluZyBkZXZlbG9wZXJzIHRv IGhvc3QgY29ubmVjdGl2aXR5IGNoZWNrIHNlcnZlcnMgYW5kIHRvIGtlZXANCj4gY29ubmVjdGl2 aXR5IGNoZWNrcyBhcyBsb2NhbCBhcyBwb3NzaWJsZS4NCj4gPg0KPg0KPiBQdXNoaW5nIHRoZSBi dXJkZW4gdG8gdGhlIG9wZXJhdG9yIGlzIG5vdCBhY2NlcHRhYmxlIHdpdGhvdXQgY29uc2VudC4g SQ0KPiBzdXBwb3NlIGhhdmluZyB0aGF0IGZxZG4gaW1wbGllcyBjb25zZW50DQo+DQo+ID4gPiBJ dCBpcyBub3QgYWNjZXB0YWJsZSB0byBleHBlY3QgYW55IGludGVyZmFjZSBvbiB0aGUgbmF0NjQg bm9kZSB0bw0KPiBoYXZlIGFuDQo+ID4gPiBmcWRuIG9yIHRvIHNlbmQgaWNtcCBjb25uZWN0aXZp dHkgY2hlY2tzIHRvIHRoZSBuYXQ2NCBub2RlLiAgVGhlDQo+ID4gPiBwcmVmNjQgbWF5IGhhdmUg YW4gZnFkbiwgdGhhdCBkb2VzIG1ha2Ugc2Vuc2UgdG8gbWUuDQo+ID4NCj4gPiBUaGUgSVB2NCBh ZGRyZXNzIGZvdW5kIHZpYSBkZXNjcmliZWQgcHJvY2VkdXJlIGRvZXMgbm90IHJlYWxseSBoYXZl IHRvDQo+IHBvaW50IHRvIE5BVDY0LCBpdCBjYW4gcG9pbnQgdG8gYW55IElQdjQgYWRkcmVzcyBj aG9zZW4gYnkgdGhlIG93bmVyIG9mDQo+IE5BVDY0J3MgRlFETiwgb3IgYmUgbm9uLWV4aXN0ZW50 Li4uIEkuZS4geW91IGNvdWxkIGRpc2FibGUgY29ubmVjdGl2aXR5DQo+IGNoZWNrcyBieSBub3Qg aGF2aW5nIEEgcmVjb3JkICh3aGljaCBpcyB0aGUgY2FzZSBhbnl3YXkgY3VycmVudGx5IGFzDQo+ IHRoZXJlJ3Mgbm8gc3RhbmRhcmQgd2F5IGZvciBob3N0IHRvIGxlYXJuIE5BVDY0J3MgRlFETiwg d2hpY2ggZG9lcyBub3QNCj4gbmVjZXNzYXJpbHkgZXZlbiBleGlzdCksIG9yIHlvdSBjb3VsZCBw b2ludCB0aGUgY2hlY2tzIHRvIHNlcGFyYXRlDQo+IHNlcnZlci4NCj4gPg0KPiA+IFNvLi4gd291 bGQgaXQgaGVscCBpZiB3ZSB3b3VsZCBtb3ZlIGFsbCBvZiB0aGUgQSByZWNvcmQgc3R1ZmYgZnJv bQ0KPiBETlNTRUMgc2VjdGlvbiB0byB0aGUgb3B0aW9uYWwgY29ubmVjdGl2aXR5IGNoZWNrIHNl Y3Rpb24sIGFuZCBkZXNjcmliZQ0KPiB0aGVyZSB0aGF0IG5ldHdvcmsgb3BlcmF0b3IgbWF5IGhl bHAgbm9kZXMgb24gY29ubmVjdGl2aXR5IGNoZWNrcyBieQ0KPiBoYXZpbmcgQSByZWNvcmQgZm9y IHRoZSBOQVQ2NCBGUUROIHRoYXQgcG9pbnRzIHRvIHNvbWV3aGVyZSAoYmUgdGhhdA0KPiBOQVQ2 NCBpdHNlbGYsIG9yIHNvbWUgZGVkaWNhdGVkIHNlcnZlcik/DQo+ID4NCj4NCj4gWWVzLiBUaGF0 IHdvdWxkIGhlbHAuIEJ1dCwgcGluZ2luZyB0aGUgY2duIGlzIHJlYWxseSBhIHJlY2lwZSBmb3IN Cj4gZGlzYXN0ZXIgdGhhdCBJIHdvdWxkIHJhdGhlciBub3Qgc2VlIGRvY3VtZW50ZWQgb3Igc3Vn Z2VzdGVkIHdpdGhvdXQNCj4gY2F1dGlvbi4NCj4NCj4NCj4gPiBCZXN0IHJlZ2FyZHMsDQo+ID4N Cj4gPiBUZWVtdQ0KPg0KPg0KDQo= --_000_13279437402548718camelNokiaN900_ Content-Type: text/html; charset="utf-8" Content-ID: <1327943739.25487.17.camel@Nokia-N900> Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMDEgVHJhbnNpdGlvbmFs Ly9FTiIgImh0dHA6Ly93d3cudzMub3JnL1RSL2h0bWw0L2xvb3NlLmR0ZCI+DQo8aHRtbD4NCjxo ZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7 IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0iZ2VuZXJhdG9yIiBjb250ZW50PSJPc3NvIE5v dGVzIj4NCjx0aXRsZT48L3RpdGxlPg0KPC9oZWFkPg0KPGJvZHk+DQo8cD5Paywgd2lsbCBjaGVj ayB0aGUgVFRMLCBidXQgSSB0aG91Z2ggdGhlIG9idmlvdXMgd291bGQgaGF2ZSBiZWVuIHRvIHVz ZSB0aGUgc2hvcnRlciBvZiB0aGUgdHdvOiBBIHJlY29yZCBUVEwgb3IgcmVtYWluaW5nIFByZWY2 NDo6L24gbGlmZXRpbWUgKG1heWJlIEknbSBtYWtpbmcgZGFuZ2Vyb3VzIGFzc3VtcHRpb24gYWdh aW4gd2hlbiBhc3N1bWluZyBQcmVmNjQ6Oi9uIEhBUyBhIGxpZmV0aW1lOikNCjxicj4NCjxicj4N CkZvciBjb25uZWN0aXZpdHkgY2hlY2sgSSB3b3VsZCBsaWtlIHRvIGhlYXIgb3RoZXIgb3Bpbmlv bnMgYXMgd2VsbC4gSSBndWVzcyB3ZSBoYXZlIG9uIHRoZSB0YWJsZToNCjxicj4NCi0gbm8gY2hl Y2sgZG9jdW1lbnRlZCA8YnI+DQotIG9wdGlvbmFsIGZvciB2ZW5kb3Igc3BlY2lmaWMgc2VydmVy IDxicj4NCi0gb3B0aW9uYWwgZm9yIG9wZXJhdG9yIGhvc3RlZCBzZXJ2ZXIgKGxlYXJudCB2aWEg QSByZWNvcmQgb2YgTkFUNjQgRlFETikgPGJyPg0KPGJyPg0KVGVlbXUgPGJyPg0KPGJyPg0KLS0t LS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0tLSA8YnI+DQomZ3Q7IDxicj4NCiZndDsgT24gSmFuIDMw LCAyMDEyIDQ6NTIgQU0sICZsdDs8YSBocmVmPSJtYWlsdG86dGVlbXUuc2F2b2xhaW5lbkBub2tp YS5jb20iPnRlZW11LnNhdm9sYWluZW5Abm9raWEuY29tPC9hPiZndDsgd3JvdGU6DQo8YnI+DQom Z3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IEhpIENhbWVyb24sIDxicj4NCiZndDsgJmd0OyA8YnI+ DQomZ3Q7ICZndDsgJmd0OyBXZWxsLCBpbiB0aGUgZHJhZnQsIHRoZSBvbmx5IGd1aWRhbmNlIGZv ciBpcHY0b25seS5hcnBhIHR0bCBpcyB0aGF0IDxicj4NCiZndDsgaXQgbm90IGV4Y2VlZCA8YnI+ DQomZ3Q7ICZndDsgJmd0OyAxIHllYXIuLi4gd2hpY2ggZG9lcyBub3QgaGVscCBpbiB0aGlzIHNp dHVhdGlvbi4gPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgVGhlIGRy YWZ0IHdvdWxkIGJlbmVmaXQgZnJvbSBleHBsaWNpdGx5IHN0YXRpbmcgZGlzY292ZXJlZCBwcmVm NjQgPGJyPg0KJmd0OyB0dGwgPSBwcmVmNjQgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgZnFkbiB0dGwu IFRoYXQgd2F5IHRoZSB0dGwgaXMgY29tcGxldGVseSBpbiBjb250cm9sIG9mIHRoZSBuZXR3b3Jr IDxicj4NCiZndDsgb3BlcmF0b3IuIDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgVGhl IG9wZXJhdG9yIGlzIGluIGNvbnRyb2wgb2YgVFRMIHVzZWQgaW4gc3ludGhldGljIEFBQUEgcmVj b3JkcyA8YnI+DQomZ3Q7IG9wZXJhdG9yJ3MgRE5TNjQgY3JlYXRlcywgb3IgYW0gSSBtaXN0YWtl bj8gQW5kIHRoYXQgVFRMIGRvZXMgbm90IGhhdmUgPGJyPg0KJmd0OyB0byBlcXVhbCB0byByZWxh dGVkIEEgcmVjb3JkIFRUTC4gSS5lLiBldmVuIGlmIGlwdjRvbmx5LmFycGEgd291bGQgaGF2ZSA8 YnI+DQomZ3Q7IDEgeWVhciBUVEwsIHRoZSBETlM2NCB0aGF0IHN5bnRoZXNpemVzIElQdjYgYWRk cmVzc2VzIGNhbiB1c2UgbXVjaCBsb3dlciA8YnI+DQomZ3Q7IFRUTCwgaGVuY2UgY2F1c2Ugbm9k ZXMgdG8gaGF2ZSBtdWNoIHNob3J0ZXIgVFRMIGZvciB0aGUgZGlzY292ZXJlZCA8YnI+DQomZ3Q7 IHByZWZpeC4gPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyBJIGJlbGlldmUg eW91IGFyZSBtaXN0YWtlbi4gUmZjIDYxNDcgc2F5cyB0aGUgb3JpZ2luYWwgdHRsIGlzIHBhc3Nl ZCBvbiwgPGJyPg0KJmd0OyBmcm9tIHRoZSBiZXN0IG9mIG15IHJlYWRpbmcuIDxicj4NCiZndDsg PGJyPg0KJmd0OyAmZ3Q7IElmIHRoZSBob3N0IHBlcmZvcm1zIFBUUiBxdWVyeSBhbmQgZm9yd2Fy ZCBBQUFBIHF1ZXJ5IGFzIGN1cnJlbnRseSA8YnI+DQomZ3Q7IGRlc2NyaWJlZCBpbiBETlNTRUMg c2VjdGlvbiwgdGhlbiBJIGd1ZXNzIHRoZSBUVEwgdXNlZCBieSBub2RlIGNvdWxkIGJlIDxicj4N CiZndDsgdGhlIE5BVDY0IEZRRE4gVFRMPyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7 ICZndDsgSXQgZG9lcyBub3QgbmVlZCB0byBiZSB0aGlzIHdheSwgcmlnaHQ/IFdoYXQgeW91IHJl YWxseSB3YW50IGlzIGEgPGJyPg0KJmd0OyBwYWlyaW5nIG9mIDxicj4NCiZndDsgJmd0OyAmZ3Q7 IGRucyByZWNvcmRzLCByaWdodD8gSWYgdGhhdCBpcyB3aGF0IGlzIG5lZWRlZCwgdGhlbiBsZXRz IHNheSB0aGF0LiBJIDxicj4NCiZndDsgd291bGQgbXVjaCA8YnI+DQomZ3Q7ICZndDsgJmd0OyBy YXRoZXIgcGFpciB0aGUgcHJlZjY0IGZxZG4gd2l0aCBhIGR1bW15IGZxZG4gZm9yIHRoaXMgcHVy cG9zZS4mbmJzcDsgSXQgPGJyPg0KJmd0OyBpcyBub3QgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgYWNj ZXB0YWJsZSB0byBuZXR3b3JrIG9wZXJhdG9ycyB0byBoYXZlIGEgbmFtZSBmb3IgYW4gaW50ZXJm YWNlIHdlIDxicj4NCiZndDsgZG8gbm90IDxicj4NCiZndDsgJmd0OyAmZ3Q7IHdhbnQgdHJhZmZp YyB0byBiZSBkZXN0aW5lIHRvLiA8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsg Jmd0OyBOb3QgbmljZS4gQ2duIGJveGVzIGFyZSBsb3RzIG9mIGFzaWNzIC8gZnBnYSAvIGJsYWgg YW5kIHJlbGF0aXZlbHkgPGJyPg0KJmd0OyB3ZWFrIGNvbnRyb2wgPGJyPg0KJmd0OyAmZ3Q7ICZn dDsgcGxhbmUgcHJvY2Vzc29ycyB0aGF0IGV4cGxpY2l0bHkgcmF0ZSBsaW1pdCBpY21wIHRvIGF2 b2lkIGNvbnRyb2wgPGJyPg0KJmd0OyBwbGFuZSA8YnI+DQomZ3Q7ICZndDsgJmd0OyByZXNvdXJj ZSBhdHRhY2tzLiBZb3UgY2Fubm90IHByZXNjcmliZSBob3cgdGhpcyBjYW4gYmUgdHJlYXRlZCwg dGhlIDxicj4NCiZndDsgZXhpc3RpbmcgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgdGV4dCBpcyBub3Qg YWNjZXB0YWJsZS4mbmJzcDsgSXQgbWF5IGJlIGFjY2VwdGFibGUgaWYgeW91IHRoaW5rIE5BVDY0 IGlzIDxicj4NCiZndDsgYSBMaW51eCBib3gsIDxicj4NCiZndDsgJmd0OyAmZ3Q7IGJ1dCBpbiBt YXkgbGFyZ2UgZGVwbG95bWVudHMsIGl0IGlzIGEgdmVyeSBkaWZmZXJlbnQgY2FzZS4gPGJyPg0K Jmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgTmV0IG5ldCwgdGhpcyBkcmFmdCwg SU1ITywgbmVlZHMgdG8gZGVmaW5lIGEgcHJvY2VkdXJlIGJhc2VkIG9uIGZxZG4gPGJyPg0KJmd0 OyBhbmQgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgb3B0aW9uYWwgY29ubmVjdGl2aXR5IGNoZWNrcy4g PGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBXaGF0IHdlIGFyZSBsb29raW5nIGhlcmUg aXMgdG8gZW5hYmxlIGNvbm5lY3Rpdml0eSBjaGVja3Mgd2l0aG91dCA8YnI+DQomZ3Q7IG1hbmRh dGluZyBkZXZlbG9wZXJzIHRvIGhvc3QgY29ubmVjdGl2aXR5IGNoZWNrIHNlcnZlcnMgYW5kIHRv IGtlZXAgPGJyPg0KJmd0OyBjb25uZWN0aXZpdHkgY2hlY2tzIGFzIGxvY2FsIGFzIHBvc3NpYmxl LiA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFB1c2hpbmcgdGhlIGJ1cmRl biB0byB0aGUgb3BlcmF0b3IgaXMgbm90IGFjY2VwdGFibGUgd2l0aG91dCBjb25zZW50LiBJIDxi cj4NCiZndDsgc3VwcG9zZSBoYXZpbmcgdGhhdCBmcWRuIGltcGxpZXMgY29uc2VudCA8YnI+DQom Z3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IEl0IGlzIG5vdCBhY2NlcHRhYmxlIHRvIGV4cGVjdCBh bnkgaW50ZXJmYWNlIG9uIHRoZSBuYXQ2NCBub2RlIHRvIDxicj4NCiZndDsgaGF2ZSBhbiA8YnI+ DQomZ3Q7ICZndDsgJmd0OyBmcWRuIG9yIHRvIHNlbmQgaWNtcCBjb25uZWN0aXZpdHkgY2hlY2tz IHRvIHRoZSBuYXQ2NCBub2RlLiZuYnNwOyBUaGUgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgcHJlZjY0 IG1heSBoYXZlIGFuIGZxZG4sIHRoYXQgZG9lcyBtYWtlIHNlbnNlIHRvIG1lLiA8YnI+DQomZ3Q7 ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IFRoZSBJUHY0IGFkZHJlc3MgZm91bmQgdmlhIGRlc2NyaWJl ZCBwcm9jZWR1cmUgZG9lcyBub3QgcmVhbGx5IGhhdmUgdG8gPGJyPg0KJmd0OyBwb2ludCB0byBO QVQ2NCwgaXQgY2FuIHBvaW50IHRvIGFueSBJUHY0IGFkZHJlc3MgY2hvc2VuIGJ5IHRoZSBvd25l ciBvZiA8YnI+DQomZ3Q7IE5BVDY0J3MgRlFETiwgb3IgYmUgbm9uLWV4aXN0ZW50Li4uIEkuZS4g eW91IGNvdWxkIGRpc2FibGUgY29ubmVjdGl2aXR5IDxicj4NCiZndDsgY2hlY2tzIGJ5IG5vdCBo YXZpbmcgQSByZWNvcmQgKHdoaWNoIGlzIHRoZSBjYXNlIGFueXdheSBjdXJyZW50bHkgYXMgPGJy Pg0KJmd0OyB0aGVyZSdzIG5vIHN0YW5kYXJkIHdheSBmb3IgaG9zdCB0byBsZWFybiBOQVQ2NCdz IEZRRE4sIHdoaWNoIGRvZXMgbm90IDxicj4NCiZndDsgbmVjZXNzYXJpbHkgZXZlbiBleGlzdCks IG9yIHlvdSBjb3VsZCBwb2ludCB0aGUgY2hlY2tzIHRvIHNlcGFyYXRlIDxicj4NCiZndDsgc2Vy dmVyLiA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IFNvLi4gd291bGQgaXQgaGVscCBp ZiB3ZSB3b3VsZCBtb3ZlIGFsbCBvZiB0aGUgQSByZWNvcmQgc3R1ZmYgZnJvbSA8YnI+DQomZ3Q7 IEROU1NFQyBzZWN0aW9uIHRvIHRoZSBvcHRpb25hbCBjb25uZWN0aXZpdHkgY2hlY2sgc2VjdGlv biwgYW5kIGRlc2NyaWJlIDxicj4NCiZndDsgdGhlcmUgdGhhdCBuZXR3b3JrIG9wZXJhdG9yIG1h eSBoZWxwIG5vZGVzIG9uIGNvbm5lY3Rpdml0eSBjaGVja3MgYnkgPGJyPg0KJmd0OyBoYXZpbmcg QSByZWNvcmQgZm9yIHRoZSBOQVQ2NCBGUUROIHRoYXQgcG9pbnRzIHRvIHNvbWV3aGVyZSAoYmUg dGhhdCA8YnI+DQomZ3Q7IE5BVDY0IGl0c2VsZiwgb3Igc29tZSBkZWRpY2F0ZWQgc2VydmVyKT8g PGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyBZZXMuIFRoYXQgd291bGQgaGVs cC4gQnV0LCBwaW5naW5nIHRoZSBjZ24gaXMgcmVhbGx5IGEgcmVjaXBlIGZvciA8YnI+DQomZ3Q7 IGRpc2FzdGVyIHRoYXQgSSB3b3VsZCByYXRoZXIgbm90IHNlZSBkb2N1bWVudGVkIG9yIHN1Z2dl c3RlZCB3aXRob3V0IDxicj4NCiZndDsgY2F1dGlvbi4gPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxi cj4NCiZndDsgJmd0OyBCZXN0IHJlZ2FyZHMsIDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZn dDsgVGVlbXUgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCjxicj4NCjwvcD4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_13279437402548718camelNokiaN900_-- From stephan.lagerholm@secure64.com Mon Jan 30 11:33: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 13EFE21F8665 for ; Mon, 30 Jan 2012 11:33:48 -0800 (PST) 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=[AWL=0.000, 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 22ESDh-fuBBN for ; Mon, 30 Jan 2012 11:33:47 -0800 (PST) Received: from zimbra.secure64.com (unknown [64.92.221.189]) by ietfa.amsl.com (Postfix) with ESMTP id 311B321F863B for ; Mon, 30 Jan 2012 11:33:47 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.secure64.com (Postfix) with ESMTP id C6AFDB8493; Mon, 30 Jan 2012 12:33:46 -0700 (MST) 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 b7SPA1SLRevN; Mon, 30 Jan 2012 12:33:45 -0700 (MST) Received: from exchange.secure64.com (exchange.secure64.com [192.168.254.250]) by zimbra.secure64.com (Postfix) with ESMTPSA id 79580B8491; Mon, 30 Jan 2012 12:33:45 -0700 (MST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=secure64.com; s=2010; t=1327952025; bh=OzO6nAp0pwBPgCTq75ht78qEXQOOliKtLhXc3FDLb90=; h=MIME-Version:Content-Type:Content-Transfer-Encoding:Subject:Date: Message-ID:In-Reply-To:References:From:To:Cc; b=e4Z0/ly+wV8Zkcrq/L d16YkRjddXtwtiIKbPPGvDASwwzPGp3y+DlK2viwekQUntjZhzQttUrkofzqQWsc4Vg oAJUvxKvhLtVVy4LjtH4bcjQ44muUYI3pd0shp0Tges2utF4L4AmYTR26N27TejLwOK 6Y+ok/wRSsJ3rCq0RBs= Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 30 Jan 2012 12:33:43 -0700 Message-ID: In-Reply-To: <916CE6CF87173740BC8A2CE443096962042CAF87@008-AM1MPN1-051.mgdnok.nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DNSSEC and NAT64 Discovery Heuristic [was RE: [BEHAVE] I-D Action: draft-ietf-behave-nat64-discovery-heuristic-05.txt] Thread-Index: AQHM3RfdVEdgOoBqgki3VCG9yLTfQ5Yk1odwgAB5pHA= References: <916CE6CF87173740BC8A2CE443096962042B6DB0@008-AM1MPN1-053.mgdnok.nokia.com><916CE6CF87173740BC8A2CE443096962042C1ADE@008-AM1MPN1-053.mgdnok.nokia.com> <158001ccdd17$d8c00170$8a400450$@com> <916CE6CF87173740BC8A2CE443096962042CAF87@008-AM1MPN1-051.mgdnok.nokia.com> From: "Stephan Lagerholm" To: , Cc: behave@ietf.org Subject: Re: [BEHAVE] DNSSEC and NAT64 Discovery Heuristic [was RE: I-D Action: draft-ietf-behave-nat64-discovery-heuristic-05.txt] X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 19:33:48 -0000 Hi Teemu, > > > > > > I don't like this requirement because it is forcing the DNS server > to support views. Additionally, you will have to update the > authoritative DNS every time you start provisioning your clients with new > addresses from new IPv6 networks. > > > > Fair point. Teemu, Jouni, thoughts on this? >=20 > The text was attempting to tackle the following attack: > - Legitimate network A is using NAT64 and related domain names are all > secured with DNSSEC > - Host is in hostile network B, where attacker has control over local > DNS64, NAT64 and routing services > - Host performs AAAA query for the well-known name, which is replied by > attacker's DNS64 using network A's Pref64::/n > - Host performs reverse query to find the FQDN for the prefix, and > find's network A's NAT64's FQDN (attacker not involved in this query) > - Host performs forward query for the learned name, validates response > with DNSSEC, and gets the same Pref64::/n as it got originally for the > well-known name (attacker not involved in this query) > - Host thinks it has learned Pref64::/n safely >=20 > Except that the host has not, because even though the discovered > Pref64::/n was matching the NAT64 FQDN and all that just fine, the host > is in a network B that should not be using the network A's Pref64::/n > and hence all host's packets could be routed to network B's NAT64 under > control of attacker (instead of NAT64 of network A - remember attacker > has taken over routing to Pref64::/n). Is sounds very easy to circumvent the security in the proposed discovery algorithm in that case. Why would the attacker use A's Pref64::/n why couldn't he just use his own Perf64::/n and insert the appropriate records into DNS? /Stephan From dwing@cisco.com Mon Jan 30 11:55: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 7F84C11E8093 for ; Mon, 30 Jan 2012 11:55:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.563 X-Spam-Level: X-Spam-Status: No, score=-106.563 tagged_above=-999 required=5 tests=[AWL=0.036, 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 4BudUVeQaCYN for ; Mon, 30 Jan 2012 11:55:44 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id C364F11E8091 for ; Mon, 30 Jan 2012 11:55:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=3002; q=dns/txt; s=iport; t=1327953344; x=1329162944; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=MnkEwq5XafO8grKmlSH0GYmVXPKabZtixJxvRpGYo1E=; b=D5wQA9N9sVJJ0wevApdfxbf9oUnfKvXlYCU4d+ifxemk0sl34Uu2WJBw mQOrZacGpB+rO8V1Fkc4EzAGxE0UkyQ+fhCruRtO4RWdQ05HbJql/SBu3 dSRsmfbHcQK5ug14JVox+lT5FlZrUSQ5CA8HPKe0D7occFJ9nUf8hrGgB A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFADj1Jk+rRDoI/2dsb2JhbABCAZ9mjnCBBYFyAQEBBAgKARcQPwwBAwIJDwIEAQEaAggEBxkjCgkIAgQBEgsXh2OaEgGeOog0AwEFAScECAEKBA0LEgcJhAsCNCkBgwoEiD+FBJpJ X-IronPort-AV: E=Sophos;i="4.71,592,1320624000"; d="scan'208";a="27832725" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 30 Jan 2012 19:55:44 +0000 Received: from dwingWS ([10.32.240.198]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q0UJtipH017228; Mon, 30 Jan 2012 19:55:44 GMT From: "Dan Wing" To: "'Stephan Lagerholm'" , References: <916CE6CF87173740BC8A2CE443096962042B6DB0@008-AM1MPN1-053.mgdnok.nokia.com><916CE6CF87173740BC8A2CE443096962042C1ADE@008-AM1MPN1-053.mgdnok.nokia.com> <158001ccdd17$d8c00170$8a400450$@com> <916CE6CF87173740BC8A2CE443096962042CAF87@008-AM1MPN1-051.mgdnok.nokia.com> In-Reply-To: Date: Mon, 30 Jan 2012 11:55:44 -0800 Message-ID: <050401ccdf89$271fa280$755ee780$@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: AQHM3RfdVEdgOoBqgki3VCG9yLTfQ5Yk1odwgAB5pHCAAATNYA== Content-Language: en-us Cc: behave@ietf.org Subject: Re: [BEHAVE] DNSSEC and NAT64 Discovery Heuristic [was RE: I-D Action: draft-ietf-behave-nat64-discovery-heuristic-05.txt] X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 19:55:45 -0000 > -----Original Message----- > From: Stephan Lagerholm [mailto:stephan.lagerholm@secure64.com] > Sent: Monday, January 30, 2012 11:34 AM > To: teemu.savolainen@nokia.com; dwing@cisco.com > Cc: behave@ietf.org > Subject: RE: DNSSEC and NAT64 Discovery Heuristic [was RE: [BEHAVE] I-D > Action: draft-ietf-behave-nat64-discovery-heuristic-05.txt] > > Hi Teemu, > > > > > > > > > I don't like this requirement because it is forcing the DNS > server > > to support views. Additionally, you will have to update the > > authoritative DNS every time you start provisioning your clients with > new > > addresses from new IPv6 networks. > > > > > > Fair point. Teemu, Jouni, thoughts on this? > > > > The text was attempting to tackle the following attack: > > - Legitimate network A is using NAT64 and related domain names are > all > > secured with DNSSEC > > - Host is in hostile network B, where attacker has control over local > > DNS64, NAT64 and routing services > > - Host performs AAAA query for the well-known name, which is replied > by > > attacker's DNS64 using network A's Pref64::/n > > - Host performs reverse query to find the FQDN for the prefix, and > > find's network A's NAT64's FQDN (attacker not involved in this query) > > - Host performs forward query for the learned name, validates > response > > with DNSSEC, and gets the same Pref64::/n as it got originally for > the > > well-known name (attacker not involved in this query) > > - Host thinks it has learned Pref64::/n safely > > > > Except that the host has not, because even though the discovered > > Pref64::/n was matching the NAT64 FQDN and all that just fine, the > host > > is in a network B that should not be using the network A's Pref64::/n > > and hence all host's packets could be routed to network B's NAT64 > under > > control of attacker (instead of NAT64 of network A - remember > attacker > > has taken over routing to Pref64::/n). > > Is sounds very easy to circumvent the security in the proposed > discovery > algorithm in that case. > Why would the attacker use A's Pref64::/n why couldn't he just use his > own Perf64::/n and insert the appropriate records into DNS? The host needs to be configured with the domain names of the NAT64 devices it will trust -- for example, if I get my Internet service from Comcast, I would configure my host to allow a name of *.comcast.net for the NAT64. The trusted domain name could reasonably be populated by the 'DNS Search List' (DNSSL) provided by DHCP, which eliminates the need for any manual configuration, and would work in many cases when visiting a friend's house or coffee shop. This is described in step #b of http://tools.ietf.org/html/draft-wing-behave-learn-prefix-04#section-5. But I see we missed step #b when http://tools.ietf.org/html/draft-wing-behave-learn-prefix-04#section-5 was incorporated into draft-ietf-behave-nat64-discovery-heuristic. Sorry about that. -d From stephan.lagerholm@secure64.com Mon Jan 30 13:02: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 B353E21F862F for ; Mon, 30 Jan 2012 13:02:54 -0800 (PST) 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=[AWL=0.000, 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 gwv5VOyQV4eB for ; Mon, 30 Jan 2012 13:02:54 -0800 (PST) Received: from zimbra.secure64.com (unknown [64.92.221.189]) by ietfa.amsl.com (Postfix) with ESMTP id 24BDE21F862B for ; Mon, 30 Jan 2012 13:02:54 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.secure64.com (Postfix) with ESMTP id 5FF1DB8493; Mon, 30 Jan 2012 14:02:51 -0700 (MST) 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 VNpWrUtAxaPA; Mon, 30 Jan 2012 14:02:51 -0700 (MST) Received: from exchange.secure64.com (exchange.secure64.com [192.168.254.250]) by zimbra.secure64.com (Postfix) with ESMTPSA id E1EB3B8491; Mon, 30 Jan 2012 14:02:50 -0700 (MST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=secure64.com; s=2010; t=1327957370; bh=NbxULA2V8uitmUWcm31Ds70omL0ci868GgFDQ92hWio=; h=MIME-Version:Content-Type:Content-Transfer-Encoding:Subject:Date: Message-ID:In-Reply-To:References:From:To:Cc; b=DfPKoHhEPng9tHtKWz 83s81YlOluXhUsAhLq74hbzVT1hDOraDWQdERmO1suRxle2WkgZVWB93PGBp5Yf9gB3 jq0q2HvJEzzvK1qxn/FqrFgI1QDUDtYjThHiI1IY7sB6Z7reLud9gJZ6jyEnU+5s4wU j4WHEXY4Uz01uzpg/e0= Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 30 Jan 2012 14:02:49 -0700 Message-ID: In-Reply-To: <050401ccdf89$271fa280$755ee780$@com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] DNSSEC and NAT64 Discovery Heuristic [was RE: I-DAction: draft-ietf-behave-nat64-discovery-heuristic-05.txt] Thread-Index: AQHM3RfdVEdgOoBqgki3VCG9yLTfQ5Yk1odwgAB5pHCAAATNYIAAFFCg References: <916CE6CF87173740BC8A2CE443096962042B6DB0@008-AM1MPN1-053.mgdnok.nokia.com><916CE6CF87173740BC8A2CE443096962042C1ADE@008-AM1MPN1-053.mgdnok.nokia.com><158001ccdd17$d8c00170$8a400450$@com><916CE6CF87173740BC8A2CE443096962042CAF87@008-AM1MPN1-051.mgdnok.nokia.com> <050401ccdf89$271fa280$755ee780$@com> From: "Stephan Lagerholm" To: "Dan Wing" , Cc: behave@ietf.org Subject: Re: [BEHAVE] DNSSEC and NAT64 Discovery Heuristic [was RE: I-DAction: draft-ietf-behave-nat64-discovery-heuristic-05.txt] X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 21:02:54 -0000 >=20 > The host needs to be configured with the domain names of the NAT64 > devices it will trust -- for example, if I get my Internet service > from Comcast, I would configure my host to allow a name of > *.comcast.net for the NAT64. =20 Thanks, that make sense but it raises another question: If you=20 already know that you are in example.net (or Comcast.net in your=20 example). They why couldn't you just ask for=20 what-is-my-prefix.example.net,=20 what-is-my-prefixlength.example.net, what-is-my-suffix.example.net ?=20 Those could be signed with DNSSEC. That sounds like a much simpler way=20 of learning the prefixes. /S From stephan.lagerholm@secure64.com Mon Jan 30 13:03: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 0EFE211E80B4 for ; Mon, 30 Jan 2012 13:03:23 -0800 (PST) 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=[AWL=0.000, 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 V5bJvI5ime6I for ; Mon, 30 Jan 2012 13:03:22 -0800 (PST) Received: from zimbra.secure64.com (unknown [64.92.221.189]) by ietfa.amsl.com (Postfix) with ESMTP id 978D421F8634 for ; Mon, 30 Jan 2012 13:03:22 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.secure64.com (Postfix) with ESMTP id 859D3B8493; Mon, 30 Jan 2012 14:03:22 -0700 (MST) 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 1qVt1YoW1q4O; Mon, 30 Jan 2012 14:03:22 -0700 (MST) Received: from exchange.secure64.com (exchange.secure64.com [192.168.254.250]) by zimbra.secure64.com (Postfix) with ESMTPSA id 1D31BB8491; Mon, 30 Jan 2012 14:03:22 -0700 (MST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=secure64.com; s=2010; t=1327957402; bh=gCyxgC2aMqzKq70qwkCGxG1gaWqGYBf4yhBWg7Zqbsg=; h=MIME-Version:Content-Type:Content-Transfer-Encoding:Subject:Date: Message-ID:In-Reply-To:References:From:To; b=dJAHID40WX+IgHyf4tSTV QjN0wm/tlv9Ui4iJAC9bGgGvI/e541gdhog8qjhki9qnR96YHTzpZBMxVUxBSP92pNZ q085UbvxOrzv7f4VqEoHxjBIPfSO1M6A8MHMl7Zz4RXq87wL1lQivNRnZhSmArwHcb9 HWo74VZRJb3NdpIs= Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 30 Jan 2012 14:03:20 -0700 Message-ID: In-Reply-To: <20120130133205.GB91476@shinkuro.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] DNSSEC and NAT64 Discovery Heuristic [was RE: I-D Action:draft-ietf-behave-nat64-discovery-heuristic-05.txt] Thread-Index: AczfU6At5POc2hdgR0GCuCA2TVkm+wAMo2ww References: <916CE6CF87173740BC8A2CE443096962042C1ADE@008-AM1MPN1-053.mgdnok.nokia.com><158001ccdd17$d8c00170$8a400450$@com><20120127211558.GG17728@mail.yitter.info><20120128005714.BF0431C2FE52@drugs.dv.isc.org><20120129164553.GC19634@mail.yitter.info><20120129230824.4FE1B1C3B476@drugs.dv.isc.org><20120130003943.GA89537@shinkuro.com><20120130020142.0F0D81C403B8@drugs.dv.isc.org> <20120130133205.GB91476@shinkuro.com> From: "Stephan Lagerholm" To: "Andrew Sullivan" , Subject: Re: [BEHAVE] DNSSEC and NAT64 Discovery Heuristic [was RE: I-D Action:draft-ietf-behave-nat64-discovery-heuristic-05.txt] X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 21:03:23 -0000 Hi Andrew, > Mark, >=20 > On Mon, Jan 30, 2012 at 01:01:41PM +1100, Mark Andrews wrote: > > > > Attempting to determine intent from DO and CD as section 3 of RFC6147 > > does is "just not possible". DNSSEC does not have the "I intend > > to validate" bit and no combination of bits means "I intended to > > validate". Pretending that there is such a combination does no-one > > any favours. >=20 > I do not believe that RFC6147 is intending to determine intent at all. > First, section 3 isn't normative; it's some background that is > intended to motivate the decision to use CD as an extra signal. But > anyway, as I already suggested in the previous message, section 3 > number 3 is likely overstating its case. >=20 > All of that said, you seem to be ignoring the use case for DNS64. > Remember that DNS64 _is not_ DNS.=20 My concern is that it is impossible to know if you are behind DNS64 or not.=20 How would somebody validating know that? For somebody behind DNS64,=20 DNS64 _is_ DNS. /S From marka@isc.org Mon Jan 30 13:09: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 A294921F865A for ; Mon, 30 Jan 2012 13:09:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.044, 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 jix6me0ndH5t for ; Mon, 30 Jan 2012 13:09:29 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 8F0201F0C4F for ; Mon, 30 Jan 2012 13:09:29 -0800 (PST) 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 "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id 25DE55F98B1; Mon, 30 Jan 2012 21:09:13 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:2dfa:e09d:2caa:6cb9]) (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 E343A216C6F; Mon, 30 Jan 2012 21:09:10 +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 A5E701C5FDF4; Tue, 31 Jan 2012 08:09:05 +1100 (EST) To: Andrew Sullivan From: Mark Andrews References: <158001ccdd17$d8c00170$8a400450$@com> <20120127211558.GG17728@mail.yitter.info> <20120128005714.BF0431C2FE52@drugs.dv.isc.org> <20120129164553.GC19634@mail.yitter.info> <20120129230824.4FE1B1C3B476@drugs.dv.isc.org> <20120130003943.GA89537@shinkuro.com> <20120130020142.0F0D81C403B8@drugs.dv.isc.org> <20120130133205.GB91476@shinkuro.com> <20120130145402.3A9CD1C5F1B0@drugs.dv.isc.org> <20120130151048.GC91476@shinkuro.com> In-reply-to: Your message of "Mon, 30 Jan 2012 10:10:54 CDT." <20120130151048.GC91476@shinkuro.com> Date: Tue, 31 Jan 2012 08:09:05 +1100 Message-Id: <20120130210905.A5E701C5FDF4@drugs.dv.isc.org> Cc: behave@ietf.org Subject: Re: [BEHAVE] DNSSEC and NAT64 Discovery Heuristic [was RE: I-D Action:draft-ietf-behave-nat64-discovery-heuristic-05.txt] X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 21:09:30 -0000 In message <20120130151048.GC91476@shinkuro.com>, Andrew Sullivan writes: > On Tue, Jan 31, 2012 at 01:54:01AM +1100, Mark Andrews wrote: > > > And CD=1 will not help with this senario. The non-validating > > resolver will cache the DNS64 translated responses and will return > > those translated responses to DO=1,CD=1 queries which will then > > fail to validate. Or if the DO=1,CD=1 query is the first query > > then the non validating stub resolvers will get NODATA responses > > to AAAA queries instead of synthesised responses. > > Ah, wait. You are worried about the case where a caching > security-aware non-validating dns64-oblivious recursive resolver is > behind a DNS64, and providing service for other clients inside that > network? Yeah, that won't work. There's a rather clumsy and > too-short discussion of some (but not all) of these issues in RFC6147, > section 6. > > > Put a DNS64 recursive server (as described in RFC6147) in front of > > a non validating DO=1 recursive server in front of a validating > > recursive server. > > No, don't. It won't work reliably, I agree. Basically, if the DNS64 > isn't the last hop before the validation point, then you're screwed. And RFC6147 doesn't provide any way for a caching server to learn the DNS64 prefixes to apply from upstream. It doesn't provide a away for answers to DO=1 queries not to be tainted. The EDNS option I suggested earlier in the thread would be sufficient. Maintain a reference counted cache of learned prefix sets and record a reference to it with the AAAA nodata negative cache entry. The DNS64 prefixes would timeout when the nodata negative cache entry times out. Alternatively we could make it more complicated and send the full policy, client address to match (IPv4 and IPv6) and exclusion address (IPv4 and IPv6) and TTL. Upstream requests would include a 32 (64?) bit hash of the DNS64 policy so that it doesn't have to be transmitted on every AAAA response. Sending that hash in the response would update the TTL entry. > At the same time, I'm a little alarmed at the prospect of caches that > hand out queries discovered with CD=0 to clients querying with CD=1, > regardless of whether they are a DNS64 or a DNS server. That should > likely be taken up on another list, however. While it is fodder for the other list, it isn't wrong as the RFC 4035 now stands. Additionally asking upstream again on CD=1 is not sufficient as there is no control of which server is queried. > > > there is twofold. First, since the only way to be sure you get all > > > the necessary validation data is to set CD=1, > > > > Not true. > > I think we are just talking with different implicit scope here, but > that's a general DNS issue and not, I think, a subject for this list. > I believe what I said, however, and I think a careful reading of RFC > 4035 backs me up. > > 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 ajs@anvilwalrusden.com Mon Jan 30 13:23: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 9358A11E80A3 for ; Mon, 30 Jan 2012 13:23:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.663 X-Spam-Level: X-Spam-Status: No, score=-2.663 tagged_above=-999 required=5 tests=[AWL=-0.064, 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 zUwvjCQZAwSD for ; Mon, 30 Jan 2012 13:23:30 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id DB1D611E80A1 for ; Mon, 30 Jan 2012 13:23:29 -0800 (PST) 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 E5D8F1ECB41C for ; Mon, 30 Jan 2012 21:23:28 +0000 (UTC) Date: Mon, 30 Jan 2012 16:23:26 -0500 From: Andrew Sullivan To: behave@ietf.org Message-ID: <20120130212326.GH19775@mail.yitter.info> References: <158001ccdd17$d8c00170$8a400450$@com> <20120127211558.GG17728@mail.yitter.info> <20120128005714.BF0431C2FE52@drugs.dv.isc.org> <20120129164553.GC19634@mail.yitter.info> <20120129230824.4FE1B1C3B476@drugs.dv.isc.org> <20120130003943.GA89537@shinkuro.com> <20120130020142.0F0D81C403B8@drugs.dv.isc.org> <20120130133205.GB91476@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [BEHAVE] DNSSEC and NAT64 Discovery Heuristic [was RE: I-D Action:draft-ietf-behave-nat64-discovery-heuristic-05.txt] X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 21:23:30 -0000 On Mon, Jan 30, 2012 at 02:03:20PM -0700, Stephan Lagerholm wrote: > My concern is that it is impossible to know if you are behind DNS64 or > not. > How would somebody validating know that? For somebody behind DNS64, > DNS64 _is_ DNS. Exactly. That's what this heuristic draft is trying to work out. I haven't yet had a chance to review the latest version. I have to be honest that I remain a little sceptical that this approach is the best way to do it. (Ok, to be blunt: I think this is an awful idea, but since people are apparently going to implement this anyway, we might as well do it right.) I am also still somewhat sceptical that all the machinery in Dan's forward- and reverse-tree mechanism is really necessary, especially since it requires the static list of "trusted DNS64s" (that part is the thing that bugs me the most). But I _think_ the current proposal mostly works anyway. One important thing, though: I don't believe that DNS64+NAT64 is going to be that reliable. That is, I expect it to have failure modes that are persistent and annoying, especially in the face of DNSSEC. I also don't think there's anything we can really do about that: all the other options seem to me to be at least as complicated or prone to failure. I think the best bet is going to be to have last-hop security between stubs and the DNS64 doing recursion; and then to use the AD bit and validation at the DNS64 to solve most of that problem. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From ajs@anvilwalrusden.com Mon Jan 30 13:32: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 6BE3E11E80A2 for ; Mon, 30 Jan 2012 13:32:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.662 X-Spam-Level: X-Spam-Status: No, score=-2.662 tagged_above=-999 required=5 tests=[AWL=-0.062, 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 B1qnksWzRws3 for ; Mon, 30 Jan 2012 13:32:33 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id C810111E809F for ; Mon, 30 Jan 2012 13:32:33 -0800 (PST) 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 231221ECB41C for ; Mon, 30 Jan 2012 21:32:33 +0000 (UTC) Date: Mon, 30 Jan 2012 16:32:31 -0500 From: Andrew Sullivan To: behave@ietf.org Message-ID: <20120130213230.GI19775@mail.yitter.info> References: <20120127211558.GG17728@mail.yitter.info> <20120128005714.BF0431C2FE52@drugs.dv.isc.org> <20120129164553.GC19634@mail.yitter.info> <20120129230824.4FE1B1C3B476@drugs.dv.isc.org> <20120130003943.GA89537@shinkuro.com> <20120130020142.0F0D81C403B8@drugs.dv.isc.org> <20120130133205.GB91476@shinkuro.com> <20120130145402.3A9CD1C5F1B0@drugs.dv.isc.org> <20120130151048.GC91476@shinkuro.com> <20120130210905.A5E701C5FDF4@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120130210905.A5E701C5FDF4@drugs.dv.isc.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [BEHAVE] DNSSEC and NAT64 Discovery Heuristic [was RE: I-D Action:draft-ietf-behave-nat64-discovery-heuristic-05.txt] X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 21:32:34 -0000 On Tue, Jan 31, 2012 at 08:09:05AM +1100, Mark Andrews wrote: > And RFC6147 doesn't provide any way for a caching server to learn > the DNS64 prefixes to apply from upstream. Correct. > The EDNS option I suggested earlier in the thread would be sufficient. And it's little different from a similar thought I had when the DNS64 work started taking off. Everyone said at the time, "Not going to do an EDNS0 option." Similarly, the current heuristic draft picked the well-known name strategy because at some relatively recent IETF meeting (Prague maybe? less recent than I thought, I guess) someone stood at the mic and said, "Add EDNS0 options and other gewgaws all you want. I'm going to implement a well-known name anyway." That's how an EDNS0 option disappeared from the WG's plans for how to handle this signalling. > Maintain a reference counted cache of learned prefix sets and record > a reference to it with the AAAA nodata negative cache entry. The > DNS64 prefixes would timeout when the nodata negative cache entry > times out. How will applications learn about all of this? There are applications that need to know about the NAT64 too, because they have IPv4 literals in them (yes, I know they shouldn't have done that. If I ran the circus, the ponies would run in the other direction, too). Since the API to DNS data is so crummy, those applications have no easy (i.e. accessible to people who don't actually know about DNS) way of learning this. So they're going to implement this dirty well-known-name hack anyway. Therefore, we need to make it as non-bad as it can be, rather than making it good. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From teemu.savolainen@nokia.com Mon Jan 30 13:40: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 9C93711E80B1 for ; Mon, 30 Jan 2012 13:40:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.748 X-Spam-Level: X-Spam-Status: No, score=-2.748 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AmQqIcyKeWUJ for ; Mon, 30 Jan 2012 13:40:58 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id A5D4111E80B0 for ; Mon, 30 Jan 2012 13:40:58 -0800 (PST) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q0ULesEb005008; Mon, 30 Jan 2012 23:40:55 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.56]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 30 Jan 2012 23:40:54 +0200 Received: from 008-AM1MPN1-051.mgdnok.nokia.com ([169.254.1.68]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.01.0355.003; Mon, 30 Jan 2012 22:40:53 +0100 From: To: , Thread-Topic: DNSSEC and NAT64 Discovery Heuristic [was RE: [BEHAVE] I-D Action: draft-ietf-behave-nat64-discovery-heuristic-05.txt] Thread-Index: Aczfl9dEBwZTR95UR7u2s02Jg9Qn6A== Date: Mon, 30 Jan 2012 21:40:53 +0000 Message-ID: <1327959645.26096.5.camel@Nokia-N900> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_1327959645260965camelNokiaN900_" MIME-Version: 1.0 X-OriginalArrivalTime: 30 Jan 2012 21:40:54.0434 (UTC) FILETIME=[D807B020:01CCDF97] X-Nokia-AV: Clean Cc: behave@ietf.org Subject: Re: [BEHAVE] DNSSEC and NAT64 Discovery Heuristic [was RE: I-D Action: draft-ietf-behave-nat64-discovery-heuristic-05.txt] X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: teemu.savolainen@nokia.com List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 21:40:59 -0000 --_000_1327959645260965camelNokiaN900_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Rm9yIGF0dGFja2VyIHRvIHVzZSBvd24gUHJlZjY0OjovbiB0aGUgYXR0YWNrZXIgd291bGQgbmVl ZCB0byBiZSBhYmxlIHRvIHNpZ24gdGhlIHJlcXVpcmVkIEROUyByZWNvcmRzIGluIGEgd2F5IHRo YXQgdmFsaWRhdGluZyBob3N0IGFjY2VwdHMgdGhlbS4gSW4gdGhhdCBjYXNlIHRoZSBhdHRhY2tl ciB3b3VsZCBhcHBlYXIgdG8gYmUgYXMgbGVnaXRpbWF0ZSBhcyBhbnkgSVNQLg0KDQpJJ20gd29u ZGVyaW5nIGlmIHRoZSBhdHRhY2sgSSBkZXNjcmliZWQgaXMgYWN0dWFsbHkgc29tZXRoaW5nIHdl IG5lZWQgdG8gYWRkcmVzcz8gSSBtZWFuIGlmIHRoZSBhdHRhY2tlciBjb250cm9scyBETlMoNjQp IGEgaG9zdCBpcyB1c2luZyBhbmQgcm91dGluZyBvbiB0aGUgYWNjZXNzIG5ldHdvcmsgdGhlIGhv c3QgaXMgYXR0YWNoZWQgdG8sIHRoZSBhdHRhY2tlciBjYW4gY2F1c2UgcHJvYmxlbXMgYW55d2F5 IChpbmNsdWRpbmcgdG8gdGhlIHRyYWZmaWMgdXNpbmcgbm9uLXN5bnRoZXRpYyBhZGRyZXNzZXMp Lg0KDQpJZiB3ZSBhZ3JlZSB3ZSBkbyBub3QgYWRyZXNzIHRoaXMgYXR0YWNrLCB3ZSBjb3VsZCBk cm9wIHRoZSBzcGxpdCBETlMgdGV4dC4NCg0KVGVlbXUNCg0KLS0tLS0gT3JpZ2luYWwgbWVzc2Fn ZSAtLS0tLQ0KPiBIaSBUZWVtdSwNCj4NCj4gPiA+ID4NCj4gPiA+ID4gSSBkb24ndCBsaWtlIHRo aXMgcmVxdWlyZW1lbnQgYmVjYXVzZSBpdCBpcyBmb3JjaW5nIHRoZSBETlMgc2VydmVyDQo+ID4g dG8gc3VwcG9ydCB2aWV3cy4gQWRkaXRpb25hbGx5LCB5b3Ugd2lsbCBoYXZlIHRvIHVwZGF0ZSB0 aGUNCj4gPiBhdXRob3JpdGF0aXZlIEROUyBldmVyeSB0aW1lIHlvdSBzdGFydCBwcm92aXNpb25p bmcgeW91ciBjbGllbnRzIHdpdGgNCj4gbmV3DQo+ID4gYWRkcmVzc2VzIGZyb20gbmV3IElQdjYg bmV0d29ya3MuDQo+ID4gPg0KPiA+ID4gRmFpciBwb2ludC4gIFRlZW11LCBKb3VuaSwgdGhvdWdo dHMgb24gdGhpcz8NCj4gPg0KPiA+IFRoZSB0ZXh0IHdhcyBhdHRlbXB0aW5nIHRvIHRhY2tsZSB0 aGUgZm9sbG93aW5nIGF0dGFjazoNCj4gPiAtIExlZ2l0aW1hdGUgbmV0d29yayBBIGlzIHVzaW5n IE5BVDY0IGFuZCByZWxhdGVkIGRvbWFpbiBuYW1lcyBhcmUgYWxsDQo+ID4gc2VjdXJlZCB3aXRo IEROU1NFQw0KPiA+IC0gSG9zdCBpcyBpbiBob3N0aWxlIG5ldHdvcmsgQiwgd2hlcmUgYXR0YWNr ZXIgaGFzIGNvbnRyb2wgb3ZlciBsb2NhbA0KPiA+IEROUzY0LCBOQVQ2NCBhbmQgcm91dGluZyBz ZXJ2aWNlcw0KPiA+IC0gSG9zdCBwZXJmb3JtcyBBQUFBIHF1ZXJ5IGZvciB0aGUgd2VsbC1rbm93 biBuYW1lLCB3aGljaCBpcyByZXBsaWVkDQo+IGJ5DQo+ID4gYXR0YWNrZXIncyBETlM2NCB1c2lu ZyBuZXR3b3JrIEEncyBQcmVmNjQ6Oi9uDQo+ID4gLSBIb3N0IHBlcmZvcm1zIHJldmVyc2UgcXVl cnkgdG8gZmluZCB0aGUgRlFETiBmb3IgdGhlIHByZWZpeCwgYW5kDQo+ID4gZmluZCdzIG5ldHdv cmsgQSdzIE5BVDY0J3MgRlFETiAoYXR0YWNrZXIgbm90IGludm9sdmVkIGluIHRoaXMgcXVlcnkp DQo+ID4gLSBIb3N0IHBlcmZvcm1zIGZvcndhcmQgcXVlcnkgZm9yIHRoZSBsZWFybmVkIG5hbWUs IHZhbGlkYXRlcyByZXNwb25zZQ0KPiA+IHdpdGggRE5TU0VDLCBhbmQgZ2V0cyB0aGUgc2FtZSBQ cmVmNjQ6Oi9uIGFzIGl0IGdvdCBvcmlnaW5hbGx5IGZvciB0aGUNCj4gPiB3ZWxsLWtub3duIG5h bWUgKGF0dGFja2VyIG5vdCBpbnZvbHZlZCBpbiB0aGlzIHF1ZXJ5KQ0KPiA+IC0gSG9zdCB0aGlu a3MgaXQgaGFzIGxlYXJuZWQgUHJlZjY0OjovbiBzYWZlbHkNCj4gPg0KPiA+IEV4Y2VwdCB0aGF0 IHRoZSBob3N0IGhhcyBub3QsIGJlY2F1c2UgZXZlbiB0aG91Z2ggdGhlIGRpc2NvdmVyZWQNCj4g PiBQcmVmNjQ6Oi9uIHdhcyBtYXRjaGluZyB0aGUgTkFUNjQgRlFETiBhbmQgYWxsIHRoYXQganVz dCBmaW5lLCB0aGUNCj4gaG9zdA0KPiA+IGlzIGluIGEgbmV0d29yayBCIHRoYXQgc2hvdWxkIG5v dCBiZSB1c2luZyB0aGUgbmV0d29yayBBJ3MgUHJlZjY0Ojovbg0KPiA+IGFuZCBoZW5jZSBhbGwg aG9zdCdzIHBhY2tldHMgY291bGQgYmUgcm91dGVkIHRvIG5ldHdvcmsgQidzIE5BVDY0DQo+IHVu ZGVyDQo+ID4gY29udHJvbCBvZiBhdHRhY2tlciAoaW5zdGVhZCBvZiBOQVQ2NCBvZiBuZXR3b3Jr IEEgLSByZW1lbWJlciBhdHRhY2tlcg0KPiA+IGhhcyB0YWtlbiBvdmVyIHJvdXRpbmcgdG8gUHJl ZjY0OjovbikuDQo+DQo+IElzIHNvdW5kcyB2ZXJ5IGVhc3kgdG8gY2lyY3VtdmVudCB0aGUgc2Vj dXJpdHkgaW4gdGhlIHByb3Bvc2VkIGRpc2NvdmVyeQ0KPiBhbGdvcml0aG0gaW4gdGhhdCBjYXNl Lg0KPiBXaHkgd291bGQgdGhlIGF0dGFja2VyIHVzZSBBJ3MgUHJlZjY0OjovbiB3aHkgY291bGRu J3QgaGUganVzdCB1c2UgaGlzDQo+IG93biBQZXJmNjQ6Oi9uIGFuZCBpbnNlcnQgdGhlIGFwcHJv cHJpYXRlIHJlY29yZHMgaW50byBETlM/DQo+DQo+IC9TdGVwaGFuDQo+DQoNCg== --_000_1327959645260965camelNokiaN900_ Content-Type: text/html; charset="utf-8" Content-ID: <1327959645.26096.4.camel@Nokia-N900> Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMDEgVHJhbnNpdGlvbmFs Ly9FTiIgImh0dHA6Ly93d3cudzMub3JnL1RSL2h0bWw0L2xvb3NlLmR0ZCI+DQo8aHRtbD4NCjxo ZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7 IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0iZ2VuZXJhdG9yIiBjb250ZW50PSJPc3NvIE5v dGVzIj4NCjx0aXRsZT48L3RpdGxlPg0KPC9oZWFkPg0KPGJvZHk+DQo8cD5Gb3IgYXR0YWNrZXIg dG8gdXNlIG93biBQcmVmNjQ6Oi9uIHRoZSBhdHRhY2tlciB3b3VsZCBuZWVkIHRvIGJlIGFibGUg dG8gc2lnbiB0aGUgcmVxdWlyZWQgRE5TIHJlY29yZHMgaW4gYSB3YXkgdGhhdCB2YWxpZGF0aW5n IGhvc3QgYWNjZXB0cyB0aGVtLiBJbiB0aGF0IGNhc2UgdGhlIGF0dGFja2VyIHdvdWxkIGFwcGVh ciB0byBiZSBhcyBsZWdpdGltYXRlIGFzIGFueSBJU1AuDQo8YnI+DQo8YnI+DQpJJ20gd29uZGVy aW5nIGlmIHRoZSBhdHRhY2sgSSBkZXNjcmliZWQgaXMgYWN0dWFsbHkgc29tZXRoaW5nIHdlIG5l ZWQgdG8gYWRkcmVzcz8gSSBtZWFuIGlmIHRoZSBhdHRhY2tlciBjb250cm9scyBETlMoNjQpIGEg aG9zdCBpcyB1c2luZyBhbmQgcm91dGluZyBvbiB0aGUgYWNjZXNzIG5ldHdvcmsgdGhlIGhvc3Qg aXMgYXR0YWNoZWQgdG8sIHRoZSBhdHRhY2tlciBjYW4gY2F1c2UgcHJvYmxlbXMgYW55d2F5IChp bmNsdWRpbmcgdG8gdGhlIHRyYWZmaWMNCiB1c2luZyBub24tc3ludGhldGljIGFkZHJlc3Nlcyku IDxicj4NCjxicj4NCklmIHdlIGFncmVlIHdlIGRvIG5vdCBhZHJlc3MgdGhpcyBhdHRhY2ssIHdl IGNvdWxkIGRyb3AgdGhlIHNwbGl0IEROUyB0ZXh0LiA8YnI+DQo8YnI+DQpUZWVtdSA8YnI+DQo8 YnI+DQotLS0tLSBPcmlnaW5hbCBtZXNzYWdlIC0tLS0tIDxicj4NCiZndDsgSGkgVGVlbXUsIDxi cj4NCiZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAm Z3Q7IEkgZG9uJ3QgbGlrZSB0aGlzIHJlcXVpcmVtZW50IGJlY2F1c2UgaXQgaXMgZm9yY2luZyB0 aGUgRE5TIHNlcnZlciA8YnI+DQomZ3Q7ICZndDsgdG8gc3VwcG9ydCB2aWV3cy4gQWRkaXRpb25h bGx5LCB5b3Ugd2lsbCBoYXZlIHRvIHVwZGF0ZSB0aGUgPGJyPg0KJmd0OyAmZ3Q7IGF1dGhvcml0 YXRpdmUgRE5TIGV2ZXJ5IHRpbWUgeW91IHN0YXJ0IHByb3Zpc2lvbmluZyB5b3VyIGNsaWVudHMg d2l0aCA8YnI+DQomZ3Q7IG5ldyA8YnI+DQomZ3Q7ICZndDsgYWRkcmVzc2VzIGZyb20gbmV3IElQ djYgbmV0d29ya3MuIDxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IEZh aXIgcG9pbnQuJm5ic3A7IFRlZW11LCBKb3VuaSwgdGhvdWdodHMgb24gdGhpcz8gPGJyPg0KJmd0 OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBUaGUgdGV4dCB3YXMgYXR0ZW1wdGluZyB0byB0YWNrbGUg dGhlIGZvbGxvd2luZyBhdHRhY2s6IDxicj4NCiZndDsgJmd0OyAtIExlZ2l0aW1hdGUgbmV0d29y ayBBIGlzIHVzaW5nIE5BVDY0IGFuZCByZWxhdGVkIGRvbWFpbiBuYW1lcyBhcmUgYWxsIDxicj4N CiZndDsgJmd0OyBzZWN1cmVkIHdpdGggRE5TU0VDIDxicj4NCiZndDsgJmd0OyAtIEhvc3QgaXMg aW4gaG9zdGlsZSBuZXR3b3JrIEIsIHdoZXJlIGF0dGFja2VyIGhhcyBjb250cm9sIG92ZXIgbG9j YWwgPGJyPg0KJmd0OyAmZ3Q7IEROUzY0LCBOQVQ2NCBhbmQgcm91dGluZyBzZXJ2aWNlcyA8YnI+ DQomZ3Q7ICZndDsgLSBIb3N0IHBlcmZvcm1zIEFBQUEgcXVlcnkgZm9yIHRoZSB3ZWxsLWtub3du IG5hbWUsIHdoaWNoIGlzIHJlcGxpZWQgPGJyPg0KJmd0OyBieSA8YnI+DQomZ3Q7ICZndDsgYXR0 YWNrZXIncyBETlM2NCB1c2luZyBuZXR3b3JrIEEncyBQcmVmNjQ6Oi9uIDxicj4NCiZndDsgJmd0 OyAtIEhvc3QgcGVyZm9ybXMgcmV2ZXJzZSBxdWVyeSB0byBmaW5kIHRoZSBGUUROIGZvciB0aGUg cHJlZml4LCBhbmQgPGJyPg0KJmd0OyAmZ3Q7IGZpbmQncyBuZXR3b3JrIEEncyBOQVQ2NCdzIEZR RE4gKGF0dGFja2VyIG5vdCBpbnZvbHZlZCBpbiB0aGlzIHF1ZXJ5KSA8YnI+DQomZ3Q7ICZndDsg LSBIb3N0IHBlcmZvcm1zIGZvcndhcmQgcXVlcnkgZm9yIHRoZSBsZWFybmVkIG5hbWUsIHZhbGlk YXRlcyByZXNwb25zZSA8YnI+DQomZ3Q7ICZndDsgd2l0aCBETlNTRUMsIGFuZCBnZXRzIHRoZSBz YW1lIFByZWY2NDo6L24gYXMgaXQgZ290IG9yaWdpbmFsbHkgZm9yIHRoZSA8YnI+DQomZ3Q7ICZn dDsgd2VsbC1rbm93biBuYW1lIChhdHRhY2tlciBub3QgaW52b2x2ZWQgaW4gdGhpcyBxdWVyeSkg PGJyPg0KJmd0OyAmZ3Q7IC0gSG9zdCB0aGlua3MgaXQgaGFzIGxlYXJuZWQgUHJlZjY0OjovbiBz YWZlbHkgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBFeGNlcHQgdGhhdCB0aGUgaG9z dCBoYXMgbm90LCBiZWNhdXNlIGV2ZW4gdGhvdWdoIHRoZSBkaXNjb3ZlcmVkIDxicj4NCiZndDsg Jmd0OyBQcmVmNjQ6Oi9uIHdhcyBtYXRjaGluZyB0aGUgTkFUNjQgRlFETiBhbmQgYWxsIHRoYXQg anVzdCBmaW5lLCB0aGUgPGJyPg0KJmd0OyBob3N0IDxicj4NCiZndDsgJmd0OyBpcyBpbiBhIG5l dHdvcmsgQiB0aGF0IHNob3VsZCBub3QgYmUgdXNpbmcgdGhlIG5ldHdvcmsgQSdzIFByZWY2NDo6 L24gPGJyPg0KJmd0OyAmZ3Q7IGFuZCBoZW5jZSBhbGwgaG9zdCdzIHBhY2tldHMgY291bGQgYmUg cm91dGVkIHRvIG5ldHdvcmsgQidzIE5BVDY0IDxicj4NCiZndDsgdW5kZXIgPGJyPg0KJmd0OyAm Z3Q7IGNvbnRyb2wgb2YgYXR0YWNrZXIgKGluc3RlYWQgb2YgTkFUNjQgb2YgbmV0d29yayBBIC0g cmVtZW1iZXIgYXR0YWNrZXIgPGJyPg0KJmd0OyAmZ3Q7IGhhcyB0YWtlbiBvdmVyIHJvdXRpbmcg dG8gUHJlZjY0OjovbikuIDxicj4NCiZndDsgPGJyPg0KJmd0OyBJcyBzb3VuZHMgdmVyeSBlYXN5 IHRvIGNpcmN1bXZlbnQgdGhlIHNlY3VyaXR5IGluIHRoZSBwcm9wb3NlZCBkaXNjb3ZlcnkgPGJy Pg0KJmd0OyBhbGdvcml0aG0gaW4gdGhhdCBjYXNlLiA8YnI+DQomZ3Q7IFdoeSB3b3VsZCB0aGUg YXR0YWNrZXIgdXNlIEEncyBQcmVmNjQ6Oi9uIHdoeSBjb3VsZG4ndCBoZSBqdXN0IHVzZSBoaXMg PGJyPg0KJmd0OyBvd24gUGVyZjY0OjovbiBhbmQgaW5zZXJ0IHRoZSBhcHByb3ByaWF0ZSByZWNv cmRzIGludG8gRE5TPyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgL1N0ZXBoYW4gPGJyPg0KJmd0OyA8 YnI+DQo8YnI+DQo8L3A+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_1327959645260965camelNokiaN900_-- From teemu.savolainen@nokia.com Mon Jan 30 13:52: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 9917F21F8693 for ; Mon, 30 Jan 2012 13:52:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.735 X-Spam-Level: X-Spam-Status: No, score=-2.735 tagged_above=-999 required=5 tests=[AWL=-0.137, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a5wfzqp-qv50 for ; Mon, 30 Jan 2012 13:52:33 -0800 (PST) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id E2BE321F8683 for ; Mon, 30 Jan 2012 13:52:32 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-sa02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q0ULqN8w019368; Mon, 30 Jan 2012 23:52:23 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.57]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 30 Jan 2012 23:52:23 +0200 Received: from 008-AM1MPN1-051.mgdnok.nokia.com ([169.254.1.68]) by 008-AM1MMR1-002.mgdnok.nokia.com ([65.54.30.57]) with mapi id 14.01.0355.003; Mon, 30 Jan 2012 22:52:22 +0100 From: To: , Thread-Topic: [BEHAVE] DNSSEC and NAT64 Discovery Heuristic [was RE: I-D Action:draft-ietf-behave-nat64-discovery-heuristic-05.txt] Thread-Index: AczfmXGpNKF1gvkJTIex4K1j/el6lA== Date: Mon, 30 Jan 2012 21:52:21 +0000 Message-ID: <1327960331.26096.11.camel@Nokia-N900> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_13279603312609611camelNokiaN900_" MIME-Version: 1.0 X-OriginalArrivalTime: 30 Jan 2012 21:52:23.0438 (UTC) FILETIME=[72B55AE0:01CCDF99] X-Nokia-AV: Clean Cc: behave@ietf.org Subject: Re: [BEHAVE] DNSSEC and NAT64 Discovery Heuristic [was RE: I-D Action:draft-ietf-behave-nat64-discovery-heuristic-05.txt] X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: teemu.savolainen@nokia.com List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 21:52:35 -0000 --_000_13279603312609611camelNokiaN900_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TWFyaywgd2UgaGF2ZSBldmVuIHByb3RvdHlwZSBpbXBsZW1lbnRhdGlvbiBkb25lIHdpdGggRURO UzAuDQoNCk9uZSBwcm9ibGVtIHdpdGggRUROUzAgaXMgdGhhdCBpdCByZXF1aXJlcyBleHBsaWNp dCBhY2Nlc3MgbmV0d29yayBzdXBwb3J0IHRvIHdvcmssIHdoaWxlIGZvciBnZW5lcmljIE5BVDY0 IGRldGVjdGlvbiB3ZSBjYW5ub3QgYXNzdW1lIGFjY2VzcyBuZXR3b3JrIGlzIGhlbHBpbmcgdXMu IEhlbmNlIGhldXJpc3RpY3MgaXMgdGhlIG9ubHkgb3B0aW9uLg0KDQpOb3cgd2hhdCBjb21lcyB0 byB0aGUgc2VjdXJlIHByZWZpeCBkaXNjb3ZlcnksIGl0IGlzIGtpbmRhIGhhcmQgdG8gZG8gdGhh dCB3aXRob3V0IG5ldHdvcmsgYXNzaXN0YW5jZS4gSGVuY2UgaW50cm9kdWN0aW9uIG9mIEROU1NF QyBpbnRvIHBpY3R1cmUuDQoNClRlZW11DQoNCg0KLS0tLS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0t LQ0KPg0KPiBJbiBtZXNzYWdlIDwyMDEyMDEzMDE1MTA0OC5HQzkxNDc2QHNoaW5rdXJvLmNvbTxt YWlsdG86MjAxMjAxMzAxNTEwNDguR0M5MTQ3NkBzaGlua3Vyby5jb20+PiwgQW5kcmV3IFN1bGxp dmFuDQo+IHdyaXRlczoNCj4gPiBPbiBUdWUsIEphbiAzMSwgMjAxMiBhdCAwMTo1NDowMUFNICsx MTAwLCBNYXJrIEFuZHJld3Mgd3JvdGU6DQo+ID4NCj4gPiA+IEFuZCBDRD0xIHdpbGwgbm90IGhl bHAgd2l0aCB0aGlzIHNlbmFyaW8uICBUaGUgbm9uLXZhbGlkYXRpbmcNCj4gPiA+IHJlc29sdmVy IHdpbGwgY2FjaGUgdGhlIEROUzY0IHRyYW5zbGF0ZWQgcmVzcG9uc2VzIGFuZCB3aWxsIHJldHVy bg0KPiA+ID4gdGhvc2UgdHJhbnNsYXRlZCByZXNwb25zZXMgdG8gRE89MSxDRD0xIHF1ZXJpZXMg d2hpY2ggd2lsbCB0aGVuDQo+ID4gPiBmYWlsIHRvIHZhbGlkYXRlLiAgT3IgaWYgdGhlIERPPTEs Q0Q9MSBxdWVyeSBpcyB0aGUgZmlyc3QgcXVlcnkNCj4gPiA+IHRoZW4gdGhlIG5vbiB2YWxpZGF0 aW5nIHN0dWIgcmVzb2x2ZXJzIHdpbGwgZ2V0IE5PREFUQSByZXNwb25zZXMNCj4gPiA+IHRvIEFB QUEgcXVlcmllcyBpbnN0ZWFkIG9mIHN5bnRoZXNpc2VkIHJlc3BvbnNlcy4NCj4gPg0KPiA+IEFo LCB3YWl0LiAgWW91IGFyZSB3b3JyaWVkIGFib3V0IHRoZSBjYXNlIHdoZXJlIGEgY2FjaGluZw0K PiA+IHNlY3VyaXR5LWF3YXJlIG5vbi12YWxpZGF0aW5nIGRuczY0LW9ibGl2aW91cyByZWN1cnNp dmUgcmVzb2x2ZXIgaXMNCj4gPiBiZWhpbmQgYSBETlM2NCwgYW5kIHByb3ZpZGluZyBzZXJ2aWNl IGZvciBvdGhlciBjbGllbnRzIGluc2lkZSB0aGF0DQo+ID4gbmV0d29yaz8gIFllYWgsIHRoYXQg d29uJ3Qgd29yay4gIFRoZXJlJ3MgYSByYXRoZXIgY2x1bXN5IGFuZA0KPiA+IHRvby1zaG9ydCBk aXNjdXNzaW9uIG9mIHNvbWUgKGJ1dCBub3QgYWxsKSBvZiB0aGVzZSBpc3N1ZXMgaW4gUkZDNjE0 NywNCj4gPiBzZWN0aW9uIDYuDQo+ID4NCj4gPiA+IFB1dCBhIEROUzY0IHJlY3Vyc2l2ZSBzZXJ2 ZXIgKGFzIGRlc2NyaWJlZCBpbiBSRkM2MTQ3KSBpbiBmcm9udCBvZg0KPiA+ID4gYSBub24gdmFs aWRhdGluZyBETz0xIHJlY3Vyc2l2ZSBzZXJ2ZXIgaW4gZnJvbnQgb2YgYSB2YWxpZGF0aW5nDQo+ ID4gPiByZWN1cnNpdmUgc2VydmVyLg0KPiA+DQo+ID4gTm8sIGRvbid0LiAgSXQgd29uJ3Qgd29y ayByZWxpYWJseSwgSSBhZ3JlZS4gIEJhc2ljYWxseSwgaWYgdGhlIEROUzY0DQo+ID4gaXNuJ3Qg dGhlIGxhc3QgaG9wIGJlZm9yZSB0aGUgdmFsaWRhdGlvbiBwb2ludCwgdGhlbiB5b3UncmUgc2Ny ZXdlZC4NCj4NCj4gQW5kIFJGQzYxNDcgZG9lc24ndCBwcm92aWRlIGFueSB3YXkgZm9yIGEgY2Fj aGluZyBzZXJ2ZXIgdG8gbGVhcm4NCj4gdGhlIEROUzY0IHByZWZpeGVzIHRvIGFwcGx5IGZyb20g dXBzdHJlYW0uICBJdCBkb2Vzbid0IHByb3ZpZGUgYQ0KPiBhd2F5IGZvciBhbnN3ZXJzIHRvIERP PTEgcXVlcmllcyBub3QgdG8gYmUgdGFpbnRlZC4NCj4NCj4gVGhlIEVETlMgb3B0aW9uIEkgc3Vn Z2VzdGVkIGVhcmxpZXIgaW4gdGhlIHRocmVhZCB3b3VsZCBiZSBzdWZmaWNpZW50Lg0KPiBNYWlu dGFpbiBhIHJlZmVyZW5jZSBjb3VudGVkIGNhY2hlIG9mIGxlYXJuZWQgcHJlZml4IHNldHMgYW5k IHJlY29yZA0KPiBhIHJlZmVyZW5jZSB0byBpdCB3aXRoIHRoZSBBQUFBIG5vZGF0YSBuZWdhdGl2 ZSBjYWNoZSBlbnRyeS4gIFRoZQ0KPiBETlM2NCBwcmVmaXhlcyB3b3VsZCB0aW1lb3V0IHdoZW4g dGhlIG5vZGF0YSBuZWdhdGl2ZSBjYWNoZSBlbnRyeQ0KPiB0aW1lcyBvdXQuDQo+DQo+IEFsdGVy bmF0aXZlbHkgd2UgY291bGQgbWFrZSBpdCBtb3JlIGNvbXBsaWNhdGVkIGFuZCBzZW5kIHRoZSBm dWxsDQo+IHBvbGljeSwgY2xpZW50IGFkZHJlc3MgdG8gbWF0Y2ggKElQdjQgYW5kIElQdjYpIGFu ZCBleGNsdXNpb24gYWRkcmVzcw0KPiAoSVB2NCBhbmQgSVB2NikgYW5kIFRUTC4gIFVwc3RyZWFt IHJlcXVlc3RzIHdvdWxkIGluY2x1ZGUgYSAzMiAoNjQ/KQ0KPiBiaXQgaGFzaCBvZiB0aGUgRE5T NjQgcG9saWN5IHNvIHRoYXQgaXQgZG9lc24ndCBoYXZlIHRvIGJlIHRyYW5zbWl0dGVkDQo+IG9u IGV2ZXJ5IEFBQUEgcmVzcG9uc2UuICBTZW5kaW5nIHRoYXQgaGFzaCBpbiB0aGUgcmVzcG9uc2Ug d291bGQNCj4gdXBkYXRlIHRoZSBUVEwgZW50cnkuDQo+DQo+ID4gQXQgdGhlIHNhbWUgdGltZSwg SSdtIGEgbGl0dGxlIGFsYXJtZWQgYXQgdGhlIHByb3NwZWN0IG9mIGNhY2hlcyB0aGF0DQo+ID4g aGFuZCBvdXQgcXVlcmllcyBkaXNjb3ZlcmVkIHdpdGggQ0Q9MCB0byBjbGllbnRzIHF1ZXJ5aW5n IHdpdGggQ0Q9MSwNCj4gPiByZWdhcmRsZXNzIG9mIHdoZXRoZXIgdGhleSBhcmUgYSBETlM2NCBv ciBhIEROUyBzZXJ2ZXIuICBUaGF0IHNob3VsZA0KPiA+IGxpa2VseSBiZSB0YWtlbiB1cCBvbiBh bm90aGVyIGxpc3QsIGhvd2V2ZXIuDQo+DQo+IFdoaWxlIGl0IGlzIGZvZGRlciBmb3IgdGhlIG90 aGVyIGxpc3QsIGl0IGlzbid0IHdyb25nIGFzIHRoZSBSRkMgNDAzNQ0KPiBub3cgc3RhbmRzLiAg QWRkaXRpb25hbGx5IGFza2luZyB1cHN0cmVhbSBhZ2FpbiBvbiBDRD0xIGlzIG5vdA0KPiBzdWZm aWNpZW50DQo+IGFzIHRoZXJlIGlzIG5vIGNvbnRyb2wgb2Ygd2hpY2ggc2VydmVyIGlzIHF1ZXJp ZWQuDQo+DQo+ID4gPiA+IHRoZXJlIGlzIHR3b2ZvbGQuICBGaXJzdCwgc2luY2UgdGhlIG9ubHkg d2F5IHRvIGJlIHN1cmUgeW91IGdldA0KPiBhbGwNCj4gPiA+ID4gdGhlIG5lY2Vzc2FyeSB2YWxp ZGF0aW9uIGRhdGEgaXMgdG8gc2V0IENEPTEsDQo+ID4gPg0KPiA+ID4gTm90IHRydWUuDQo+ID4N Cj4gPiBJIHRoaW5rIHdlIGFyZSBqdXN0IHRhbGtpbmcgd2l0aCBkaWZmZXJlbnQgaW1wbGljaXQg c2NvcGUgaGVyZSwgYnV0DQo+ID4gdGhhdCdzIGEgZ2VuZXJhbCBETlMgaXNzdWUgYW5kIG5vdCwg SSB0aGluaywgYSBzdWJqZWN0IGZvciB0aGlzIGxpc3QuDQo+ID4gSSBiZWxpZXZlIHdoYXQgSSBz YWlkLCBob3dldmVyLCBhbmQgSSB0aGluayBhIGNhcmVmdWwgcmVhZGluZyBvZiBSRkMNCj4gPiA0 MDM1IGJhY2tzIG1lIHVwLg0KPiA+DQo+ID4gQmVzdCwNCj4gPg0KPiA+IEENCj4gPg0KPiA+IC0t DQo+ID4gQW5kcmV3IFN1bGxpdmFuDQo+ID4gYWpzQGFudmlsd2FscnVzZGVuLmNvbTxtYWlsdG86 YWpzQGFudmlsd2FscnVzZGVuLmNvbT4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiA+IEJlaGF2ZSBtYWlsaW5nIGxpc3QNCj4gPiBCZWhhdmVA aWV0Zi5vcmc8bWFpbHRvOkJlaGF2ZUBpZXRmLm9yZz4NCj4gPiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2JlaGF2ZQ0KPiAtLQ0KPiBNYXJrIEFuZHJld3MsIElTQw0KPiAx IFNleW1vdXIgU3QuLCBEdW5kYXMgVmFsbGV5LCBOU1cgMjExNywgQXVzdHJhbGlhDQo+IFBIT05F OiArNjEgMiA5ODcxIDQ3NDIgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIElOVEVSTkVU OiBtYXJrYUBpc2Mub3JnPG1haWx0bzptYXJrYUBpc2Mub3JnPg0KPiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBCZWhhdmUgbWFpbGluZyBsaXN0DQo+ IEJlaGF2ZUBpZXRmLm9yZzxtYWlsdG86QmVoYXZlQGlldGYub3JnPg0KPiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2JlaGF2ZQ0KPg0KDQo= --_000_13279603312609611camelNokiaN900_ Content-Type: text/html; charset="utf-8" Content-ID: <1327960330.26096.10.camel@Nokia-N900> Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMDEgVHJhbnNpdGlvbmFs Ly9FTiIgImh0dHA6Ly93d3cudzMub3JnL1RSL2h0bWw0L2xvb3NlLmR0ZCI+DQo8aHRtbD4NCjxo ZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7 IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0iZ2VuZXJhdG9yIiBjb250ZW50PSJPc3NvIE5v dGVzIj4NCjx0aXRsZT48L3RpdGxlPg0KPC9oZWFkPg0KPGJvZHk+DQo8cD5NYXJrLCB3ZSBoYXZl IGV2ZW4gcHJvdG90eXBlIGltcGxlbWVudGF0aW9uIGRvbmUgd2l0aCBFRE5TMC4gPGJyPg0KPGJy Pg0KT25lIHByb2JsZW0gd2l0aCBFRE5TMCBpcyB0aGF0IGl0IHJlcXVpcmVzIGV4cGxpY2l0IGFj Y2VzcyBuZXR3b3JrIHN1cHBvcnQgdG8gd29yaywgd2hpbGUgZm9yIGdlbmVyaWMgTkFUNjQgZGV0 ZWN0aW9uIHdlIGNhbm5vdCBhc3N1bWUgYWNjZXNzIG5ldHdvcmsgaXMgaGVscGluZyB1cy4gSGVu Y2UgaGV1cmlzdGljcyBpcyB0aGUgb25seSBvcHRpb24uDQo8YnI+DQo8YnI+DQpOb3cgd2hhdCBj b21lcyB0byB0aGUgc2VjdXJlIHByZWZpeCBkaXNjb3ZlcnksIGl0IGlzIGtpbmRhIGhhcmQgdG8g ZG8gdGhhdCB3aXRob3V0IG5ldHdvcmsgYXNzaXN0YW5jZS4gSGVuY2UgaW50cm9kdWN0aW9uIG9m IEROU1NFQyBpbnRvIHBpY3R1cmUuDQo8YnI+DQo8YnI+DQpUZWVtdSA8YnI+DQo8YnI+DQo8YnI+ DQotLS0tLSBPcmlnaW5hbCBtZXNzYWdlIC0tLS0tIDxicj4NCiZndDsgPGJyPg0KJmd0OyBJbiBt ZXNzYWdlICZsdDs8YSBocmVmPSJtYWlsdG86MjAxMjAxMzAxNTEwNDguR0M5MTQ3NkBzaGlua3Vy by5jb20iPjIwMTIwMTMwMTUxMDQ4LkdDOTE0NzZAc2hpbmt1cm8uY29tPC9hPiZndDssIEFuZHJl dyBTdWxsaXZhbg0KPGJyPg0KJmd0OyB3cml0ZXM6IDxicj4NCiZndDsgJmd0OyBPbiBUdWUsIEph biAzMSwgMjAxMiBhdCAwMTo1NDowMUFNICYjNDM7MTEwMCwgTWFyayBBbmRyZXdzIHdyb3RlOiA8 YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgQW5kIENEPTEgd2lsbCBub3QgaGVs cCB3aXRoIHRoaXMgc2VuYXJpby4mbmJzcDsgVGhlIG5vbi12YWxpZGF0aW5nIDxicj4NCiZndDsg Jmd0OyAmZ3Q7IHJlc29sdmVyIHdpbGwgY2FjaGUgdGhlIEROUzY0IHRyYW5zbGF0ZWQgcmVzcG9u c2VzIGFuZCB3aWxsIHJldHVybiA8YnI+DQomZ3Q7ICZndDsgJmd0OyB0aG9zZSB0cmFuc2xhdGVk IHJlc3BvbnNlcyB0byBETz0xLENEPTEgcXVlcmllcyB3aGljaCB3aWxsIHRoZW4gPGJyPg0KJmd0 OyAmZ3Q7ICZndDsgZmFpbCB0byB2YWxpZGF0ZS4mbmJzcDsgT3IgaWYgdGhlIERPPTEsQ0Q9MSBx dWVyeSBpcyB0aGUgZmlyc3QgcXVlcnkgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgdGhlbiB0aGUgbm9u IHZhbGlkYXRpbmcgc3R1YiByZXNvbHZlcnMgd2lsbCBnZXQgTk9EQVRBIHJlc3BvbnNlcyA8YnI+ DQomZ3Q7ICZndDsgJmd0OyB0byBBQUFBIHF1ZXJpZXMgaW5zdGVhZCBvZiBzeW50aGVzaXNlZCBy ZXNwb25zZXMuIDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgQWgsIHdhaXQuJm5ic3A7 IFlvdSBhcmUgd29ycmllZCBhYm91dCB0aGUgY2FzZSB3aGVyZSBhIGNhY2hpbmcgPGJyPg0KJmd0 OyAmZ3Q7IHNlY3VyaXR5LWF3YXJlIG5vbi12YWxpZGF0aW5nIGRuczY0LW9ibGl2aW91cyByZWN1 cnNpdmUgcmVzb2x2ZXIgaXMgPGJyPg0KJmd0OyAmZ3Q7IGJlaGluZCBhIEROUzY0LCBhbmQgcHJv dmlkaW5nIHNlcnZpY2UgZm9yIG90aGVyIGNsaWVudHMgaW5zaWRlIHRoYXQgPGJyPg0KJmd0OyAm Z3Q7IG5ldHdvcms/Jm5ic3A7IFllYWgsIHRoYXQgd29uJ3Qgd29yay4mbmJzcDsgVGhlcmUncyBh IHJhdGhlciBjbHVtc3kgYW5kIDxicj4NCiZndDsgJmd0OyB0b28tc2hvcnQgZGlzY3Vzc2lvbiBv ZiBzb21lIChidXQgbm90IGFsbCkgb2YgdGhlc2UgaXNzdWVzIGluIFJGQzYxNDcsIDxicj4NCiZn dDsgJmd0OyBzZWN0aW9uIDYuIDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBQ dXQgYSBETlM2NCByZWN1cnNpdmUgc2VydmVyIChhcyBkZXNjcmliZWQgaW4gUkZDNjE0NykgaW4g ZnJvbnQgb2YgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgYSBub24gdmFsaWRhdGluZyBETz0xIHJlY3Vy c2l2ZSBzZXJ2ZXIgaW4gZnJvbnQgb2YgYSB2YWxpZGF0aW5nIDxicj4NCiZndDsgJmd0OyAmZ3Q7 IHJlY3Vyc2l2ZSBzZXJ2ZXIuIDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgTm8sIGRv bid0LiZuYnNwOyBJdCB3b24ndCB3b3JrIHJlbGlhYmx5LCBJIGFncmVlLiZuYnNwOyBCYXNpY2Fs bHksIGlmIHRoZSBETlM2NCA8YnI+DQomZ3Q7ICZndDsgaXNuJ3QgdGhlIGxhc3QgaG9wIGJlZm9y ZSB0aGUgdmFsaWRhdGlvbiBwb2ludCwgdGhlbiB5b3UncmUgc2NyZXdlZC4gPGJyPg0KJmd0OyA8 YnI+DQomZ3Q7IEFuZCBSRkM2MTQ3IGRvZXNuJ3QgcHJvdmlkZSBhbnkgd2F5IGZvciBhIGNhY2hp bmcgc2VydmVyIHRvIGxlYXJuIDxicj4NCiZndDsgdGhlIEROUzY0IHByZWZpeGVzIHRvIGFwcGx5 IGZyb20gdXBzdHJlYW0uJm5ic3A7IEl0IGRvZXNuJ3QgcHJvdmlkZSBhIDxicj4NCiZndDsgYXdh eSBmb3IgYW5zd2VycyB0byBETz0xIHF1ZXJpZXMgbm90IHRvIGJlIHRhaW50ZWQuIDxicj4NCiZn dDsgPGJyPg0KJmd0OyBUaGUgRUROUyBvcHRpb24gSSBzdWdnZXN0ZWQgZWFybGllciBpbiB0aGUg dGhyZWFkIHdvdWxkIGJlIHN1ZmZpY2llbnQuIDxicj4NCiZndDsgTWFpbnRhaW4gYSByZWZlcmVu Y2UgY291bnRlZCBjYWNoZSBvZiBsZWFybmVkIHByZWZpeCBzZXRzIGFuZCByZWNvcmQgPGJyPg0K Jmd0OyBhIHJlZmVyZW5jZSB0byBpdCB3aXRoIHRoZSBBQUFBIG5vZGF0YSBuZWdhdGl2ZSBjYWNo ZSBlbnRyeS4mbmJzcDsgVGhlIDxicj4NCiZndDsgRE5TNjQgcHJlZml4ZXMgd291bGQgdGltZW91 dCB3aGVuIHRoZSBub2RhdGEgbmVnYXRpdmUgY2FjaGUgZW50cnkgPGJyPg0KJmd0OyB0aW1lcyBv dXQuIDxicj4NCiZndDsgPGJyPg0KJmd0OyBBbHRlcm5hdGl2ZWx5IHdlIGNvdWxkIG1ha2UgaXQg bW9yZSBjb21wbGljYXRlZCBhbmQgc2VuZCB0aGUgZnVsbCA8YnI+DQomZ3Q7IHBvbGljeSwgY2xp ZW50IGFkZHJlc3MgdG8gbWF0Y2ggKElQdjQgYW5kIElQdjYpIGFuZCBleGNsdXNpb24gYWRkcmVz cyA8YnI+DQomZ3Q7IChJUHY0IGFuZCBJUHY2KSBhbmQgVFRMLiZuYnNwOyBVcHN0cmVhbSByZXF1 ZXN0cyB3b3VsZCBpbmNsdWRlIGEgMzIgKDY0PykgPGJyPg0KJmd0OyBiaXQgaGFzaCBvZiB0aGUg RE5TNjQgcG9saWN5IHNvIHRoYXQgaXQgZG9lc24ndCBoYXZlIHRvIGJlIHRyYW5zbWl0dGVkIDxi cj4NCiZndDsgb24gZXZlcnkgQUFBQSByZXNwb25zZS4mbmJzcDsgU2VuZGluZyB0aGF0IGhhc2gg aW4gdGhlIHJlc3BvbnNlIHdvdWxkIDxicj4NCiZndDsgdXBkYXRlIHRoZSBUVEwgZW50cnkuIDxi cj4NCiZndDsgPGJyPg0KJmd0OyAmZ3Q7IEF0IHRoZSBzYW1lIHRpbWUsIEknbSBhIGxpdHRsZSBh bGFybWVkIGF0IHRoZSBwcm9zcGVjdCBvZiBjYWNoZXMgdGhhdCA8YnI+DQomZ3Q7ICZndDsgaGFu ZCBvdXQgcXVlcmllcyBkaXNjb3ZlcmVkIHdpdGggQ0Q9MCB0byBjbGllbnRzIHF1ZXJ5aW5nIHdp dGggQ0Q9MSwgPGJyPg0KJmd0OyAmZ3Q7IHJlZ2FyZGxlc3Mgb2Ygd2hldGhlciB0aGV5IGFyZSBh IEROUzY0IG9yIGEgRE5TIHNlcnZlci4mbmJzcDsgVGhhdCBzaG91bGQgPGJyPg0KJmd0OyAmZ3Q7 IGxpa2VseSBiZSB0YWtlbiB1cCBvbiBhbm90aGVyIGxpc3QsIGhvd2V2ZXIuIDxicj4NCiZndDsg PGJyPg0KJmd0OyBXaGlsZSBpdCBpcyBmb2RkZXIgZm9yIHRoZSBvdGhlciBsaXN0LCBpdCBpc24n dCB3cm9uZyBhcyB0aGUgUkZDIDQwMzUgPGJyPg0KJmd0OyBub3cgc3RhbmRzLiZuYnNwOyBBZGRp dGlvbmFsbHkgYXNraW5nIHVwc3RyZWFtIGFnYWluIG9uIENEPTEgaXMgbm90IDxicj4NCiZndDsg c3VmZmljaWVudCA8YnI+DQomZ3Q7IGFzIHRoZXJlIGlzIG5vIGNvbnRyb2wgb2Ygd2hpY2ggc2Vy dmVyIGlzIHF1ZXJpZWQuIDxicj4NCiZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyB0aGVy ZSBpcyB0d29mb2xkLiZuYnNwOyBGaXJzdCwgc2luY2UgdGhlIG9ubHkgd2F5IHRvIGJlIHN1cmUg eW91IGdldCA8YnI+DQomZ3Q7IGFsbCA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IHRoZSBuZWNl c3NhcnkgdmFsaWRhdGlvbiBkYXRhIGlzIHRvIHNldCBDRD0xLCA8YnI+DQomZ3Q7ICZndDsgJmd0 OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBOb3QgdHJ1ZS4gPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZn dDsgJmd0OyBJIHRoaW5rIHdlIGFyZSBqdXN0IHRhbGtpbmcgd2l0aCBkaWZmZXJlbnQgaW1wbGlj aXQgc2NvcGUgaGVyZSwgYnV0IDxicj4NCiZndDsgJmd0OyB0aGF0J3MgYSBnZW5lcmFsIEROUyBp c3N1ZSBhbmQgbm90LCBJIHRoaW5rLCBhIHN1YmplY3QgZm9yIHRoaXMgbGlzdC4gPGJyPg0KJmd0 OyAmZ3Q7IEkgYmVsaWV2ZSB3aGF0IEkgc2FpZCwgaG93ZXZlciwgYW5kIEkgdGhpbmsgYSBjYXJl ZnVsIHJlYWRpbmcgb2YgUkZDIDxicj4NCiZndDsgJmd0OyA0MDM1IGJhY2tzIG1lIHVwLiA8YnI+ DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IEJlc3QsIDxicj4NCiZndDsgJmd0OyA8YnI+DQom Z3Q7ICZndDsgQSA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IC0tIDxicj4NCiZndDsg Jmd0OyBBbmRyZXcgU3VsbGl2YW4gPGJyPg0KJmd0OyAmZ3Q7IDxhIGhyZWY9Im1haWx0bzphanNA YW52aWx3YWxydXNkZW4uY29tIj5hanNAYW52aWx3YWxydXNkZW4uY29tPC9hPiA8YnI+DQomZ3Q7 ICZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gPGJy Pg0KJmd0OyAmZ3Q7IEJlaGF2ZSBtYWlsaW5nIGxpc3QgPGJyPg0KJmd0OyAmZ3Q7IDxhIGhyZWY9 Im1haWx0bzpCZWhhdmVAaWV0Zi5vcmciPkJlaGF2ZUBpZXRmLm9yZzwvYT4gPGJyPg0KJmd0OyAm Z3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYmVoYXZl Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2JlaGF2ZTwvYT4NCjxicj4N CiZndDsgLS0gPGJyPg0KJmd0OyBNYXJrIEFuZHJld3MsIElTQyA8YnI+DQomZ3Q7IDEgU2V5bW91 ciBTdC4sIER1bmRhcyBWYWxsZXksIE5TVyAyMTE3LCBBdXN0cmFsaWEgPGJyPg0KJmd0OyBQSE9O RTogJiM0Mzs2MSAyIDk4NzEgNDc0MiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyBJTlRFUk5FVDogPGEgaHJlZj0ibWFpbHRvOm1hcmthQGlzYy5v cmciPg0KbWFya2FAaXNjLm9yZzwvYT4gPGJyPg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXyA8YnI+DQomZ3Q7IEJlaGF2ZSBtYWlsaW5nIGxpc3Qg PGJyPg0KJmd0OyA8YSBocmVmPSJtYWlsdG86QmVoYXZlQGlldGYub3JnIj5CZWhhdmVAaWV0Zi5v cmc8L2E+IDxicj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9iZWhhdmUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYmVo YXZlPC9hPg0KPGJyPg0KJmd0OyA8YnI+DQo8YnI+DQo8L3A+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_13279603312609611camelNokiaN900_-- From dwing@cisco.com Mon Jan 30 14:53: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 8F4B021F8787 for ; Mon, 30 Jan 2012 14:53:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.564 X-Spam-Level: X-Spam-Status: No, score=-106.564 tagged_above=-999 required=5 tests=[AWL=0.035, 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 abtpyxmAeRf7 for ; Mon, 30 Jan 2012 14:53:06 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 55BEC21F8786 for ; Mon, 30 Jan 2012 14:53:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1327; q=dns/txt; s=iport; t=1327963986; x=1329173586; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=AHHYO/Qs1L5qs74EplpTTvqfJsOTozP1vdOxNNg48Q0=; b=X003tTAn/G1quIj2dwfZAprcbBgAi181a5OiocJ4Q/wC5DgHMPn/j756 iKnS8IbmoUirLm83193/zSLE8p2m70p0vSYTybkgFG8V1olwJGP436EZN 1kMofwo6sUXtIoP3JOKlbxJNzEU69HJjMU2Iy7jjnZcMdrPAwVB7RZNw+ Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAE4eJ0+rRDoG/2dsb2JhbABDn2eOcIEFgXIBAQEECAoBFxAzDAwBAwIJDwIEAQEkBAcZIwoJCAIEARILF4djmiMBnj6KfwEpDAEBCQQUCw8GBIQOAhKDWASIP4UEmkk X-IronPort-AV: E=Sophos;i="4.71,592,1320624000"; d="scan'208";a="27693016" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 30 Jan 2012 22:53:04 +0000 Received: from dwingWS ([10.32.240.198]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q0UMr4vj008104; Mon, 30 Jan 2012 22:53:04 GMT From: "Dan Wing" To: "'Stephan Lagerholm'" , References: <916CE6CF87173740BC8A2CE443096962042B6DB0@008-AM1MPN1-053.mgdnok.nokia.com><916CE6CF87173740BC8A2CE443096962042C1ADE@008-AM1MPN1-053.mgdnok.nokia.com><158001ccdd17$d8c00170$8a400450$@com><916CE6CF87173740BC8A2CE443096962042CAF87@008-AM1MPN1-051.mgdnok.nokia.com> <050401ccdf89$271fa280$755ee780$@com> In-Reply-To: Date: Mon, 30 Jan 2012 14:53:04 -0800 Message-ID: <060901ccdfa1$ecd284d0$c6778e70$@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: AQHM3RfdVEdgOoBqgki3VCG9yLTfQ5Yk1odwgAB5pHCAAATNYIAAFFCggAAenwA= Content-Language: en-us Cc: behave@ietf.org Subject: Re: [BEHAVE] DNSSEC and NAT64 Discovery Heuristic [was RE: I-DAction: draft-ietf-behave-nat64-discovery-heuristic-05.txt] X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 22:53:07 -0000 > -----Original Message----- > From: Stephan Lagerholm [mailto:stephan.lagerholm@secure64.com] > Sent: Monday, January 30, 2012 1:03 PM > To: Dan Wing; teemu.savolainen@nokia.com > Cc: behave@ietf.org > Subject: RE: [BEHAVE] DNSSEC and NAT64 Discovery Heuristic [was RE: I- > DAction: draft-ietf-behave-nat64-discovery-heuristic-05.txt] > > > > > The host needs to be configured with the domain names of the NAT64 > > devices it will trust -- for example, if I get my Internet service > > from Comcast, I would configure my host to allow a name of > > *.comcast.net for the NAT64. > > Thanks, that make sense but it raises another question: If you > already know that you are in example.net (or Comcast.net in your > example). They why couldn't you just ask for > what-is-my-prefix.example.net, > what-is-my-prefixlength.example.net, > what-is-my-suffix.example.net ? > Those could be signed with DNSSEC. That sounds like a much simpler way > of learning the prefixes. It won't always work. In my own home, for example, I override my ISP's DNS search list to one of my personal domains. Thus, if we only query .example.net, it would fail in those instances. Querying ipv6only.arpa would always work in those cases. DNSSEC validation is intended to be optional. -d From dwing@cisco.com Mon Jan 30 15:01: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 CEA8121F87B0 for ; Mon, 30 Jan 2012 15:01:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.565 X-Spam-Level: X-Spam-Status: No, score=-106.565 tagged_above=-999 required=5 tests=[AWL=0.034, 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 8nYumqe4+jf2 for ; Mon, 30 Jan 2012 15:01:13 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 4B47721F87AD for ; Mon, 30 Jan 2012 15:01:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=3099; q=dns/txt; s=iport; t=1327964473; x=1329174073; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=/7+8c2u29IO0ND3tEF5fntEMrIc/neVAEDbjdp4+b1Y=; b=e6f7OtiyDdxfN8ORKF+N+IhEO3/eYJmHGtGt6TIp+W2B387C+06Sqwbu sGCpLvYO4XZ1K/Q3mKxHi9OeOopv5yVdhE5KI3O+LR5YM0dt6/fSHmf70 cW876295z+mBdifeU24rQOd05+UjCDr7UvAq9ddyEUu5D5MpLg/OFA7AH s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAJIgJ0+rRDoJ/2dsb2JhbABCAYULmlyOcIEFgXIBAQEDAQgKARAHTwUHAQMCCQ8CBAEBAwIVAggEAwICGSMKCQgBAQQBEgsXh1qaLwGMYZFdgS+JUAEpDAEBCQQUCw8KhA4CEk0BgXSBFgSIP4UEmkk X-IronPort-AV: E=Sophos;i="4.71,592,1320624000"; d="scan'208";a="27861276" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 30 Jan 2012 23:01:10 +0000 Received: from dwingWS ([10.32.240.198]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q0UN19jd026785; Mon, 30 Jan 2012 23:01:09 GMT From: "Dan Wing" To: , References: <1327959645.26096.5.camel@Nokia-N900> In-Reply-To: <1327959645.26096.5.camel@Nokia-N900> Date: Mon, 30 Jan 2012 15:01:09 -0800 Message-ID: <062001ccdfa3$0e3c7c10$2ab57430$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Aczfl9dEBwZTR95UR7u2s02Jg9Qn6AACsv3w Content-Language: en-us Cc: behave@ietf.org Subject: Re: [BEHAVE] DNSSEC and NAT64 Discovery Heuristic [was RE: I-D Action: draft-ietf-behave-nat64-discovery-heuristic-05.txt] X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 23:01:13 -0000 > -----Original Message----- > From: teemu.savolainen@nokia.com [mailto:teemu.savolainen@nokia.com] > Sent: Monday, January 30, 2012 1:41 PM > To: stephan.lagerholm@secure64.com; dwing@cisco.com > Cc: behave@ietf.org > Subject: RE: DNSSEC and NAT64 Discovery Heuristic [was RE: [BEHAVE] I-D > Action: draft-ietf-behave-nat64-discovery-heuristic-05.txt] > > For attacker to use own Pref64::/n the attacker would need to be able > to sign the required DNS records in a way that validating host accepts > them. In that case the attacker would appear to be as legitimate as any > ISP. > > I'm wondering if the attack I described is actually something we need > to address? I mean if the attacker controls DNS(64) a host is using and > routing on the access network the host is attached to, the attacker can > cause problems anyway (including to the traffic using non-synthetic > addresses). That attack (manipulation of DNS) is prevented by host DNSSEC. > If we agree we do not adress this attack, we could drop the split DNS > text. -d > Teemu > > ----- Original message ----- > > Hi Teemu, > > > > > > > > > > > > I don't like this requirement because it is forcing the DNS > server > > > to support views. Additionally, you will have to update the > > > authoritative DNS every time you start provisioning your clients > with > > new > > > addresses from new IPv6 networks. > > > > > > > > Fair point. Teemu, Jouni, thoughts on this? > > > > > > The text was attempting to tackle the following attack: > > > - Legitimate network A is using NAT64 and related domain names are > all > > > secured with DNSSEC > > > - Host is in hostile network B, where attacker has control over > local > > > DNS64, NAT64 and routing services > > > - Host performs AAAA query for the well-known name, which is > replied > > by > > > attacker's DNS64 using network A's Pref64::/n > > > - Host performs reverse query to find the FQDN for the prefix, and > > > find's network A's NAT64's FQDN (attacker not involved in this > query) > > > - Host performs forward query for the learned name, validates > response > > > with DNSSEC, and gets the same Pref64::/n as it got originally for > the > > > well-known name (attacker not involved in this query) > > > - Host thinks it has learned Pref64::/n safely > > > > > > Except that the host has not, because even though the discovered > > > Pref64::/n was matching the NAT64 FQDN and all that just fine, the > > host > > > is in a network B that should not be using the network A's > Pref64::/n > > > and hence all host's packets could be routed to network B's NAT64 > > under > > > control of attacker (instead of NAT64 of network A - remember > attacker > > > has taken over routing to Pref64::/n). > > > > Is sounds very easy to circumvent the security in the proposed > discovery > > algorithm in that case. > > Why would the attacker use A's Pref64::/n why couldn't he just use > his > > own Perf64::/n and insert the appropriate records into DNS? > > > > /Stephan > > > > From stephan.lagerholm@secure64.com Mon Jan 30 17:51: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 EE6AC11E80D9 for ; Mon, 30 Jan 2012 17:51:39 -0800 (PST) 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=[AWL=0.000, 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 GTfXyufSWyMT for ; Mon, 30 Jan 2012 17:51:39 -0800 (PST) Received: from zimbra.secure64.com (unknown [64.92.221.189]) by ietfa.amsl.com (Postfix) with ESMTP id 29C1511E80E9 for ; Mon, 30 Jan 2012 17:51:39 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.secure64.com (Postfix) with ESMTP id 7312DB8497; Mon, 30 Jan 2012 18:51:37 -0700 (MST) 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 bke+t-OFP+wU; Mon, 30 Jan 2012 18:51:36 -0700 (MST) Received: from exchange.secure64.com (exchange.secure64.com [192.168.254.250]) by zimbra.secure64.com (Postfix) with ESMTPSA id 3B447B8470; Mon, 30 Jan 2012 18:51:36 -0700 (MST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=secure64.com; s=2010; t=1327974696; bh=xSTfCUUlyI56PeCk3p/KEwZuJndpWpUa7Te8w2rRcm0=; h=MIME-Version:Content-Type:Content-Transfer-Encoding:Subject:Date: Message-ID:In-Reply-To:References:From:To:Cc; b=lWrsKAMFcPiNFeg2Hh 6yTzNz9pHRemEiq4chrZ92UNbA/HjNpGwlG0mEpUjURvVSk96mH7PJLFfsR4nToSqf8 DvwK0vo3gCe3JeguozZ3a19D9Rm5EtzjXtVbqaZhJOpa2G1PZZ7TDFMkCdsqas38zuc UrTH6JYPx78GoSb+aSA= Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 30 Jan 2012 18:51:34 -0700 Message-ID: In-Reply-To: <060901ccdfa1$ecd284d0$c6778e70$@com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] DNSSEC and NAT64 Discovery Heuristic [was RE: I-DAction: draft-ietf-behave-nat64-discovery-heuristic-05.txt] Thread-Index: AQHM3RfdVEdgOoBqgki3VCG9yLTfQ5Yk1odwgAB5pHCAAATNYIAAFFCggAAenwCAADJKAA== References: <916CE6CF87173740BC8A2CE443096962042B6DB0@008-AM1MPN1-053.mgdnok.nokia.com><916CE6CF87173740BC8A2CE443096962042C1ADE@008-AM1MPN1-053.mgdnok.nokia.com><158001ccdd17$d8c00170$8a400450$@com><916CE6CF87173740BC8A2CE443096962042CAF87@008-AM1MPN1-051.mgdnok.nokia.com> <050401ccdf89$271fa280$755ee780$@com> <060901ccdfa1$ecd284d0$c6778e70$@com> From: "Stephan Lagerholm" To: "Dan Wing" , Cc: behave@ietf.org Subject: Re: [BEHAVE] DNSSEC and NAT64 Discovery Heuristic [was RE: I-DAction: draft-ietf-behave-nat64-discovery-heuristic-05.txt] X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 01:51:40 -0000 > > > > > > The host needs to be configured with the domain names of the NAT64 > > > devices it will trust -- for example, if I get my Internet service > > > from Comcast, I would configure my host to allow a name of > > > *.comcast.net for the NAT64. > > > > Thanks, that make sense but it raises another question: If you > > already know that you are in example.net (or Comcast.net in your > > example). They why couldn't you just ask for > > what-is-my-prefix.example.net, > > what-is-my-prefixlength.example.net, > > what-is-my-suffix.example.net ? > > Those could be signed with DNSSEC. That sounds like a much simpler > way > > of learning the prefixes. >=20 > It won't always work. In my own home, for example, I override my > ISP's DNS search list to one of my personal domains. Thus, if > we only query .example.net, it would fail > in those instances. Querying ipv6only.arpa would always work > in those cases. Ok, now I'm confused. You just said that the host needs to be=20 configured with the domain names of the NAT64 it will trust... > DNSSEC validation is intended to be optional. Thanks for clarifying this. You should probably spell that out in=20 the draft. (I was reading it as if DNSSEC were mandatory and that the CD bit was set from all handsets/clients.)=20 From dwing@cisco.com Mon Jan 30 18:17: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 ADB1F21F8712 for ; Mon, 30 Jan 2012 18:17:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.568 X-Spam-Level: X-Spam-Status: No, score=-106.568 tagged_above=-999 required=5 tests=[AWL=0.031, 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 6sPQA9S0Zw-X for ; Mon, 30 Jan 2012 18:17:08 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id C963521F8713 for ; Mon, 30 Jan 2012 18:17:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2271; q=dns/txt; s=iport; t=1327976229; x=1329185829; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=lxeOT65Wekox7m2ez/x4ts2gBQdtPmqPS048SBju6uE=; b=EPovggImr+Q/3KGljvBTzxf8mKkq8LAGGR76NnMbsfZVfq8wQe6aSjql YsfCENWheJGoSq5hF/htnVhTdZ8edXRcR8t7S7WoLncAiUzOnKEK/RaaP znEgsNXM3hrl52sen8OZZ1sDS6FSDYEPV8uCU+YfsyJGsIwYBY88PMEmS c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFABdOJ0+rRDoJ/2dsb2JhbABDn2eOcIEFgXIBAQEDAQgKARcQMwwMAQMCCQ8CBAEBJAQHGSMKCQgCBAESCxeHWgmaQwGeTIp/ASkMAQEJBBQLDwqEDgISg1gEiD+FBJpJ X-IronPort-AV: E=Sophos;i="4.71,592,1320624000"; d="scan'208";a="27885987" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 31 Jan 2012 02:17:08 +0000 Received: from dwingWS ([10.32.240.198]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q0V2H8Nv027869; Tue, 31 Jan 2012 02:17:08 GMT From: "Dan Wing" To: "'Stephan Lagerholm'" , References: <916CE6CF87173740BC8A2CE443096962042B6DB0@008-AM1MPN1-053.mgdnok.nokia.com><916CE6CF87173740BC8A2CE443096962042C1ADE@008-AM1MPN1-053.mgdnok.nokia.com><158001ccdd17$d8c00170$8a400450$@com><916CE6CF87173740BC8A2CE443096962042CAF87@008-AM1MPN1-051.mgdnok.nokia.com> <050401ccdf89$271fa280$755ee780$@com> <060901ccdfa1$ecd284d0$c6778e70$@com> In-Reply-To: Date: Mon, 30 Jan 2012 18:17:08 -0800 Message-ID: <071f01ccdfbe$6f001b40$4d0051c0$@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: AQHM3RfdVEdgOoBqgki3VCG9yLTfQ5Yk1odwgAB5pHCAAATNYIAAFFCggAAenwCAADJKAIAAB2Ug Content-Language: en-us Cc: behave@ietf.org Subject: Re: [BEHAVE] DNSSEC and NAT64 Discovery Heuristic [was RE: I-DAction: draft-ietf-behave-nat64-discovery-heuristic-05.txt] X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 02:17:09 -0000 > -----Original Message----- > From: Stephan Lagerholm [mailto:stephan.lagerholm@secure64.com] > Sent: Monday, January 30, 2012 5:52 PM > To: Dan Wing; teemu.savolainen@nokia.com > Cc: behave@ietf.org > Subject: RE: [BEHAVE] DNSSEC and NAT64 Discovery Heuristic [was RE: I- > DAction: draft-ietf-behave-nat64-discovery-heuristic-05.txt] > > > > > > > > > The host needs to be configured with the domain names of the > NAT64 > > > > devices it will trust -- for example, if I get my Internet > service > > > > from Comcast, I would configure my host to allow a name of > > > > *.comcast.net for the NAT64. > > > > > > Thanks, that make sense but it raises another question: If you > > > already know that you are in example.net (or Comcast.net in your > > > example). They why couldn't you just ask for > > > what-is-my-prefix.example.net, > > > what-is-my-prefixlength.example.net, > > > what-is-my-suffix.example.net ? > > > Those could be signed with DNSSEC. That sounds like a much simpler > > way > > > of learning the prefixes. > > > > It won't always work. In my own home, for example, I override my > > ISP's DNS search list to one of my personal domains. Thus, if > > we only query .example.net, it would fail > > in those instances. Querying ipv6only.arpa would always work > > in those cases. > > Ok, now I'm confused. You just said that the host needs to be > configured with the domain names of the NAT64 it will trust... As document author: For doing the DNSSEC validation, yes, that's right. If the host doesn't want to validate the information it gets from its ipv4only.arpa query, it can just use it -- it will be approximately (not exactly) as trustable as other DNS responses it receives. Not every host will do DNSSEC validation ("walk, then run"). But, when a host wants to do that, we wanted explanation for how it happens. > > DNSSEC validation is intended to be optional. > > Thanks for clarifying this. You should probably spell that out in > the draft. (I was reading it as if DNSSEC were mandatory and that the > CD bit was set from all handsets/clients.) It's in a subsection right now; I agree that dropping it later into the document would help. -d From dwing@cisco.com Tue Jan 31 11:27: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 5857821F8531; Tue, 31 Jan 2012 11:27:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.569 X-Spam-Level: X-Spam-Status: No, score=-106.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 2X7yIM3fESiI; Tue, 31 Jan 2012 11:27:34 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 359DA21F851D; Tue, 31 Jan 2012 11:27:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=392; q=dns/txt; s=iport; t=1328038053; x=1329247653; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=fw5exKSvm4h6hwwEaXIOqJItWwsLhDWt48+cos4YRH4=; b=EvAsMPKx1berMS6h1PhYB1aj64X8qMu1IkInoVlcq3fhz/S7tTJb1TUh I67eM+9TTGEPA0/i0HOvC3KFocYENrgC8wrsyZlXerZ/pLeSRx+1kPmgv sukjQXkWTqnBJ1LkU3MLMcojAw/9vI0JA3wAYLitEPzB9+/uR6OJVMS19 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAOM/KE+rRDoJ/2dsb2JhbABDn3WOa4EFgXkICgEXEC4RDQUYUCMcAQQeF4djmiYBnluLAQUBBgEBAgEpDAEBCQQUCw8DAQIBA4RIARWDHASIQIUFmlA X-IronPort-AV: E=Sophos;i="4.71,597,1320624000"; d="scan'208";a="28021066" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 31 Jan 2012 19:27:31 +0000 Received: from dwingWS (sjc-vpn6-616.cisco.com [10.21.122.104]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q0VJRUu8015702; Tue, 31 Jan 2012 19:27:30 GMT From: "Dan Wing" To: Date: Tue, 31 Jan 2012 11:27:30 -0800 Message-ID: <096801cce04e$5fafcf10$1f0f6d30$@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: AczgTl9hEazs2/PLRM2dW+P1zvrl0A== Content-Language: en-us Cc: 'David B Harrington' , iesg-secretary@ietf.org, behave-chairs@tools.ietf.org, 'Dave Thaler' Subject: [BEHAVE] reschedule BEHAVE interim: Thursday, February 16 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, 31 Jan 2012 19:27:35 -0000 Sorry, due to a scheduling mistake that I made, we need to move the BEHAVE audio conference interim meeting (yes, again). We are cancelling the February 3 interim meeting. New time: Thursday, February 16, 7am-8:30am Pacific Standard Time (San Francisco, GMT-08:00). Agenda and audio conference details published at http://trac.tools.ietf.org/wg/behave/trac/wiki/WikiStart -d From wwwrun@ietfa.amsl.com Tue Jan 31 16:22:45 2012 Return-Path: X-Original-To: behave@ietf.org Delivered-To: behave@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 30) id 17C9E21F8548; Tue, 31 Jan 2012 16:22:45 -0800 (PST) From: IESG Secretary To: IETF Announcement list Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20120201002245.17C9E21F8548@ietfa.amsl.com> Date: Tue, 31 Jan 2012 16:22:45 -0800 (PST) Cc: behave@ietf.org Subject: [BEHAVE] Rescheduled BEHAVE WG Virtual Interim Meeting: Thursday, February 16, 7am PST 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, 01 Feb 2012 00:22:45 -0000 Due to a scheduling conflict, the BEHAVE audio conference interim meeting is being rescheduled. The previously-scheduled February 3 interim meeting is cancelled. NEW DATE AND TIME: Thursday, February 16, 7am-8:30am Pacific Standard Time (San Francisco, GMT-08:00). Agenda and audio conference details published at http://trac.tools.ietf.org/wg/behave/trac/wiki/WikiStart