<= SPAN=20 class=3Dh1>Discussion: Should draft-ietf-behave-nat64-discovery-heuristic say something about = the=20 applicability scope? Is it justified to implement this heuristic to retriev= e an=20 information which is available via PCP?

<= SPAN=20 class=3Dh1>

<= SPAN=20 class=3Dh1>Cheers,

<= SPAN=20 class=3Dh1>Med

--_000_94C682931C08B048B7A8645303FDC9F36E57B08679PUEXCB1Bnante_-- From teemu.savolainen@nokia.com Fri Sep 7 00:12: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 915A121E809A for ; Fri, 7 Sep 2012 00:12:16 -0700 (PDT) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tla-vLoM7z-a for ; Fri, 7 Sep 2012 00:12:16 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id B454021E808A for ; Fri, 7 Sep 2012 00:12:15 -0700 (PDT) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-da02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q877BSiN008606; Fri, 7 Sep 2012 10:12:14 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.47]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 7 Sep 2012 10:11:52 +0300 Received: from 008-AM1MPN1-053.mgdnok.nokia.com ([169.254.3.232]) by 008-AM1MMR1-013.mgdnok.nokia.com ([2002:4136:1e2f::4136:1e2f]) with mapi id 14.02.0309.003; Fri, 7 Sep 2012 09:11:51 +0200 From: To: , Thread-Topic: draft-ietf-behave-nat64-discovery-heuristic in PCP-enabled networks? Thread-Index: Ac2MxAyc7zD6FB63TBeiX8PaDuv0LgAAxlPw Date: Fri, 7 Sep 2012 07:11:50 +0000 Message-ID: <916CE6CF87173740BC8A2CE4430969620444AB9D@008-AM1MPN1-053.mgdnok.nokia.com> References: <94C682931C08B048B7A8645303FDC9F36E57B08679@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E57B08679@PUEXCB1B.nanterre.francetelecom.fr> 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+/nZJb9Kg7InqTkps8u7XkfvsMuD5807G9+xWipz3rWFJnQsKpRE+L3W8bHr1x7LA/8ESXCHSfn3v1moTxuezKv1AQB2ThX1Yzp0GVWXa3sMiZ2oj+qK5Y/UxWhXBIuHJUOi/5bR1xd1zAT9Yefe3OYLrsgrfetE8kkLEj5fGOjObd/4xH4lB701bj0/DRw+mn7IBRBa33Q2sFPHLRQrPH90hnlTldSO2zixuidHMrZsmOdR3xOVl8Pxf87MietZdmflzp5wQISeHXlxPluSra0mZ9vNe7Jr0= x-originating-ip: [10.163.19.180] Content-Type: multipart/alternative; boundary="_000_916CE6CF87173740BC8A2CE4430969620444AB9D008AM1MPN1053mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 07 Sep 2012 07:11:52.0422 (UTC) FILETIME=[0E42D060:01CD8CC8] X-Nokia-AV: Clean Subject: Re: [BEHAVE] draft-ietf-behave-nat64-discovery-heuristic in PCP-enabled networks? 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, 07 Sep 2012 07:12:16 -0000 --_000_916CE6CF87173740BC8A2CE4430969620444AB9D008AM1MPN1053mg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Med, All, It is justified, because the heuristic approach was specifically developed = to allow discovery of Pref64::/n when the network does not explicitly provi= de the information (by any means that are generally available). Even if PCP= would provide this information, there is no telling what kind of deploymen= t PCP will see and especially will there always be PCP when there is NAT64. Furthermore, will the PCP *always* tell the Pref64::/n, or is that also PCP= deployment specific detail? IMHO PCP proposal for Pref64::/n falls to similar category as DHCPv6 in the= draft-ietf-behave-nat64-learn-analysis-03.txt. I.e. it may not be deployed= alongside NAT64, it requires PCP client implementation on a node, and so f= orth. Best regards, Teemu From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of= ext mohamed.boucadair@orange.com Sent: 07. syyskuuta 2012 09:43 To: behave@ietf.org Subject: [BEHAVE] draft-ietf-behave-nat64-discovery-heuristic in PCP-enable= d networks? Dear all, I bring this discussion point to behave ML as draft-ietf-behave-nat64-disco= very-heuristic was cited by Simon and Reddy in PCP ML. Context: There are plans to use PCP to control an upstream NAT64. For such = contexts, using PCP to retrieve the PREFI64 is straightforward. Discussion: Should draft-ietf-behave-nat64-discovery-heuristic say somethin= g about the applicability scope? Is it justified to implement this heuristi= c to retrieve an information which is available via PCP? Cheers, Med --_000_916CE6CF87173740BC8A2CE4430969620444AB9D008AM1MPN1053mg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Med, All,

<= /p>

It is justified, because = the heuristic approach was specifically developed to allow discovery of Pre= f64::/n when the network does not explicitly provide the information (by any means that are generally available). Even if PCP would= provide this information, there is no telling what kind of deployment PCP = will see and especially will there always be PCP when there is NAT64.<= /o:p>

<= /p>

Furthermore, will the PCP= *always* tell the Pref64::/n, or is that also PCP deployment specif= ic detail?

<= /p>

IMHO PCP proposal for Pre= f64::/n falls to similar category as DHCPv6 in the draft-ietf-behave-nat64-= learn-analysis-03.txt. I.e. it may not be deployed alongside NAT64, it requires PCP client implementation on a node, and so forth.=

<= /p>

Best regards,<= /span>

<= /p>

&= nbsp; Teemu

<= /p>

From: behave-b= ounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of ext mohamed.boucadair@orange.com
Sent: 07. syyskuuta 2012 09:43
To: behave@ietf.org
Subject: [BEHAVE] draft-ietf-behave-nat64-discovery-heuristic in PCP= -enabled networks?

Dear all,

I bring this discussion point to behave= ML as draft-ietf-behave-nat64-discovery-heuristic was = cited by Simon and Reddy in PCP ML.

Context: There are plans to use PCP to control an upstream NAT64. For such c= ontexts, using PCP to retrieve the PREFI64 is straightforward.

Discussion: Should draft-ietf-behave-na= t64-discovery-heuristic say something about the applicability scope? Is it = justified to implement this heuristic to retrieve an information which is available via PCP? <= /p>

Cheers,

Med

--_000_916CE6CF87173740BC8A2CE4430969620444AB9D008AM1MPN1053mg_-- From mohamed.boucadair@orange.com Fri Sep 7 01:27: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 252C721F8570; Fri, 7 Sep 2012 01:27:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.915 X-Spam-Level: X-Spam-Status: No, score=-1.915 tagged_above=-999 required=5 tests=[AWL=-0.267, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_12=0.6, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hfZhcoxy9jp2; Fri, 7 Sep 2012 01:27:33 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id C7E3921F8567; Fri, 7 Sep 2012 01:27:32 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 08C572643A9; Fri, 7 Sep 2012 10:27:32 +0200 (CEST) Received: from puexch31.nanterre.francetelecom.fr (unknown [10.101.44.29]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id E004827C11B; Fri, 7 Sep 2012 10:27:31 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by puexch31.nanterre.francetelecom.fr ([10.101.44.29]) with mapi; Fri, 7 Sep 2012 10:27:29 +0200 From: To: "teemu.savolainen@nokia.com" , "simon.perreault@viagenie.ca" Date: Fri, 7 Sep 2012 10:27:28 +0200 Thread-Topic: [pcp] PREFIX64 PCP Option for NAT64: draft-boucadair-pcp-nat64-prefix64-option Thread-Index: Ac2MREsThTb5jn5dQvm14yeG1MbvVgAdLJUwAAPMTNAAAgZYgA== Message-ID: <94C682931C08B048B7A8645303FDC9F36E57B08727@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E57B08381@PUEXCB1B.nanterre.francetelecom.fr> <504898BD.7000702@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E57B08524@PUEXCB1B.nanterre.francetelecom.fr> <5048AC63.50700@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E57B085C5@PUEXCB1B.nanterre.francetelecom.fr> <5048C127.50704@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E57B08650@PUEXCB1B.nanterre.francetelecom.fr> <916CE6CF87173740BC8A2CE4430969620444ABB8@008-AM1MPN1-053.mgdnok.nokia.com> In-Reply-To: <916CE6CF87173740BC8A2CE4430969620444ABB8@008-AM1MPN1-053.mgdnok.nokia.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.9.7.74524 Cc: "pcp@ietf.org" , "behave@ietf.org" Subject: Re: [BEHAVE] [pcp] PREFIX64 PCP Option for NAT64: draft-boucadair-pcp-nat64-prefix64-option 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, 07 Sep 2012 08:27:34 -0000 Hi Teemu, (behave ML cced) The point is: for PCP-enabled networks the heuristic seems to be more "comp= lex" compared to returning this information using PCP. >From an operational standpoint, the situation is as follows: * PCP is needed for NAT64 to accept incoming connections/hosting servers/re= duce keepalive messages/etc.=20 * A solution to learn the PREFIX64 is needed (e.g., IPv4 in referrals) so t= hat local address synthesis can be done by the host. * Several NAT64 can be deployed and load balancing enabled to distribute co= nnected hosts: this can be done by assigning distinct PREFIX64s. * An application/host needs to retrieve the exact PREFIX64 used for the NAT= 64 to be involved in the data path. * An exist strategy is still to be found for the heuristic method. * The heuristic method requires some tweaking in DNS. Given what listed above, wouldn't be safe to provide some guidelines to hel= p selecting which option to use in PCP-based networks or the one to prefer = when both are available?=20 Cheers, Med >-----Message d'origine----- >De : teemu.savolainen@nokia.com [mailto:teemu.savolainen@nokia.com]=20 >Envoy=E9 : vendredi 7 septembre 2012 09:15 >=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP; simon.perreault@viagenie.ca >Cc : pcp@ietf.org >Objet : RE: [pcp] PREFIX64 PCP Option for NAT64:=20 >draft-boucadair-pcp-nat64-prefix64-option > >Just quick comment also for PCP mailing (I sent separate email=20 >also to behave) - maybe we need to cross post if this=20 >discussion extends. > >The PCP may be fine way to learn Pref64::/n, but I doubt it is=20 >possible to generalize PCP to be always present *and* telling=20 >Pref64::/n when there is NAT64. I.e. PCP would be similar as=20 >DHCPv6 in its pros/cons (as listed in=20 >draft-ietf-behave-nat64-learn-analysis) - am I right? > >I.e. we need the heuristic to have a general way to find out=20 >Pref64::/n, as we cannot count PCP to be always deployed with NAT64. > >Best regards, > > Teemu > >> -----Original Message----- >> From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On=20 >Behalf Of ext >> mohamed.boucadair@orange.com >> Sent: 07. syyskuuta 2012 08:26 >> To: Simon Perreault >> Cc: pcp@ietf.org >> Subject: Re: [pcp] PREFIX64 PCP Option for NAT64:=20 >draft-boucadair-pcp- >> nat64-prefix64-option >> >> Hi Simon, >> >> Perhaps it is too late to ask for including it in the analysis draft. >> I see another place where we can ask for including it is:=20 >464xlat v6op draft. >> >> Cheers, >> Med >> >> >-----Message d'origine----- >> >De : Simon Perreault [mailto:simon.perreault@viagenie.ca] >> >Envoy=E9 : jeudi 6 septembre 2012 17:29 >> >=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >> >Cc : pcp@ietf.org >> >Objet : Re: [pcp] PREFIX64 PCP Option for NAT64: >> >draft-boucadair-pcp-nat64-prefix64-option >> > >> >Le 2012-09-06 11:04, mohamed.boucadair@orange.com a =E9crit : >> >> Med: I'm open to evaluate which approach is better: new opcode vs. >> >> new option. We need first to agree this is valid problem to solve. >> > >> >There is clearly a need to discover the NAT64 prefix: >> >draft-ietf-behave-nat64-learn-analysis >> >draft-ietf-behave-nat64-discovery-heuristic >> > >> >Note that the analysis draft does not consider PCP. Maybe it should. >> >Looking at the list of pros and cons for DHCPv6, PCP would be >> >different, and better in some aspects. >> > >> >Personally I would much prefer using PCP than the heuristic=20 >when PCP is >> >available. >> > >> >Simon >> >-- >> >DTN made easy, lean, and smart --> http://postellation.viagenie.ca >> >NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca >> >STUN/TURN server --> http://numb.viagenie.ca >> > >> _______________________________________________ >> pcp mailing list >> pcp@ietf.org >> https://www.ietf.org/mailman/listinfo/pcp >= From teemu.savolainen@nokia.com Fri Sep 7 02:57: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 2847021F84EC; Fri, 7 Sep 2012 02:57:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.149 X-Spam-Level: X-Spam-Status: No, score=-6.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zpwCrD3jLyMz; Fri, 7 Sep 2012 02:57:47 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 965F821F84D9; Fri, 7 Sep 2012 02:57:46 -0700 (PDT) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-da01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q879vLst017086; Fri, 7 Sep 2012 12:57:41 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.57]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 7 Sep 2012 12:57:21 +0300 Received: from 008-AM1MPN1-052.mgdnok.nokia.com ([169.254.2.249]) by 008-AM1MMR1-002.mgdnok.nokia.com ([65.54.30.57]) with mapi id 14.02.0309.003; Fri, 7 Sep 2012 11:57:20 +0200 From: To: , Thread-Topic: [pcp] PREFIX64 PCP Option for NAT64: draft-boucadair-pcp-nat64-prefix64-option Thread-Index: Ac2MREsThTb5jn5dQvm14yeG1MbvVgAdLJUwAAPMTNAAAgZYgAADCg4Q Date: Fri, 7 Sep 2012 09:57:19 +0000 Message-ID: <916CE6CF87173740BC8A2CE44309696204453374@008-AM1MPN1-052.mgdnok.nokia.com> References: <94C682931C08B048B7A8645303FDC9F36E57B08381@PUEXCB1B.nanterre.francetelecom.fr> <504898BD.7000702@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E57B08524@PUEXCB1B.nanterre.francetelecom.fr> <5048AC63.50700@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E57B085C5@PUEXCB1B.nanterre.francetelecom.fr> <5048C127.50704@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E57B08650@PUEXCB1B.nanterre.francetelecom.fr> <916CE6CF87173740BC8A2CE4430969620444ABB8@008-AM1MPN1-053.mgdnok.nokia.com> <94C682931C08B048B7A8645303FDC9F36E57B08727@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E57B08727@PUEXCB1B.nanterre.francetelecom.fr> 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+/nZJb9Kg7IkG58TW0g8v3pRTIa5m0oRvOwWvPPL+sw1OI592gw0w+/D3rEkeVQ4iwch1++FHcoO6ydKVeY+yCx3JcwHtjroRij1AGuFnPfkj1BKE+9amJQMLBqkOWtEyXwQcgA66Rr5fF+0nTmIq9fhFmwOM2gfVNHhve4r0QbqTjQVKTmTfd6LlB35tVQWpxV69dUtObFgw3JVNtcAwDrBbnM2Wr5OowXtvCCIa3PhLR4cmMj1tWHfI6o6eIvLmFmocxa5M0VK9vjgxt2LbmQJFRMeIhWR2HkLrNofwa3pe2qo3hym0M x-originating-ip: [10.163.19.180] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 07 Sep 2012 09:57:21.0608 (UTC) FILETIME=[2C845C80:01CD8CDF] X-Nokia-AV: Clean Cc: pcp@ietf.org, behave@ietf.org Subject: Re: [BEHAVE] [pcp] PREFIX64 PCP Option for NAT64: draft-boucadair-pcp-nat64-prefix64-option 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, 07 Sep 2012 09:57:48 -0000 Hi Med, >From a host standpoint there are no guarantees to have PCP always available= when a NAT64 is present. Hence heuristic is needed anyway, but as an optim= ization/improvement it is possible to avoid heuristic in cases where PCP ha= ppens to be available. To respond to your detailed points: > * PCP is needed for NAT64 to accept incoming connections/hosting > servers/reduce keepalive messages/etc. Only if an operator chooses to provide these goodies to hosts; I have no ev= idence that says all operators who deploy NAT64 are ok to allow incoming co= nnections/hosting services/helping hosts to reduce keepalive signaling. I d= o hope PCP finds its place in networks and helps save battery etc, but it i= s not something that can be assumed to happen (always). > * A solution to learn the PREFIX64 is needed (e.g., IPv4 in referrals) so= that > local address synthesis can be done by the host. Agree:) > * Several NAT64 can be deployed and load balancing enabled to distribute > connected hosts: this can be done by assigning distinct PREFIX64s. Yes, but do you need to make an individual host use multitude of Pref64::/n= ? In a large deployment wouldn't the load balancing purposes be achieved by= some hosts using one Pref64::/n and others using another? > * An application/host needs to retrieve the exact PREFIX64 used for the > NAT64 to be involved in the data path. You plan to utilize different Pref64::/n for different IPv4 destinations? T= hat is definitely something heuristic does not support (finding out random = mappings for different IPv4 addresses would require plenty of queries :-D If this is really a hard requirement (i.e. not possible / too costly) to ro= ute all IPv4 traffic using a single Pref64::/n, then I agree you need to ha= ve a provisioning tool in place. This tool perhaps could be PCP - if this W= G thinks it is ok to extent PCP for this kind of provisioning purposes - fo= r me this sounds a bit like loading PCP with something that might fit bette= r to DHCPv6. All that I'm saying is that PCP cannot replace the need for heuristic in a = general case due availability reasons, and that I don't think it is ok to m= andate hosts to implement PCP just for Pref64::/n discovery purposes. > * An exist strategy is still to be found for the heuristic method. True (but hosts would also someday need to stop asking for Pref64::/n with = PCP). > * The heuristic method requires some tweaking in DNS. It requires hosting of a well-known IPv4-only name, such as "ipv4only.arpa"= . But no tweaking to DNS protocols or server softwares. That is much less t= weaking that implementing PCP client to hosts/applications, hosting PCP ser= ver on all NAT64 enabled networks, and supporting some PCP server discovery= mechanism (e.g. via DHCPv6 options). Best regards, Teemu > -----Original Message----- > From: ext mohamed.boucadair@orange.com > [mailto:mohamed.boucadair@orange.com] > Sent: 07. syyskuuta 2012 11:27 > To: Savolainen Teemu (Nokia-NRC/Tampere); simon.perreault@viagenie.ca > Cc: pcp@ietf.org; behave@ietf.org > Subject: RE: [pcp] PREFIX64 PCP Option for NAT64: draft-boucadair-pcp- > nat64-prefix64-option >=20 > Hi Teemu, >=20 > (behave ML cced) >=20 > The point is: for PCP-enabled networks the heuristic seems to be more > "complex" compared to returning this information using PCP. >=20 > From an operational standpoint, the situation is as follows: >=20 > * PCP is needed for NAT64 to accept incoming connections/hosting > servers/reduce keepalive messages/etc. > * A solution to learn the PREFIX64 is needed (e.g., IPv4 in referrals) so= that > local address synthesis can be done by the host. > * Several NAT64 can be deployed and load balancing enabled to distribute > connected hosts: this can be done by assigning distinct PREFIX64s. > * An application/host needs to retrieve the exact PREFIX64 used for the > NAT64 to be involved in the data path. > * An exist strategy is still to be found for the heuristic method. > * The heuristic method requires some tweaking in DNS. >=20 > Given what listed above, wouldn't be safe to provide some guidelines to h= elp > selecting which option to use in PCP-based networks or the one to prefer > when both are available? >=20 > Cheers, > Med >=20 > >-----Message d'origine----- > >De : teemu.savolainen@nokia.com [mailto:teemu.savolainen@nokia.com] > >Envoy=E9 : vendredi 7 septembre 2012 09:15 =C0 : BOUCADAIR Mohamed > >OLNC/NAD/TIP; simon.perreault@viagenie.ca Cc : pcp@ietf.org Objet : RE: > >[pcp] PREFIX64 PCP Option for NAT64: > >draft-boucadair-pcp-nat64-prefix64-option > > > >Just quick comment also for PCP mailing (I sent separate email also to > >behave) - maybe we need to cross post if this discussion extends. > > > >The PCP may be fine way to learn Pref64::/n, but I doubt it is possible > >to generalize PCP to be always present *and* telling Pref64::/n when > >there is NAT64. I.e. PCP would be similar as > >DHCPv6 in its pros/cons (as listed in > >draft-ietf-behave-nat64-learn-analysis) - am I right? > > > >I.e. we need the heuristic to have a general way to find out > >Pref64::/n, as we cannot count PCP to be always deployed with NAT64. > > > >Best regards, > > > > Teemu > > > >> -----Original Message----- > >> From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On > >Behalf Of ext > >> mohamed.boucadair@orange.com > >> Sent: 07. syyskuuta 2012 08:26 > >> To: Simon Perreault > >> Cc: pcp@ietf.org > >> Subject: Re: [pcp] PREFIX64 PCP Option for NAT64: > >draft-boucadair-pcp- > >> nat64-prefix64-option > >> > >> Hi Simon, > >> > >> Perhaps it is too late to ask for including it in the analysis draft. > >> I see another place where we can ask for including it is: > >464xlat v6op draft. > >> > >> Cheers, > >> Med > >> > >> >-----Message d'origine----- > >> >De : Simon Perreault [mailto:simon.perreault@viagenie.ca] > >> >Envoy=E9 : jeudi 6 septembre 2012 17:29 =C0 : BOUCADAIR Mohamed > >> >OLNC/NAD/TIP Cc : pcp@ietf.org Objet : Re: [pcp] PREFIX64 PCP Option > >> >for NAT64: > >> >draft-boucadair-pcp-nat64-prefix64-option > >> > > >> >Le 2012-09-06 11:04, mohamed.boucadair@orange.com a =E9crit : > >> >> Med: I'm open to evaluate which approach is better: new opcode vs. > >> >> new option. We need first to agree this is valid problem to solve. > >> > > >> >There is clearly a need to discover the NAT64 prefix: > >> >draft-ietf-behave-nat64-learn-analysis > >> >draft-ietf-behave-nat64-discovery-heuristic > >> > > >> >Note that the analysis draft does not consider PCP. Maybe it should. > >> >Looking at the list of pros and cons for DHCPv6, PCP would be > >> >different, and better in some aspects. > >> > > >> >Personally I would much prefer using PCP than the heuristic > >when PCP is > >> >available. > >> > > >> >Simon > >> >-- > >> >DTN made easy, lean, and smart --> http://postellation.viagenie.ca > >> >NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > >> >STUN/TURN server --> http://numb.viagenie.ca > >> > > >> _______________________________________________ > >> pcp mailing list > >> pcp@ietf.org > >> https://www.ietf.org/mailman/listinfo/pcp > > From mohamed.boucadair@orange.com Fri Sep 7 04:40:11 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 02F5D21E8034; Fri, 7 Sep 2012 04:40:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_12=0.6, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jj0s5Yj61+74; Fri, 7 Sep 2012 04:40:10 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 850D821E803C; Fri, 7 Sep 2012 04:40:09 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 9801C2643F7; Fri, 7 Sep 2012 13:40:08 +0200 (CEST) Received: from PUEXCH11.nanterre.francetelecom.fr (unknown [10.101.44.27]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 743BA238129; Fri, 7 Sep 2012 13:40:08 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH11.nanterre.francetelecom.fr ([10.101.44.27]) with mapi; Fri, 7 Sep 2012 13:40:06 +0200 From: To: "teemu.savolainen@nokia.com" , "simon.perreault@viagenie.ca" Date: Fri, 7 Sep 2012 13:40:05 +0200 Thread-Topic: [pcp] PREFIX64 PCP Option for NAT64: draft-boucadair-pcp-nat64-prefix64-option Thread-Index: Ac2MREsThTb5jn5dQvm14yeG1MbvVgAdLJUwAAPMTNAAAgZYgAADCg4QAAPxyvA= Message-ID: <94C682931C08B048B7A8645303FDC9F36E57B08811@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E57B08381@PUEXCB1B.nanterre.francetelecom.fr> <504898BD.7000702@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E57B08524@PUEXCB1B.nanterre.francetelecom.fr> <5048AC63.50700@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E57B085C5@PUEXCB1B.nanterre.francetelecom.fr> <5048C127.50704@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E57B08650@PUEXCB1B.nanterre.francetelecom.fr> <916CE6CF87173740BC8A2CE4430969620444ABB8@008-AM1MPN1-053.mgdnok.nokia.com> <94C682931C08B048B7A8645303FDC9F36E57B08727@PUEXCB1B.nanterre.francetelecom.fr> <916CE6CF87173740BC8A2CE44309696204453374@008-AM1MPN1-052.mgdnok.nokia.com> In-Reply-To: <916CE6CF87173740BC8A2CE44309696204453374@008-AM1MPN1-052.mgdnok.nokia.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.6.19.115414 Cc: "pcp@ietf.org" , "behave@ietf.org" Subject: Re: [BEHAVE] [pcp] PREFIX64 PCP Option for NAT64: draft-boucadair-pcp-nat64-prefix64-option 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, 07 Sep 2012 11:40:11 -0000 Re-, Please see inline. Cheers, Med =20 >-----Message d'origine----- >De : teemu.savolainen@nokia.com [mailto:teemu.savolainen@nokia.com]=20 >Envoy=E9 : vendredi 7 septembre 2012 11:57 >=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP; simon.perreault@viagenie.ca >Cc : pcp@ietf.org; behave@ietf.org >Objet : RE: [pcp] PREFIX64 PCP Option for NAT64:=20 >draft-boucadair-pcp-nat64-prefix64-option > >Hi Med, > >From a host standpoint there are no guarantees to have PCP=20 >always available when a NAT64 is present.=20 Med: Yes, this is deployment-specific. Note the LSN requirements draft mand= ates to have a way to open mappings. Hence heuristic is=20 >needed anyway, but as an optimization/improvement it is=20 >possible to avoid heuristic in cases where PCP happens to be available. Med: This is what I wanted to hear. The intent was not to say PCP is better= . My initial discussion point was focusing on PCP-enabled networks and only= that case. Concretely, would it be possible to add a sentence in the sense= of your statement above?=20 > >To respond to your detailed points: > >> * PCP is needed for NAT64 to accept incoming connections/hosting >> servers/reduce keepalive messages/etc. > >Only if an operator chooses to provide these goodies to hosts;=20 >I have no evidence that says all operators who deploy NAT64=20 >are ok to allow incoming connections/hosting services/helping=20 >hosts to reduce keepalive signaling. I do hope PCP finds its=20 >place in networks and helps save battery etc, but it is not=20 >something that can be assumed to happen (always). Med: That's fair. Again, I'm exclusively positioning this discussion in con= text where PCP is deployed. > >> * A solution to learn the PREFIX64 is needed (e.g., IPv4 in=20 >referrals) so that >> local address synthesis can be done by the host. > >Agree:) > >> * Several NAT64 can be deployed and load balancing enabled=20 >to distribute >> connected hosts: this can be done by assigning distinct PREFIX64s. > >Yes, but do you need to make an individual host use multitude=20 >of Pref64::/n? In a large deployment wouldn't the load=20 >balancing purposes be achieved by some hosts using one=20 >Pref64::/n and others using another? > >> * An application/host needs to retrieve the exact PREFIX64=20 >used for the >> NAT64 to be involved in the data path. > >You plan to utilize different Pref64::/n for different IPv4=20 >destinations? That is definitely something heuristic does not=20 >support (finding out random mappings for different IPv4=20 >addresses would require plenty of queries :-D Med: This can happen if each NAT64 is servicing a portion of the IPv4 netwo= rk/internet. > >If this is really a hard requirement (i.e. not possible / too=20 >costly) to route all IPv4 traffic using a single Pref64::/n,=20 >then I agree you need to have a provisioning tool in place.=20 >This tool perhaps could be PCP - if this WG thinks it is ok to=20 >extent PCP for this kind of provisioning purposes - for me=20 >this sounds a bit like loading PCP with something that might=20 >fit better to DHCPv6. Med: I disagree: PCP is there to help NAT traversal, returning the PREFIX64= is part of that problem.=20 > >All that I'm saying is that PCP cannot replace the need for=20 >heuristic in a general case due availability reasons, and that=20 >I don't think it is ok to mandate hosts to implement PCP just=20 >for Pref64::/n discovery purposes. Med: I didn't asked for that. Sorry I was not clear: the scope of this disc= ussion is: PCP-enabled networks. > >> * An exist strategy is still to be found for the heuristic method. > >True (but hosts would also someday need to stop asking for=20 >Pref64::/n with PCP). > >> * The heuristic method requires some tweaking in DNS. > >It requires hosting of a well-known IPv4-only name, such as=20 >"ipv4only.arpa". But no tweaking to DNS protocols or server=20 >softwares. That is much less tweaking that implementing PCP=20 >client to hosts/applications, hosting PCP server on all NAT64=20 >enabled networks, and supporting some PCP server discovery=20 >mechanism (e.g. via DHCPv6 options). > >Best regards, > > Teemu > >> -----Original Message----- >> From: ext mohamed.boucadair@orange.com >> [mailto:mohamed.boucadair@orange.com] >> Sent: 07. syyskuuta 2012 11:27 >> To: Savolainen Teemu (Nokia-NRC/Tampere); simon.perreault@viagenie.ca >> Cc: pcp@ietf.org; behave@ietf.org >> Subject: RE: [pcp] PREFIX64 PCP Option for NAT64:=20 >draft-boucadair-pcp- >> nat64-prefix64-option >>=20 >> Hi Teemu, >>=20 >> (behave ML cced) >>=20 >> The point is: for PCP-enabled networks the heuristic seems to be more >> "complex" compared to returning this information using PCP. >>=20 >> From an operational standpoint, the situation is as follows: >>=20 >> * PCP is needed for NAT64 to accept incoming connections/hosting >> servers/reduce keepalive messages/etc. >> * A solution to learn the PREFIX64 is needed (e.g., IPv4 in=20 >referrals) so that >> local address synthesis can be done by the host. >> * Several NAT64 can be deployed and load balancing enabled=20 >to distribute >> connected hosts: this can be done by assigning distinct PREFIX64s. >> * An application/host needs to retrieve the exact PREFIX64=20 >used for the >> NAT64 to be involved in the data path. >> * An exist strategy is still to be found for the heuristic method. >> * The heuristic method requires some tweaking in DNS. >>=20 >> Given what listed above, wouldn't be safe to provide some=20 >guidelines to help >> selecting which option to use in PCP-based networks or the=20 >one to prefer >> when both are available? >>=20 >> Cheers, >> Med >>=20 >> >-----Message d'origine----- >> >De : teemu.savolainen@nokia.com [mailto:teemu.savolainen@nokia.com] >> >Envoy=E9 : vendredi 7 septembre 2012 09:15 =C0 : BOUCADAIR Mohamed >> >OLNC/NAD/TIP; simon.perreault@viagenie.ca Cc : pcp@ietf.org=20 >Objet : RE: >> >[pcp] PREFIX64 PCP Option for NAT64: >> >draft-boucadair-pcp-nat64-prefix64-option >> > >> >Just quick comment also for PCP mailing (I sent separate=20 >email also to >> >behave) - maybe we need to cross post if this discussion extends. >> > >> >The PCP may be fine way to learn Pref64::/n, but I doubt it=20 >is possible >> >to generalize PCP to be always present *and* telling Pref64::/n when >> >there is NAT64. I.e. PCP would be similar as >> >DHCPv6 in its pros/cons (as listed in >> >draft-ietf-behave-nat64-learn-analysis) - am I right? >> > >> >I.e. we need the heuristic to have a general way to find out >> >Pref64::/n, as we cannot count PCP to be always deployed with NAT64. >> > >> >Best regards, >> > >> > Teemu >> > >> >> -----Original Message----- >> >> From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On >> >Behalf Of ext >> >> mohamed.boucadair@orange.com >> >> Sent: 07. syyskuuta 2012 08:26 >> >> To: Simon Perreault >> >> Cc: pcp@ietf.org >> >> Subject: Re: [pcp] PREFIX64 PCP Option for NAT64: >> >draft-boucadair-pcp- >> >> nat64-prefix64-option >> >> >> >> Hi Simon, >> >> >> >> Perhaps it is too late to ask for including it in the=20 >analysis draft. >> >> I see another place where we can ask for including it is: >> >464xlat v6op draft. >> >> >> >> Cheers, >> >> Med >> >> >> >> >-----Message d'origine----- >> >> >De : Simon Perreault [mailto:simon.perreault@viagenie.ca] >> >> >Envoy=E9 : jeudi 6 septembre 2012 17:29 =C0 : BOUCADAIR Mohamed >> >> >OLNC/NAD/TIP Cc : pcp@ietf.org Objet : Re: [pcp]=20 >PREFIX64 PCP Option >> >> >for NAT64: >> >> >draft-boucadair-pcp-nat64-prefix64-option >> >> > >> >> >Le 2012-09-06 11:04, mohamed.boucadair@orange.com a =E9crit : >> >> >> Med: I'm open to evaluate which approach is better:=20 >new opcode vs. >> >> >> new option. We need first to agree this is valid=20 >problem to solve. >> >> > >> >> >There is clearly a need to discover the NAT64 prefix: >> >> >draft-ietf-behave-nat64-learn-analysis >> >> >draft-ietf-behave-nat64-discovery-heuristic >> >> > >> >> >Note that the analysis draft does not consider PCP.=20 >Maybe it should. >> >> >Looking at the list of pros and cons for DHCPv6, PCP would be >> >> >different, and better in some aspects. >> >> > >> >> >Personally I would much prefer using PCP than the heuristic >> >when PCP is >> >> >available. >> >> > >> >> >Simon >> >> >-- >> >> >DTN made easy, lean, and smart -->=20 >http://postellation.viagenie.ca >> >> >NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca >> >> >STUN/TURN server --> http://numb.viagenie.ca >> >> > >> >> _______________________________________________ >> >> pcp mailing list >> >> pcp@ietf.org >> >> https://www.ietf.org/mailman/listinfo/pcp >> > >= From simon.perreault@viagenie.ca Fri Sep 7 05:45: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 EFB4921F8734 for ; Fri, 7 Sep 2012 05:45:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hl09ovGxWZAk for ; Fri, 7 Sep 2012 05:45:58 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0194321F8715 for ; Fri, 7 Sep 2012 05:45:58 -0700 (PDT) Received: from balaise.nomis80.org (modemcable212.59-179-173.mc.videotron.ca [173.179.59.212]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 3AE54415C0 for ; Fri, 7 Sep 2012 08:45:57 -0400 (EDT) Message-ID: <5049EC84.2090102@viagenie.ca> Date: Fri, 07 Sep 2012 08:45:56 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: behave@ietf.org References: <94C682931C08B048B7A8645303FDC9F36E57B08679@PUEXCB1B.nanterre.francetelecom.fr> <916CE6CF87173740BC8A2CE4430969620444AB9D@008-AM1MPN1-053.mgdnok.nokia.com> In-Reply-To: <916CE6CF87173740BC8A2CE4430969620444AB9D@008-AM1MPN1-053.mgdnok.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] draft-ietf-behave-nat64-discovery-heuristic in PCP-enabled networks? 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, 07 Sep 2012 12:45:59 -0000 On 09/07/2012 03:11 AM, teemu.savolainen@nokia.com wrote: > IMHO PCP proposal for Pref64::/n falls to similar category as DHCPv6 in > the draft-ietf-behave-nat64-learn-analysis-03.txt. I.e. it may not be > deployed alongside NAT64, it requires PCP client implementation on a > node, and so forth. Yes they are similar, but there are differences: > The PROs of the proposal are listed below: > > + Can be used to solve Issue #1, Issue #2, Issue #3 and Issue #4 via > DHCPv6 information lifetime. Same for PCP. > + Does not involve DNS system. Therefore, applications that would > not normally initiate any DNS queries can still learn the NAT64 > prefix. Same for PCP. > + DHCPv6 is designed to provide various kinds of configuration > information in a centrally managed fashion. Not really the same, but this is fuzzy... > The CONs of the proposal are listed below: > > - Change of NSP requires change to DHCPv6 configuration. Here PCP is different: since the PCP server presumably has direct access to CGN configuration, there is no need to change the PCP server configuration. > - Requires at least Stateless DHCPv6 client on hosts. PCP requires a PCP client on hosts. > - Requires support on DHCPv6 clients, which is not trivial in all > operating systems. PCP requires support on PCP clients. > - The DHCPv6-based solution involves changes and management on > network side nodes that are not really part of the NAT64/DNS64 > deployment (or issues caused by their existence). This does not apply to PCP. > - A new DHCPv6 option is required and the corresponding changes to > both DHCPv6 clients and servers. And a new PCP option/opcode is required. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From teemu.savolainen@nokia.com Fri Sep 7 06:17: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 B7E0821F841B; Fri, 7 Sep 2012 06:17:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.399 X-Spam-Level: X-Spam-Status: No, score=-6.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yi3Z3qf3bShM; Fri, 7 Sep 2012 06:17:21 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id A13ED21F85EF; Fri, 7 Sep 2012 06:17:20 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (in-mx.nokia.com [10.160.244.31]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q87DHEvU031013; Fri, 7 Sep 2012 16:17:15 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.24]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 7 Sep 2012 16:17:14 +0300 Received: from 008-AM1MPN1-053.mgdnok.nokia.com ([169.254.3.232]) by 008-AM1MMR1-008.mgdnok.nokia.com ([65.54.30.24]) with mapi id 14.02.0309.003; Fri, 7 Sep 2012 15:17:14 +0200 From: To: , Thread-Topic: [pcp] PREFIX64 PCP Option for NAT64: draft-boucadair-pcp-nat64-prefix64-option Thread-Index: Ac2MREsThTb5jn5dQvm14yeG1MbvVgAdLJUwAAPMTNAAAgZYgAADCg4QAAPxyvAAAq5H8A== Date: Fri, 7 Sep 2012 13:17:12 +0000 Message-ID: <916CE6CF87173740BC8A2CE4430969620445C977@008-AM1MPN1-053.mgdnok.nokia.com> References: <94C682931C08B048B7A8645303FDC9F36E57B08381@PUEXCB1B.nanterre.francetelecom.fr> <504898BD.7000702@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E57B08524@PUEXCB1B.nanterre.francetelecom.fr> <5048AC63.50700@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E57B085C5@PUEXCB1B.nanterre.francetelecom.fr> <5048C127.50704@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E57B08650@PUEXCB1B.nanterre.francetelecom.fr> <916CE6CF87173740BC8A2CE4430969620444ABB8@008-AM1MPN1-053.mgdnok.nokia.com> <94C682931C08B048B7A8645303FDC9F36E57B08727@PUEXCB1B.nanterre.francetelecom.fr> <916CE6CF87173740BC8A2CE44309696204453374@008-AM1MPN1-052.mgdnok.nokia.com> <94C682931C08B048B7A8645303FDC9F36E57B08811@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E57B08811@PUEXCB1B.nanterre.francetelecom.fr> 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+/nZJb9Kg7IkG58TW0g8v3pRTIa5m0oRvOwWvPPL+sw1OI592gw0w+/D3rEkeVQ4iwch1++FHcoO6ydKVeY+yCx3JcwHtjroRij1AGuFnPfkj1BKE+9amJQMLBqkOWtEyXwQcgA66Rr5fF+0nTmIq9fhFmwOM2gfVNHhve4r0QbqTjQVKTmTfd6LlB35tVQWpxV69dUtObFgw3JVNtcAwDrBbnM2Wr5OowXtvCCIa3PhLR4cmMj1tWHfI6o6eIvLmFmocxa5M0VK9vjgxt2LbmQJFRMeIhWR2HkLrNofwa3pe2qo3hym0M x-originating-ip: [10.163.19.180] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 07 Sep 2012 13:17:14.0774 (UTC) FILETIME=[19004360:01CD8CFB] X-Nokia-AV: Clean Cc: pcp@ietf.org, behave@ietf.org Subject: Re: [BEHAVE] [pcp] PREFIX64 PCP Option for NAT64: draft-boucadair-pcp-nat64-prefix64-option 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, 07 Sep 2012 13:17:21 -0000 Hi, Inline: > >From a host standpoint there are no guarantees to have PCP always > >available when a NAT64 is present. >=20 > Med: Yes, this is deployment-specific. Note the LSN requirements draft > mandates to have a way to open mappings. I hope the cellular (and other) operators actually follow the guidance once= that draft becomes RFC.=20 =20 > Med: This is what I wanted to hear. The intent was not to say PCP is bett= er. My > initial discussion point was focusing on PCP-enabled networks and only th= at > case. Concretely, would it be possible to add a sentence in the sense of = your > statement above? I think the heuristic draft is best to be kept as a standalone tool and I t= hink that it definitely should not speculate on what other tools there migh= t be available in the future (there have been other proposals as well at th= e individual I-D level). If the PREFIX64 option is adopted by the PCP WG, I think it could describe = how it will coexist with heuristic-option, e.g. saying that if a client sup= ports PCP, it SHOULD/MUST try with PREFIX64 option before performing heuris= tic procedures. Btw how do you get the IPv4 subnet->Pref64::/n mapping list with this optio= n? I quickly looked the draft and it also seemed to deliver just one Pref64= ::/n? > >Only if an operator chooses to provide these goodies to hosts; I have > >no evidence that says all operators who deploy NAT64 are ok to allow > >incoming connections/hosting services/helping hosts to reduce keepalive > >signaling. I do hope PCP finds its place in networks and helps save > >battery etc, but it is not something that can be assumed to happen > >(always). >=20 > Med: That's fair. Again, I'm exclusively positioning this discussion in c= ontext > where PCP is deployed. Good, and I definitely support deployment of PCP. > >This tool perhaps could be PCP - if this WG thinks it is ok to extent > >PCP for this kind of provisioning purposes - for me this sounds a bit > >like loading PCP with something that might fit better to DHCPv6. >=20 > Med: I disagree: PCP is there to help NAT traversal, returning the PREFIX= 64 is > part of that problem. Well, ok, I agree and changed my mind on this:) The PCP Server definitely h= as an interface to NAT64 (unlike DHCPv6 Server), and hence it could ask the= Pref64::/n from it (or provision it to NAT64, whatever you guys plan to do= ). > Med: I didn't asked for that. Sorry I was not clear: the scope of this di= scussion > is: PCP-enabled networks. Thanks, in PCP-enabled networks it is definitely ok to skip heuristics in f= avor for explicit configuration.=20 If you do go forward with explicit option, you could look if you can resolv= e the "mapping of IPv4 address ranges to IPv6 prefixes" problem. Something = better perhaps than asking from PCP Server what is the Pref64::/n for a giv= en IPv4 address.. Best regards Teemu From cb.list6@gmail.com Fri Sep 7 13:01: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 C40C921E808F; Fri, 7 Sep 2012 13:01:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.209 X-Spam-Level: X-Spam-Status: No, score=-3.209 tagged_above=-999 required=5 tests=[AWL=0.390, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ndEik-tpqmdV; Fri, 7 Sep 2012 13:01:46 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4E7DA21E805F; Fri, 7 Sep 2012 13:01:45 -0700 (PDT) Received: by lahm15 with SMTP id m15so2275823lah.31 for ; Fri, 07 Sep 2012 13:01:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=h/9hNGnP0tUV/wVBaQf2d5LqiZFgWoq50e37wVIQ6wU=; b=DlfdTPnauuZ9Lc2pQhxFvc4ZPnu1DR20oDbVNuuMgNbvLRUbwcArb1pQOpb/RyoMq7 /35Hb0nM6vuKSqXE4V2HOjkW4gpDiv6jITeiPA2GyDIQJvQyUUncJyoGtZhNDa9zq8DI 8gDUNWkzrqEwYMSr6732KzVMSuKsvT6MSDy2gwZL3wV7Ne5RU0/7dOtOZKHrKXB3csVB iF+uEbLrIjhN983THTj95IqQCPCLiYTfa0oqoJggMDFOGQhzw77TeZG0aag+lTI24AGa b596HQzIye89KekBdNYrdvKZWIcTdhE4jy+xPiC3W7+vStIFZnSUUYez8yvvc40jyFOi T7ww== MIME-Version: 1.0 Received: by 10.152.104.172 with SMTP id gf12mr6263284lab.56.1347048104248; Fri, 07 Sep 2012 13:01:44 -0700 (PDT) Received: by 10.112.49.66 with HTTP; Fri, 7 Sep 2012 13:01:40 -0700 (PDT) In-Reply-To: <916CE6CF87173740BC8A2CE4430969620445C977@008-AM1MPN1-053.mgdnok.nokia.com> References: <94C682931C08B048B7A8645303FDC9F36E57B08381@PUEXCB1B.nanterre.francetelecom.fr> <504898BD.7000702@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E57B08524@PUEXCB1B.nanterre.francetelecom.fr> <5048AC63.50700@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E57B085C5@PUEXCB1B.nanterre.francetelecom.fr> <5048C127.50704@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E57B08650@PUEXCB1B.nanterre.francetelecom.fr> <916CE6CF87173740BC8A2CE4430969620444ABB8@008-AM1MPN1-053.mgdnok.nokia.com> <94C682931C08B048B7A8645303FDC9F36E57B08727@PUEXCB1B.nanterre.francetelecom.fr> <916CE6CF87173740BC8A2CE44309696204453374@008-AM1MPN1-052.mgdnok.nokia.com> <94C682931C08B048B7A8645303FDC9F36E57B08811@PUEXCB1B.nanterre.francetelecom.fr> <916CE6CF87173740BC8A2CE4430969620445C977@008-AM1MPN1-053.mgdnok.nokia.com> Date: Fri, 7 Sep 2012 13:01:40 -0700 Message-ID: From: Cameron Byrne To: teemu.savolainen@nokia.com Content-Type: text/plain; charset=ISO-8859-1 Cc: pcp@ietf.org, mohamed.boucadair@orange.com, behave@ietf.org Subject: Re: [BEHAVE] [pcp] PREFIX64 PCP Option for NAT64: draft-boucadair-pcp-nat64-prefix64-option 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, 07 Sep 2012 20:01:46 -0000 On Fri, Sep 7, 2012 at 6:17 AM, wrote: > Hi, > > Inline: > >> >From a host standpoint there are no guarantees to have PCP always >> >available when a NAT64 is present. >> >> Med: Yes, this is deployment-specific. Note the LSN requirements draft >> mandates to have a way to open mappings. > > I hope the cellular (and other) operators actually follow the guidance once that draft becomes RFC. > Cellular operator here. No plans to support PCP on NAT64, LSN, or clients, .... just as a data point. >> Med: This is what I wanted to hear. The intent was not to say PCP is better. My >> initial discussion point was focusing on PCP-enabled networks and only that >> case. Concretely, would it be possible to add a sentence in the sense of your >> statement above? > > I think the heuristic draft is best to be kept as a standalone tool and I think that it definitely should not speculate on what other tools there might be available in the future (there have been other proposals as well at the individual I-D level). > +1 for standalone. Heuristic just like NAT64 does not require anything special on the client side aside from supporting IPv6 and a simple script to derive the Pref64. I have that today. PCP option would not be heuristic, it would be explicit (like a DHCP option) support assuming a capable client and NAT64. CB > If the PREFIX64 option is adopted by the PCP WG, I think it could describe how it will coexist with heuristic-option, e.g. saying that if a client supports PCP, it SHOULD/MUST try with PREFIX64 option before performing heuristic procedures. > > Btw how do you get the IPv4 subnet->Pref64::/n mapping list with this option? I quickly looked the draft and it also seemed to deliver just one Pref64::/n? > >> >Only if an operator chooses to provide these goodies to hosts; I have >> >no evidence that says all operators who deploy NAT64 are ok to allow >> >incoming connections/hosting services/helping hosts to reduce keepalive >> >signaling. I do hope PCP finds its place in networks and helps save >> >battery etc, but it is not something that can be assumed to happen >> >(always). >> >> Med: That's fair. Again, I'm exclusively positioning this discussion in context >> where PCP is deployed. > > Good, and I definitely support deployment of PCP. > >> >This tool perhaps could be PCP - if this WG thinks it is ok to extent >> >PCP for this kind of provisioning purposes - for me this sounds a bit >> >like loading PCP with something that might fit better to DHCPv6. >> >> Med: I disagree: PCP is there to help NAT traversal, returning the PREFIX64 is >> part of that problem. > > Well, ok, I agree and changed my mind on this:) The PCP Server definitely has an interface to NAT64 (unlike DHCPv6 Server), and hence it could ask the Pref64::/n from it (or provision it to NAT64, whatever you guys plan to do). > >> Med: I didn't asked for that. Sorry I was not clear: the scope of this discussion >> is: PCP-enabled networks. > > Thanks, in PCP-enabled networks it is definitely ok to skip heuristics in favor for explicit configuration. > > If you do go forward with explicit option, you could look if you can resolve the "mapping of IPv4 address ranges to IPv6 prefixes" problem. Something better perhaps than asking from PCP Server what is the Pref64::/n for a given IPv4 address.. > > Best regards > > Teemu > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From dwing@cisco.com Fri Sep 7 16:35:04 2012 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C55A221E8084; Fri, 7 Sep 2012 16:35:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l7wJTyzV7mkL; Fri, 7 Sep 2012 16:35:04 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 39C3F21F8581; Fri, 7 Sep 2012 16:35:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=966; q=dns/txt; s=iport; t=1347060904; x=1348270504; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=YLmnc2BtpIsP1eem+xPQRNum+HxcSxFl50wiMNQvu2c=; b=ECrWqHlSSZJjH5hZxbWMa2TZ2nVYATP8WIRAtgA7S+dlYZdER59ZDbxI 7eV+RYPRblYawgDtVIJHZRwJIiH179OyXmpaKecXQKiYd0DkrpH+QRomv RoYpI80s8dz3lQt8ihx3CIxn6Q4mPSQ/r6aiCZM99m42Yh1SSymdihRNl Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgoFAGyDSlCrRDoG/2dsb2JhbABFq1SPfYEHgiEBAQQICgEXED8NAwIJDzcZIxsBAQQBHReHbZsaoBiLF4YvA4hThQ6WMYFngwQ X-IronPort-AV: E=Sophos;i="4.80,388,1344211200"; d="scan'208";a="54476878" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 07 Sep 2012 23:35:03 +0000 Received: from dwingWS ([10.32.240.195]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q87NZ3S0023869; Fri, 7 Sep 2012 23:35:03 GMT From: "Dan Wing" To: , , References: <94C682931C08B048B7A8645303FDC9F36E57B08381@PUEXCB1B.nanterre.francetelecom.fr> <504898BD.7000702@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E57B08524@PUEXCB1B.nanterre.francetelecom.fr> <5048AC63.50700@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E57B085C5@PUEXCB1B.nanterre.francetelecom.fr> <5048C127.50704@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E57B08650@PUEXCB1B.nanterre.francetelecom.fr> <916CE6CF87173740BC8A2CE4430969620444ABB8@008-AM1MPN1-053.mgdnok.nokia.com> <94C682931C08B048B7A8645303FDC9F36E57B08727@PUEXCB1B.nanterre.francetelecom.fr> <916CE6CF87173740BC8A2CE44309696204453374@008-AM1MPN1-052.mgdnok.nokia.com> In-Reply-To: <916CE6CF87173740BC8A2CE44309696204453374@008-AM1MPN1-052.mgdnok.nokia.com> Date: Fri, 7 Sep 2012 16:35:04 -0700 Message-ID: <04f301cd8d51$68b6cbd0$3a246370$@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: Ac2MREsThTb5jn5dQvm14yeG1MbvVgAdLJUwAAPMTNAAAgZYgAADCg4QAB0jEWA= Content-Language: en-us Cc: pcp@ietf.org, behave@ietf.org Subject: Re: [BEHAVE] [pcp] PREFIX64 PCP Option for NAT64: draft-boucadair-pcp-nat64-prefix64-option 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, 07 Sep 2012 23:35:04 -0000 ... > > * PCP is needed for NAT64 to accept incoming connections/hosting > > servers/reduce keepalive messages/etc. > > Only if an operator chooses to provide these goodies to hosts; I have > no evidence that says all operators who deploy NAT64 are ok to allow > incoming connections/hosting services/helping hosts to reduce keepalive > signaling. I do hope PCP finds its place in networks and helps save > battery etc, but it is not something that can be assumed to happen > (always). The MAP Opcode allows those incoming connections, which is separate from the PEER Opcode to optimize keepalives. It would be annoying to implementers, but I could imagine some network operators deploying a PCP server with PEER enabled but with MAP disabled. I would imagine the network operators that, today, find excuses to rotate their subscriber's IP addresses every day would be among those operators that will not allow MAP but might allow PEER. -d From mohamed.boucadair@orange.com Tue Sep 11 02:50:11 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 0D39F21F8769; Tue, 11 Sep 2012 02:50:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MqY-C-MAjCcr; Tue, 11 Sep 2012 02:50:10 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 260C221F8764; Tue, 11 Sep 2012 02:50:09 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id D40052640EB; Tue, 11 Sep 2012 11:50:08 +0200 (CEST) Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id B3DA94C0C8; Tue, 11 Sep 2012 11:50:08 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Tue, 11 Sep 2012 11:50:04 +0200 From: To: "teemu.savolainen@nokia.com" , "simon.perreault@viagenie.ca" Date: Tue, 11 Sep 2012 11:50:03 +0200 Thread-Topic: [pcp] PREFIX64 PCP Option for NAT64: draft-boucadair-pcp-nat64-prefix64-option Thread-Index: Ac2MREsThTb5jn5dQvm14yeG1MbvVgAdLJUwAAPMTNAAAgZYgAADCg4QAAPxyvAAAq5H8ADA9/qg Message-ID: <94C682931C08B048B7A8645303FDC9F36E5A10BF4F@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E57B08381@PUEXCB1B.nanterre.francetelecom.fr> <504898BD.7000702@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E57B08524@PUEXCB1B.nanterre.francetelecom.fr> <5048AC63.50700@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E57B085C5@PUEXCB1B.nanterre.francetelecom.fr> <5048C127.50704@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E57B08650@PUEXCB1B.nanterre.francetelecom.fr> <916CE6CF87173740BC8A2CE4430969620444ABB8@008-AM1MPN1-053.mgdnok.nokia.com> <94C682931C08B048B7A8645303FDC9F36E57B08727@PUEXCB1B.nanterre.francetelecom.fr> <916CE6CF87173740BC8A2CE44309696204453374@008-AM1MPN1-052.mgdnok.nokia.com> <94C682931C08B048B7A8645303FDC9F36E57B08811@PUEXCB1B.nanterre.francetelecom.fr> <916CE6CF87173740BC8A2CE4430969620445C977@008-AM1MPN1-053.mgdnok.nokia.com> In-Reply-To: <916CE6CF87173740BC8A2CE4430969620445C977@008-AM1MPN1-053.mgdnok.nokia.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.6.19.115414 Cc: "pcp@ietf.org" , "behave@ietf.org" Subject: Re: [BEHAVE] [pcp] PREFIX64 PCP Option for NAT64: draft-boucadair-pcp-nat64-prefix64-option 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, 11 Sep 2012 09:50:11 -0000 Hi Teemu, Please see inline.=20 Cheers, Med=20 >-----Message d'origine----- >De : teemu.savolainen@nokia.com [mailto:teemu.savolainen@nokia.com]=20 >Envoy=E9 : vendredi 7 septembre 2012 15:17 >=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP; simon.perreault@viagenie.ca >Cc : pcp@ietf.org; behave@ietf.org >Objet : RE: [pcp] PREFIX64 PCP Option for NAT64:=20 >draft-boucadair-pcp-nat64-prefix64-option > >Hi, [...] > >> Med: I didn't asked for that. Sorry I was not clear: the=20 >scope of this discussion >> is: PCP-enabled networks. > >Thanks, in PCP-enabled networks it is definitely ok to skip=20 >heuristics in favor for explicit configuration.=20 > >If you do go forward with explicit option, you could look if=20 >you can resolve the "mapping of IPv4 address ranges to IPv6=20 >prefixes" problem. Something better perhaps than asking from=20 >PCP Server what is the Pref64::/n for a given IPv4 address.. Med: Thanks. I have just submited a new version which takes into account th= is comment. An OpCode is now supported to convey a list of {IPv4 subnet, P= refix64::/n}. The new version is available at: http://tools.ietf.org/html/d= raft-boucadair-pcp-nat64-prefix64-option-01 > >Best regards > > Teemu >= From dwing@cisco.com Thu Sep 20 11:36:49 2012 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD92B21F8752 for ; Thu, 20 Sep 2012 11:36:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HOu+oACvBdiD for ; Thu, 20 Sep 2012 11:36:48 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 3DA8821F874C for ; Thu, 20 Sep 2012 11:36:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2865; q=dns/txt; s=iport; t=1348166208; x=1349375808; h=from:to:subject:date:message-id:mime-version: content-transfer-encoding; bh=/93KE/KPe0+/8phOD61MSOwobP36/g7P5XsesMhycyQ=; b=Ztd7cFVkk0fvf3ZqPaEMlje/Zc9HE6yNMj5B9Irmcw7mO8BorHd3jiob VMCg/rirgTe+/RYzf5x4malrvE/2UIXgszsIfehPPHsjvHeX/FlOftwlg KYLV2W6vmxwrNbISe2ikEMJxl74N6BERhXc/DVjsOu+s33KmfiTBRsGMn Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AigFAKphW1CtJV2d/2dsb2JhbABFrSWQBYEIgiABAQEECAoBFxBLAQUJDwIEAQEoICMKBwEBBQQBBBMJAheHYQuYZ4EooBSLHBqDCIMgA4hWhRCJEo0kgWmDB4FD X-IronPort-AV: E=Sophos;i="4.80,455,1344211200"; d="scan'208";a="123465456" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-1.cisco.com with ESMTP; 20 Sep 2012 18:36:47 +0000 Received: from dwingWS ([10.32.240.198]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q8KIalP1005278 for ; Thu, 20 Sep 2012 18:36:47 GMT From: "Dan Wing" To: Date: Thu, 20 Sep 2012 11:36:47 -0700 Message-ID: <11c001cd975e$e4c1ab70$ae450250$@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: Ac2XXryEzk+BLRymTgWW27uh+Z/beAAAAV0w Content-Language: en-us Subject: [BEHAVE] FW: pcp-base-27: Mapping Nonce change 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, 20 Sep 2012 18:36:49 -0000 FYI. This has some impact on draft-ietf-behave-lsn-requirements. -d -----Original Message----- From: Dan Wing [mailto:dwing@cisco.com] Sent: Thursday, September 20, 2012 11:36 AM To: 'pcp@ietf.org' Cc: 'pcp-chairs@tools.ietf.org' Subject: pcp-base-27: Mapping Nonce change Based on IESG feedback and coordinating these changes with draft-ietf-behave-lsn-requirements, an updated version of pcp-base has been posted. The proposed change to Mapping Nonce was announced on August 17, "strengthening PCP with Mapping Nonce", http://www.ietf.org/mail-archive/web/pcp/current/msg02229.html. The significant changes are: 1. Once a MAP or PEER opcode is processed by the PCP server, subsequent changes to that mapping have to use the same Mapping Nonce. This closes the attack that led to REQ-9-A in draft-ietf-behave-lsn-requirements-09. However, this change has a side-effect of disabling two previous MAP features: (a) the ability of a PCP client to delete (clear) PCP mappings created by a previous PCP client using the same IP address, and (b) ability for a PCP client to delete all of the mappings it created by sending one MAP message. To accommodate the loss of (a), pcp-base-27 recommends that when a host joins a network, the network device that allowed the device to join the network should flush PCP-created mappings and non-PCP-created mappings (e.g., DHCP, 802.1x, PPPoE). Towards that end, Stuart has written draft-cheshire-pcp-expire, and there are many other ways to clear PCP and implicit mapping state in NATs and firewalls when a device joins a network. (b) was just an optimization; the PCP client can delete MAP created mappings by issuing separate requests, similar to how it issued separate MAP requests to create the mappings. 2. Clarified that PEER can reduce a mapping lifetime to the same lifetime as active, bi-directional traffic. This allows PEER to extend lifetime of a mapping, then later using the same Mapping Nonce, PEER can rescind (revert) that lifetime extension so the mapping is treated as if PEER was never used. Another significant change, unrelated to Mapping Nonce, is that Mapping Update is now required. This means the PCP server now MUST inform the PCP client of any changes to a mapping; earlier versions of the specification said this was merely a SHOULD. This change makes PCP a more reliable protocol. There are a lot of other minor changes from IESG feedback and from other reviewers. See the changelog in Section B.1, or the side-by-side diffs. URL: http://www.ietf.org/internet-drafts/draft-ietf-pcp-base-27.txt Status: http://datatracker.ietf.org/doc/draft-ietf-pcp-base Htmlized: http://tools.ietf.org/html/draft-ietf-pcp-base-27 Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-pcp-base-27 -d From dthaler@microsoft.com Thu Sep 20 14:08:01 2012 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE1D621F864D for ; Thu, 20 Sep 2012 14:08:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.982 X-Spam-Level: X-Spam-Status: No, score=-103.982 tagged_above=-999 required=5 tests=[AWL=-0.384, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lv8kdvvnspSM for ; Thu, 20 Sep 2012 14:08:01 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe001.messaging.microsoft.com [213.199.154.204]) by ietfa.amsl.com (Postfix) with ESMTP id ED71821F8648 for ; Thu, 20 Sep 2012 14:08:00 -0700 (PDT) Received: from mail92-am1-R.bigfish.com (10.3.201.233) by AM1EHSOBE004.bigfish.com (10.3.204.24) with Microsoft SMTP Server id 14.1.225.23; Thu, 20 Sep 2012 21:07:59 +0000 Received: from mail92-am1 (localhost [127.0.0.1]) by mail92-am1-R.bigfish.com (Postfix) with ESMTP id F0FAC2A00EF for ; Thu, 20 Sep 2012 21:07:59 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: 1 X-BigFish: VS1(zzc85fhd6f1izz1202h1d1ah1d2ahzz17326ah8275bh8275dhz2fh2a8h668h839hd25hf0ah107ah1288h12a5h12bdh137ah1155h) Received-SPF: pass (mail92-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=TK5EX14HUBC103.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail92-am1 (localhost.localdomain [127.0.0.1]) by mail92-am1 (MessageSwitch) id 1348175277724910_31526; Thu, 20 Sep 2012 21:07:57 +0000 (UTC) Received: from AM1EHSMHS007.bigfish.com (unknown [10.3.201.241]) by mail92-am1.bigfish.com (Postfix) with ESMTP id AF7034C0092 for ; Thu, 20 Sep 2012 21:07:57 +0000 (UTC) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS007.bigfish.com (10.3.207.107) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 20 Sep 2012 21:07:56 +0000 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) with Microsoft SMTP Server (TLS) id 14.2.318.3; Thu, 20 Sep 2012 21:07:45 +0000 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) with Microsoft SMTP Server (TLS) id 14.2.318.3; Thu, 20 Sep 2012 14:07:44 -0700 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.129]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.02.0318.003; Thu, 20 Sep 2012 14:07:44 -0700 From: Dave Thaler To: "behave@ietf.org" Thread-Topic: Last call: draft-ietf-behave-nat64-discovery-heuristic-11 Thread-Index: Ac2Xc7cV3cKg/vUUTUejTO5rsFUFEw== Date: Thu, 20 Sep 2012 21:07:44 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B7C04CE@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.90] Content-Type: multipart/alternative; boundary="_000_9B57C850BB53634CACEC56EF4853FF653B7C04CETK5EX14MBXW604w_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-11 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, 20 Sep 2012 21:08:02 -0000 --_000_9B57C850BB53634CACEC56EF4853FF653B7C04CETK5EX14MBXW604w_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All comments received during the first WGLC (on -09) have been resolved. This email initiates another two-week Working Group Last Call on draft-ietf-behave-nat64-discovery-heuristic-11, to conclude Thursday October 4th. We need at least 5 reviewers to comment on the doc (even if just saying "looks good"). -Dave Thaler --_000_9B57C850BB53634CACEC56EF4853FF653B7C04CETK5EX14MBXW604w_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All comments received during the first WGLC (on -09) have = been

resolved.

This email initiates another two-week Working Group Last C= all

on draft-ietf-behave-nat64-discovery-heuristic-11, to conc= lude

Thursday October 4^th.

We need at least 5 reviewers to comment on the doc

(even if just saying "looks good").

-Dave Thaler

--_000_9B57C850BB53634CACEC56EF4853FF653B7C04CETK5EX14MBXW604w_-- From todd@apx-labs.com Thu Sep 20 20:38:05 2012 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CC2C21F84D7 for ; Thu, 20 Sep 2012 20:38:05 -0700 (PDT) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lkcHy9c86DBX for ; Thu, 20 Sep 2012 20:38:04 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe003.messaging.microsoft.com [65.55.88.13]) by ietfa.amsl.com (Postfix) with ESMTP id A8C8A21F84B6 for ; Thu, 20 Sep 2012 20:38:04 -0700 (PDT) Received: from mail89-tx2-R.bigfish.com (10.9.14.250) by TX2EHSOBE006.bigfish.com (10.9.40.26) with Microsoft SMTP Server id 14.1.225.23; Fri, 21 Sep 2012 03:38:03 +0000 Received: from mail89-tx2 (localhost [127.0.0.1]) by mail89-tx2-R.bigfish.com (Postfix) with ESMTP id 9248E3E012F for ; Fri, 21 Sep 2012 03:38:03 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.234.133; KIP:(null); UIP:(null); IPV:NLI; H:SN2PRD0610HT003.namprd06.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -1 X-BigFish: PS-1(zzc85fh4015Izz1202h1d2ahzz17326ah8275bh8275dhz2fh2a8h668h839hd25hf0ah107ah1288h12a5h12bdh137ah1155h) Received-SPF: pass (mail89-tx2: domain of apx-labs.com designates 157.56.234.133 as permitted sender) client-ip=157.56.234.133; envelope-from=todd@apx-labs.com; helo=SN2PRD0610HT003.namprd06.prod.outlook.com ; .outlook.com ; Received: from mail89-tx2 (localhost.localdomain [127.0.0.1]) by mail89-tx2 (MessageSwitch) id 1348198681554072_6797; Fri, 21 Sep 2012 03:38:01 +0000 (UTC) Received: from TX2EHSMHS026.bigfish.com (unknown [10.9.14.237]) by mail89-tx2.bigfish.com (Postfix) with ESMTP id 7B3656005D for ; Fri, 21 Sep 2012 03:38:01 +0000 (UTC) Received: from SN2PRD0610HT003.namprd06.prod.outlook.com (157.56.234.133) by TX2EHSMHS026.bigfish.com (10.9.99.126) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 21 Sep 2012 03:38:00 +0000 Received: from SN2PRD0610MB372.namprd06.prod.outlook.com ([169.254.7.182]) by SN2PRD0610HT003.namprd06.prod.outlook.com ([10.255.117.38]) with mapi id 14.16.0190.008; Fri, 21 Sep 2012 03:38:00 +0000 From: Todd Herman To: "behave@ietf.org" Thread-Topic: Couple questions regarding RFC 5389 (STUN) Thread-Index: Ac2XqWNw4N+FWpCpSpCoQq4PO0uhjw== Date: Fri, 21 Sep 2012 03:37:59 +0000 Message-ID: <980973149D509B4AA117C3CE035BACA92F828A5F@SN2PRD0610MB372.namprd06.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [108.45.33.82] Content-Type: multipart/alternative; boundary="_000_980973149D509B4AA117C3CE035BACA92F828A5FSN2PRD0610MB372_" MIME-Version: 1.0 X-OriginatorOrg: apx-labs.com Subject: [BEHAVE] Couple questions regarding RFC 5389 (STUN) 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, 21 Sep 2012 03:39:14 -0000 --_000_980973149D509B4AA117C3CE035BACA92F828A5FSN2PRD0610MB372_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have a few questions, clarifications really, regarding RFC 5389. Is this= the correct place to ask them? Thanks, Todd Herman --_000_980973149D509B4AA117C3CE035BACA92F828A5FSN2PRD0610MB372_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have a few questions, clarifications really, regar= ding RFC 5389. Is this the correct place to ask them?

Thanks,

Todd Herman

--_000_980973149D509B4AA117C3CE035BACA92F828A5FSN2PRD0610MB372_-- From petithug@acm.org Thu Sep 20 22:49:49 2012 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47E1E21F8555 for ; Thu, 20 Sep 2012 22:49:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.335 X-Spam-Level: X-Spam-Status: No, score=-102.335 tagged_above=-999 required=5 tests=[AWL=0.265, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yRRb++IbNFMX for ; Thu, 20 Sep 2012 22:49:48 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 486FE21F8551 for ; Thu, 20 Sep 2012 22:49:48 -0700 (PDT) Received: from [IPv6:2601:9:4b80:32:d5:1a77:d45:96c1] (unknown [IPv6:2601:9:4b80:32:d5:1a77:d45:96c1]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 41BDB20B8F; Fri, 21 Sep 2012 05:49:46 +0000 (UTC) Message-ID: <505BFFF7.4040801@acm.org> Date: Thu, 20 Sep 2012 22:49:43 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.6esrpre) Gecko/20120817 Icedove/10.0.6 MIME-Version: 1.0 To: Todd Herman References: <980973149D509B4AA117C3CE035BACA92F828A5F@SN2PRD0610MB372.namprd06.prod.outlook.com> In-Reply-To: <980973149D509B4AA117C3CE035BACA92F828A5F@SN2PRD0610MB372.namprd06.prod.outlook.com> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "behave@ietf.org" Subject: Re: [BEHAVE] Couple questions regarding RFC 5389 (STUN) 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, 21 Sep 2012 05:49:49 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 09/20/2012 08:37 PM, Todd Herman wrote: > I have a few questions, clarifications really, regarding RFC 5389. Is this > the correct place to ask them? Yes. - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJQW//1AAoJECnERZXWan7EyHgP/RXiw6deUa+hVrF0yiAPRVhD Q0xeXZaGkaDZ4GifKIgbIsG77VdMypBgXB/rTdYx6BbvrEhfzA5ZRH260Tm1u12F vYHNZ8tl7AeN1fOxZSvEYNj9li3qhmH81BCHdeNhWth1z+aFU08RdwiDB9m2dl7H 2MBfyUAhg57JuTNdjrqtMmm4iHTiYAh2pwYGTP4bsb2st8JFohiHJrPdoF1wEEEE +uOffHeyvAPNitPAx9R1JmYwlheC78tsaSJDgc8EOv/XIg8nrYqm0wRYOPTALUpr 3oxCMojE0WDvQKNVbBnW9StnNclIoD1P7mTGYXA7dyXyPgWzEKoilERAlKn33AJh BfUJabNwmNYK5XUXm6JoQgLuxUzDwuhJGXQuwqYeAF8NfV0OTn45dIAx4GmZm1Pq XpilPST4hOPiLnut4p9rSJbgLtiIek5Fji2aUwua17QOdBPZvUxTmDvgI3kzYuYC LeJCQyct9bSzzVxe1wy7tp308ROKrzmQ4NEHXanCRxHXRcxtoJutdcaaRK6dijwD IYrobxvGfy6xC+NCSXj1ZBXM03G3H9A+bF08zGVq/QmF2unflqaSjvpv16XwLoBH U+jQXATKiOgZVxLHFjGvfw8KE3BO0RQgtjbddms+/TpJOVWT4l9zmmtC4lUMaOkU N4FvHklM5l2oztkOuCO9 =z8GB -----END PGP SIGNATURE----- From todd@apx-labs.com Fri Sep 21 05:40: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 DA64621F877D for ; Fri, 21 Sep 2012 05:40:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.234 X-Spam-Level: X-Spam-Status: No, score=-6.234 tagged_above=-999 required=5 tests=[AWL=-0.235, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UyTZnozc1IFI for ; Fri, 21 Sep 2012 05:40:00 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe005.messaging.microsoft.com [65.55.88.15]) by ietfa.amsl.com (Postfix) with ESMTP id CBDC521F877C for ; Fri, 21 Sep 2012 05:39:59 -0700 (PDT) Received: from mail107-tx2-R.bigfish.com (10.9.14.240) by TX2EHSOBE013.bigfish.com (10.9.40.33) with Microsoft SMTP Server id 14.1.225.23; Fri, 21 Sep 2012 12:39:58 +0000 Received: from mail107-tx2 (localhost [127.0.0.1]) by mail107-tx2-R.bigfish.com (Postfix) with ESMTP id D99AB4C00D6; Fri, 21 Sep 2012 12:39:58 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.234.133; KIP:(null); UIP:(null); IPV:NLI; H:SN2PRD0610HT003.namprd06.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -37 X-BigFish: PS-37(zzbb2dI98dI154cP9371Ic89bh542M1432I62a3Id6f1izz1202h1d2ahzz1033IL17326ah8275bh8275dhz2fh2a8h668h839h93fhd25hf0ah107ah1288h12a5h12a9h12bdh137ah1155h) Received-SPF: pass (mail107-tx2: domain of apx-labs.com designates 157.56.234.133 as permitted sender) client-ip=157.56.234.133; envelope-from=todd@apx-labs.com; helo=SN2PRD0610HT003.namprd06.prod.outlook.com ; .outlook.com ; Received: from mail107-tx2 (localhost.localdomain [127.0.0.1]) by mail107-tx2 (MessageSwitch) id 1348231196395408_31518; Fri, 21 Sep 2012 12:39:56 +0000 (UTC) Received: from TX2EHSMHS037.bigfish.com (unknown [10.9.14.254]) by mail107-tx2.bigfish.com (Postfix) with ESMTP id 53CA13E0045; Fri, 21 Sep 2012 12:39:56 +0000 (UTC) Received: from SN2PRD0610HT003.namprd06.prod.outlook.com (157.56.234.133) by TX2EHSMHS037.bigfish.com (10.9.99.137) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 21 Sep 2012 12:39:52 +0000 Received: from SN2PRD0610MB372.namprd06.prod.outlook.com ([169.254.7.182]) by SN2PRD0610HT003.namprd06.prod.outlook.com ([10.255.117.38]) with mapi id 14.16.0190.008; Fri, 21 Sep 2012 12:39:51 +0000 From: Todd Herman To: Marc Petit-Huguenin Thread-Topic: [BEHAVE] Couple questions regarding RFC 5389 (STUN) Thread-Index: Ac2XqWNw4N+FWpCpSpCoQq4PO0uhjwAE4JyAAA3Oj6A= Date: Fri, 21 Sep 2012 12:39:50 +0000 Message-ID: <980973149D509B4AA117C3CE035BACA92F829F2D@SN2PRD0610MB372.namprd06.prod.outlook.com> References: <980973149D509B4AA117C3CE035BACA92F828A5F@SN2PRD0610MB372.namprd06.prod.outlook.com> <505BFFF7.4040801@acm.org> In-Reply-To: <505BFFF7.4040801@acm.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [108.45.33.82] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: apx-labs.com Cc: "behave@ietf.org" Subject: Re: [BEHAVE] Couple questions regarding RFC 5389 (STUN) 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, 21 Sep 2012 12:40:01 -0000 QXdlc29tZS4gIFNlY3Rpb24gNy4yLjEgb2YgdGhlIFJGQyBkaXNjdXNzZXMgdXNpbmcgYSBSZXRy YW5zbWlzc2lvbiBUaW1lb3V0IChSVE8pIGNhbGN1bGF0ZWQgYWNjb3JkaW5nIHRvIFJGQyAyOTg4 IHdpdGggMiBtaW5vciBhbHRlcmF0aW9ucy4gIEkgaGF2ZSByZXZpZXdlZCB0aGlzIHNlY3Rpb24g YW5kIFJGQyAyOTg4IGFuZCBJIGFtIGhhdmluZyBhIGRpZmZpY3VsdCB0aW1lIGdldHRpbmcgaXQg dG8gd29yayBvdXQgYXMgZXhwZWN0ZWQuICANCg0KVGhlIGxhc3QgcGFyYWdyYXBoIGluIHNlY3Rp b24gNy4yLjEgcHJvdmlkZXMgYW4gZXhhbXBsZSB0aGF0IHNheXMgdGhhdCBpZiBhbiBSVE8gb2Yg NTAwbXMgaXMgdXNlZCB0aGUgcmVxdWVzdHMgd291bGQgYmUgc2VudCBhdCAwLCA1MDAsIDE1MDAs IDM1MDAsIDc1MDAsIDE1NTAwIGFuZCAzMTUwMC4gIFdoZXJlIGFyZSB0aGVzZSB2YWx1ZXMgY29t aW5nIGZyb20/ICBJIGdhdGhlciBmcm9tIHRoZSBzdGF0ZW1lbnQgdGhhdCBSVE8gaGFzIGFscmVh ZHkgYmVlbiBjYWxjdWxhdGVkIHNvIHRoYXQgc2hvdWxkIG1lYW4gd2UgYXJlIG5vdCB1c2luZyB0 aGUgZm9ybXVsYXMgaW4gUkZDIDI5ODguICBSRkMgMjk4OCBkb2VzIHN0YXRlIHRoYXQgeW91IHNo b3VsZCBzdGFydCB3aXRoIDUwMCBtcyBmb3IgdGhlIGZpcnN0IHRpbWUgYW55d2F5LiAgSXQgaXMg ZWFzeSBlbm91Z2ggdG8gc2VlIHRoYXQgdGhvc2UgdmFsdWVzIGFyZSBiZWluZyBiYWNrZWQgb2Zm IGFuZCBzZWVtIHRvIHVzZSB0aGUgZm9ybXVsYSBSVE8gPSBSVE8gKiAyICsgUlRPIGJ1dCBJIGRv bid0IHNlZSB3aGVyZSB0aGlzIGZvcm11bGEgaXMgbWVudGlvbmVkIGluIFJGQyA1Mzg5Lg0KDQpD b3VsZCBzb21lb25lIGNsZWFyIHVwIHRoaXMgY29uZnVzaW9uICBsaXR0bGUgZm9yIG1lIHBsZWFz ZT8NCg0KVG9kZCBIZXJtYW4NClNlbmlvciBTb2Z0d2FyZSBFbmdpbmVlcg0KwqANCg0KPiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBNYXJjIFBldGl0LUh1Z3VlbmluIFttYWls dG86cGV0aXRodWdAYWNtLm9yZ10NCj4gU2VudDogRnJpZGF5LCBTZXB0ZW1iZXIgMjEsIDIwMTIg MTo1MCBBTQ0KPiBUbzogVG9kZCBIZXJtYW4NCj4gQ2M6IGJlaGF2ZUBpZXRmLm9yZw0KPiBTdWJq ZWN0OiBSZTogW0JFSEFWRV0gQ291cGxlIHF1ZXN0aW9ucyByZWdhcmRpbmcgUkZDIDUzODkgKFNU VU4pDQo+IA0KPiAtLS0tLUJFR0lOIFBHUCBTSUdORUQgTUVTU0FHRS0tLS0tDQo+IEhhc2g6IFNI QTI1Ng0KPiANCj4gT24gMDkvMjAvMjAxMiAwODozNyBQTSwgVG9kZCBIZXJtYW4gd3JvdGU6DQo+ ID4gSSBoYXZlIGEgZmV3IHF1ZXN0aW9ucywgY2xhcmlmaWNhdGlvbnMgcmVhbGx5LCByZWdhcmRp bmcgUkZDIDUzODkuICBJcw0KPiA+IHRoaXMgdGhlIGNvcnJlY3QgcGxhY2UgdG8gYXNrIHRoZW0/ DQo+IA0KPiBZZXMuDQo+IA0KPiAtIC0tDQo+IE1hcmMgUGV0aXQtSHVndWVuaW4NCj4gRW1haWw6 IG1hcmNAcGV0aXQtaHVndWVuaW4ub3JnDQo+IEJsb2c6IGh0dHA6Ly9ibG9nLm1hcmMucGV0aXQt aHVndWVuaW4ub3JnDQo+IFByb2ZpbGU6IGh0dHA6Ly93d3cubGlua2VkaW4uY29tL2luL3BldGl0 aHVnDQo+IC0tLS0tQkVHSU4gUEdQIFNJR05BVFVSRS0tLS0tDQo+IFZlcnNpb246IEdudVBHIHYx LjQuMTIgKEdOVS9MaW51eCkNCj4gDQo+IGlRSWNCQUVCQ0FBR0JRSlFXLy8xQUFvSkVDbkVSWlhX YW43RXlIZ1AvUlhpdzZkZVVhK2hWckYweWlBUFINCj4gVmhEDQo+IFEweGVYWmFHa2FEWjRHaWZL SWdiSXNHNzdWZE15cEJnWEIvclRkWXg2QmJ2ckVoZnpBNVpSSDI2MFRtMXUxMg0KPiBGDQo+IHZZ SE5aOHRsN0FlTjFmT3haU3ZFWU5qOWxpM3FobUg4MUJDSGRlTmhXdGgxeithRlUwOFJkd2lEQjlt MmRsDQo+IDdIDQo+IDJNQmZ5VUFoZzU3SnVUTmRqcnF0TW1tNGlIVGlZQWgycHdZR1RQNGJzYjJz dDhKRm9oaUhKclBkb0Yxd0VFRQ0KPiBFDQo+ICt1T2ZmSGV5dkFQTml0UEF4OVIxSm1Zd2xoZUM3 OHRzYVNKRGdjOEVPdi9YSWc4bnJZcW0wd1JZT1BUQUxVcA0KPiByDQo+IDNveENNb2pFMFdEdlFL TlZiQm5XOVN0bk5jbElvRDFQN21UR1lYQTdkeVh5UGdXekVLb2lsRVJBbEtuMw0KPiAzQUpoDQo+ IEJmVUphYk53bU5ZSzVYVVhtNkpvUWdMdXhVekR3dWhKR1hRdXdxWWVBRjhOZlYwT1RuNDVkSUF4 NEcNCj4gbVptMVBxDQo+IFhwaWxQU1Q0aE9QaUxudXQ0cDlyU0piZ0x0aUllazVGamkyYVV3dWEx N1FPZEJQWnZVeFRtRHZnSTNrell1WUMNCj4gTGVKQ1F5Y3Q5YlN6elZ4ZTF3eTd0cDMwOFJPS3J6 bVE0TkVIWGFuQ1J4SFhSY3h0b0p1dGRjYWFSSzZkaWp3DQo+IEQNCj4gSVlyb2J4dkdmeTZ4QytO Q1NYajFaQlhNMDNHM0g5QStiRjA4ekdWcS9RbUYydW5mbHFhU2p2cHYxNlh3TG8NCj4gQkgNCj4g VStqUVhBVEtpT2daVnhMSEZqR3ZmdzhLRTNCTzBSUWd0amJkZG1zKy9UcEpPVldUNGw5em1tdEM0 bFVNYQ0KPiBPa1UNCj4gTjRGdkhrbE01bDJvenRrT3VDTzkNCj4gPXo4R0INCj4gLS0tLS1FTkQg UEdQIFNJR05BVFVSRS0tLS0tDQoNCg== From simon.perreault@viagenie.ca Fri Sep 21 05:59:53 2012 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F17921F870B for ; Fri, 21 Sep 2012 05:59:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eJpE7p1xMc2R for ; Fri, 21 Sep 2012 05:59:53 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id E23D521F8705 for ; Fri, 21 Sep 2012 05:59:52 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:987e:53d3:3d57:e57c]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 66175425DB for ; Fri, 21 Sep 2012 08:59:52 -0400 (EDT) Message-ID: <505C64C7.6030001@viagenie.ca> Date: Fri, 21 Sep 2012 08:59:51 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120828 Thunderbird/15.0 MIME-Version: 1.0 To: behave@ietf.org References: <980973149D509B4AA117C3CE035BACA92F828A5F@SN2PRD0610MB372.namprd06.prod.outlook.com> <505BFFF7.4040801@acm.org> <980973149D509B4AA117C3CE035BACA92F829F2D@SN2PRD0610MB372.namprd06.prod.outlook.com> In-Reply-To: <980973149D509B4AA117C3CE035BACA92F829F2D@SN2PRD0610MB372.namprd06.prod.outlook.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [BEHAVE] Couple questions regarding RFC 5389 (STUN) 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, 21 Sep 2012 12:59:53 -0000 Le 2012-09-21 08:39, Todd Herman a écrit : > The last paragraph in section 7.2.1 provides an example that says > that if an RTO of 500ms is used the requests would be sent at 0, 500, > 1500, 3500, 7500, 15500 and 31500. Where are these values coming > from? I gather from the statement that RTO has already been > calculated so that should mean we are not using the formulas in RFC > 2988. RFC 2988 does state that you should start with 500 ms for the > first time anyway. It is easy enough to see that those values are > being backed off and seem to use the formula RTO = RTO * 2 + RTO but > I don't see where this formula is mentioned in RFC 5389. Section 7.2.1, second paragraph: A client SHOULD retransmit a STUN request message starting with an interval of RTO ("Retransmission TimeOut"), doubling after each retransmission. That's it. Value Delta 0 500 500 1500 1000 3500 2000 7500 4000 15500 8000 31500 16000 See? The delta doubles at each line. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From todd@apx-labs.com Fri Sep 21 07:09:20 2012 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE9F221F8830 for ; Fri, 21 Sep 2012 07:09:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pkB6rUC6iz6v for ; Fri, 21 Sep 2012 07:09:19 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe001.messaging.microsoft.com [216.32.181.181]) by ietfa.amsl.com (Postfix) with ESMTP id B142321F882C for ; Fri, 21 Sep 2012 07:09:19 -0700 (PDT) Received: from mail197-ch1-R.bigfish.com (10.43.68.239) by CH1EHSOBE018.bigfish.com (10.43.70.68) with Microsoft SMTP Server id 14.1.225.23; Fri, 21 Sep 2012 14:09:17 +0000 Received: from mail197-ch1 (localhost [127.0.0.1]) by mail197-ch1-R.bigfish.com (Postfix) with ESMTP id 57926402F1; Fri, 21 Sep 2012 14:09:17 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.234.133; KIP:(null); UIP:(null); IPV:NLI; H:SN2PRD0610HT004.namprd06.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -27 X-BigFish: PS-27(zz9371Ic89bh936eI542M1432Id6f1izz1202h1d2ahzz1033IL17326ah8275dhz2fh2a8h668h839h93fhd25hf0ah107ah1288h12a5h12a9h12bdh137ah1155h) Received-SPF: pass (mail197-ch1: domain of apx-labs.com designates 157.56.234.133 as permitted sender) client-ip=157.56.234.133; envelope-from=todd@apx-labs.com; helo=SN2PRD0610HT004.namprd06.prod.outlook.com ; .outlook.com ; Received: from mail197-ch1 (localhost.localdomain [127.0.0.1]) by mail197-ch1 (MessageSwitch) id 1348236556132857_23932; Fri, 21 Sep 2012 14:09:16 +0000 (UTC) Received: from CH1EHSMHS035.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.254]) by mail197-ch1.bigfish.com (Postfix) with ESMTP id 13CEA180093; Fri, 21 Sep 2012 14:09:16 +0000 (UTC) Received: from SN2PRD0610HT004.namprd06.prod.outlook.com (157.56.234.133) by CH1EHSMHS035.bigfish.com (10.43.70.35) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 21 Sep 2012 14:09:13 +0000 Received: from SN2PRD0610MB372.namprd06.prod.outlook.com ([169.254.7.182]) by SN2PRD0610HT004.namprd06.prod.outlook.com ([10.255.117.39]) with mapi id 14.16.0190.008; Fri, 21 Sep 2012 14:09:10 +0000 From: Todd Herman To: Simon Perreault , "behave@ietf.org" Thread-Topic: [BEHAVE] Couple questions regarding RFC 5389 (STUN) Thread-Index: Ac2XqWNw4N+FWpCpSpCoQq4PO0uhjwAE4JyAAA3Oj6AAATcigAAB/X7g Date: Fri, 21 Sep 2012 14:09:09 +0000 Message-ID: <980973149D509B4AA117C3CE035BACA92F82A269@SN2PRD0610MB372.namprd06.prod.outlook.com> References: <980973149D509B4AA117C3CE035BACA92F828A5F@SN2PRD0610MB372.namprd06.prod.outlook.com> <505BFFF7.4040801@acm.org> <980973149D509B4AA117C3CE035BACA92F829F2D@SN2PRD0610MB372.namprd06.prod.outlook.com> <505C64C7.6030001@viagenie.ca> In-Reply-To: <505C64C7.6030001@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.73.3.78] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: apx-labs.com Subject: Re: [BEHAVE] Couple questions regarding RFC 5389 (STUN) 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, 21 Sep 2012 14:09:20 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBiZWhhdmUtYm91bmNlc0BpZXRm Lm9yZyBbbWFpbHRvOmJlaGF2ZS1ib3VuY2VzQGlldGYub3JnXSBPbg0KPiBCZWhhbGYgT2YgU2lt b24gUGVycmVhdWx0DQo+IFNlbnQ6IEZyaWRheSwgU2VwdGVtYmVyIDIxLCAyMDEyIDk6MDAgQU0N Cj4gVG86IGJlaGF2ZUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW0JFSEFWRV0gQ291cGxlIHF1 ZXN0aW9ucyByZWdhcmRpbmcgUkZDIDUzODkgKFNUVU4pDQo+IA0KPiBMZSAyMDEyLTA5LTIxIDA4 OjM5LCBUb2RkIEhlcm1hbiBhIMOpY3JpdCA6DQo+ID4gVGhlIGxhc3QgcGFyYWdyYXBoIGluIHNl Y3Rpb24gNy4yLjEgcHJvdmlkZXMgYW4gZXhhbXBsZSB0aGF0IHNheXMgdGhhdA0KPiA+IGlmIGFu IFJUTyBvZiA1MDBtcyBpcyB1c2VkIHRoZSByZXF1ZXN0cyB3b3VsZCBiZSBzZW50IGF0IDAsIDUw MCwgMTUwMCwNCj4gPiAzNTAwLCA3NTAwLCAxNTUwMCBhbmQgMzE1MDAuICBXaGVyZSBhcmUgdGhl c2UgdmFsdWVzIGNvbWluZyBmcm9tPyAgSQ0KPiA+IGdhdGhlciBmcm9tIHRoZSBzdGF0ZW1lbnQg dGhhdCBSVE8gaGFzIGFscmVhZHkgYmVlbiBjYWxjdWxhdGVkIHNvIHRoYXQNCj4gPiBzaG91bGQg bWVhbiB3ZSBhcmUgbm90IHVzaW5nIHRoZSBmb3JtdWxhcyBpbiBSRkMgMjk4OC4gIFJGQyAyOTg4 IGRvZXMNCj4gPiBzdGF0ZSB0aGF0IHlvdSBzaG91bGQgc3RhcnQgd2l0aCA1MDAgbXMgZm9yIHRo ZSBmaXJzdCB0aW1lIGFueXdheS4gIEl0DQo+ID4gaXMgZWFzeSBlbm91Z2ggdG8gc2VlIHRoYXQg dGhvc2UgdmFsdWVzIGFyZSBiZWluZyBiYWNrZWQgb2ZmIGFuZCBzZWVtDQo+ID4gdG8gdXNlIHRo ZSBmb3JtdWxhIFJUTyA9IFJUTyAqIDIgKyBSVE8gYnV0IEkgZG9uJ3Qgc2VlIHdoZXJlIHRoaXMN Cj4gPiBmb3JtdWxhIGlzIG1lbnRpb25lZCBpbiBSRkMgNTM4OS4NCj4gDQo+IFNlY3Rpb24gNy4y LjEsIHNlY29uZCBwYXJhZ3JhcGg6DQo+IA0KPiAgICAgQSBjbGllbnQgU0hPVUxEIHJldHJhbnNt aXQgYSBTVFVOIHJlcXVlc3QgbWVzc2FnZSBzdGFydGluZyB3aXRoIGFuDQo+ICAgICBpbnRlcnZh bCBvZiBSVE8gKCJSZXRyYW5zbWlzc2lvbiBUaW1lT3V0IiksIGRvdWJsaW5nIGFmdGVyIGVhY2gN Cj4gICAgIHJldHJhbnNtaXNzaW9uLg0KPiANCj4gVGhhdCdzIGl0Lg0KPiANCj4gVmFsdWUJRGVs dGENCj4gMA0KPiA1MDAgICAgIDUwMA0KPiAxNTAwCTEwMDANCj4gMzUwMAkyMDAwDQo+IDc1MDAJ NDAwMA0KPiAxNTUwMAk4MDAwDQo+IDMxNTAwCTE2MDAwDQo+IA0KPiBTZWU/IFRoZSBkZWx0YSBk b3VibGVzIGF0IGVhY2ggbGluZS4NCg0KV2hlbiBJIHJlYWQgdGhhdCBwb3J0aW9uLCBJIHNlcGFy YXRlZCB0aGUgInN0YXJ0aW5nIHdpdGggYW4gaW50ZXJ2YWwgb2YgUlRPIiBmcm9tIHRoZSAiYWZ0 ZXIgZWFjaCB0cmFuc21pc3Npb24iIHdoaWNoIGdpdmVzIHlvdSBSVE8gPSBSVE8gKiAyIGZvciBl YWNoIGl0ZXJhdGlvbi4gIEkgZG8gc2VlIHRoYXQgdGhlIGRlbHRhIGRvdWJsZXMgYXQgZWFjaCBs aW5lIGJ1dCBJIGFtIHN0aWxsIG1pc3Npbmcgc29tZXRoaW5nLiAgV2hlcmUgZG9lcyB0aGUgb3Ro ZXIgcG9ydGlvbiBvZiB0aGUgdmFsdWUgY29tZSBmcm9tPyAgSXQgYXBwZWFycyB0byBiZSBSVE8g PSBSVE8gKyBkZWx0YSBidXQgSSBkb24ndCBzZWUgdGhhdCBpbiB0aGUgZGVzY3JpcHRpb24uICBJ IGFwb2xvZ2l6ZSBmb3IgYmVpbmcgc28gb2J0dXNlIGhlcmUuICBJdCBpcyBwb3NzaWJsZSB0aGF0 IEkgaGF2ZSBiZWVuIHN0YXJpbmcgYXQgdGhlc2UgZG9jdW1lbnRzIHRvbyBsb25nLiAgSSBkb24n dCB3YW50IHRvIGp1c3QgdXNlIHRoZSBmb3JtdWxhIHdpdGhvdXQgZnVsbHkgdW5kZXJzdGFuZGlu ZyB3aGVyZSB0aGUgdmFsdWVzIGFyZSBjb21pbmcgZnJvbS4NCg0KPiANCj4gU2ltb24NCj4gLS0N Cj4gRFROIG1hZGUgZWFzeSwgbGVhbiwgYW5kIHNtYXJ0IC0tPiBodHRwOi8vcG9zdGVsbGF0aW9u LnZpYWdlbmllLmNhDQo+IE5BVDY0L0ROUzY0IG9wZW4tc291cmNlICAgICAgICAtLT4gaHR0cDov L2VjZHlzaXMudmlhZ2VuaWUuY2ENCj4gU1RVTi9UVVJOIHNlcnZlciAgICAgICAgICAgICAgIC0t PiBodHRwOi8vbnVtYi52aWFnZW5pZS5jYQ0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiBCZWhhdmUgbWFpbGluZyBsaXN0DQo+IEJlaGF2ZUBpZXRm Lm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2JlaGF2ZQ0K From todd@apx-labs.com Fri Sep 21 07:25:10 2012 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D84221F8850 for ; Fri, 21 Sep 2012 07:25:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=1.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ctR+5DYE45q7 for ; Fri, 21 Sep 2012 07:25:09 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe005.messaging.microsoft.com [65.55.88.15]) by ietfa.amsl.com (Postfix) with ESMTP id EA42521F8852 for ; Fri, 21 Sep 2012 07:24:55 -0700 (PDT) Received: from mail247-tx2-R.bigfish.com (10.9.14.247) by TX2EHSOBE003.bigfish.com (10.9.40.23) with Microsoft SMTP Server id 14.1.225.23; Fri, 21 Sep 2012 14:24:55 +0000 Received: from mail247-tx2 (localhost [127.0.0.1]) by mail247-tx2-R.bigfish.com (Postfix) with ESMTP id 6F8EF1CC01C5; Fri, 21 Sep 2012 14:24:55 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.234.133; KIP:(null); UIP:(null); IPV:NLI; H:SN2PRD0610HT005.namprd06.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -27 X-BigFish: PS-27(zz9371Ic89bh936eI542M1432Id6f1izz1202h1d2ahzz1033IL17326ah8275dhz2fh2a8h668h839h93fhd25hf0ah107ah1288h12a5h12a9h12bdh137ah1155h) Received-SPF: pass (mail247-tx2: domain of apx-labs.com designates 157.56.234.133 as permitted sender) client-ip=157.56.234.133; envelope-from=todd@apx-labs.com; helo=SN2PRD0610HT005.namprd06.prod.outlook.com ; .outlook.com ; Received: from mail247-tx2 (localhost.localdomain [127.0.0.1]) by mail247-tx2 (MessageSwitch) id 1348237493335846_30928; Fri, 21 Sep 2012 14:24:53 +0000 (UTC) Received: from TX2EHSMHS007.bigfish.com (unknown [10.9.14.243]) by mail247-tx2.bigfish.com (Postfix) with ESMTP id 4FE74A80045; Fri, 21 Sep 2012 14:24:53 +0000 (UTC) Received: from SN2PRD0610HT005.namprd06.prod.outlook.com (157.56.234.133) by TX2EHSMHS007.bigfish.com (10.9.99.107) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 21 Sep 2012 14:24:51 +0000 Received: from SN2PRD0610MB372.namprd06.prod.outlook.com ([169.254.7.182]) by SN2PRD0610HT005.namprd06.prod.outlook.com ([10.255.117.40]) with mapi id 14.16.0190.008; Fri, 21 Sep 2012 14:24:51 +0000 From: Todd Herman To: Simon Perreault , "behave@ietf.org" Thread-Topic: [BEHAVE] Couple questions regarding RFC 5389 (STUN) Thread-Index: Ac2XqWNw4N+FWpCpSpCoQq4PO0uhjwAE4JyAAA3Oj6AAATcigAAC15uw Date: Fri, 21 Sep 2012 14:24:51 +0000 Message-ID: <980973149D509B4AA117C3CE035BACA92F82A30E@SN2PRD0610MB372.namprd06.prod.outlook.com> References: <980973149D509B4AA117C3CE035BACA92F828A5F@SN2PRD0610MB372.namprd06.prod.outlook.com> <505BFFF7.4040801@acm.org> <980973149D509B4AA117C3CE035BACA92F829F2D@SN2PRD0610MB372.namprd06.prod.outlook.com> <505C64C7.6030001@viagenie.ca> In-Reply-To: <505C64C7.6030001@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.73.3.78] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: apx-labs.com Subject: Re: [BEHAVE] Couple questions regarding RFC 5389 (STUN) 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, 21 Sep 2012 14:25:10 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBiZWhhdmUtYm91bmNlc0BpZXRm Lm9yZyBbbWFpbHRvOmJlaGF2ZS1ib3VuY2VzQGlldGYub3JnXSBPbg0KPiBCZWhhbGYgT2YgU2lt b24gUGVycmVhdWx0DQo+IFNlbnQ6IEZyaWRheSwgU2VwdGVtYmVyIDIxLCAyMDEyIDk6MDAgQU0N Cj4gVG86IGJlaGF2ZUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW0JFSEFWRV0gQ291cGxlIHF1 ZXN0aW9ucyByZWdhcmRpbmcgUkZDIDUzODkgKFNUVU4pDQo+IA0KPiBMZSAyMDEyLTA5LTIxIDA4 OjM5LCBUb2RkIEhlcm1hbiBhIMOpY3JpdCA6DQo+ID4gVGhlIGxhc3QgcGFyYWdyYXBoIGluIHNl Y3Rpb24gNy4yLjEgcHJvdmlkZXMgYW4gZXhhbXBsZSB0aGF0IHNheXMgdGhhdA0KPiA+IGlmIGFu IFJUTyBvZiA1MDBtcyBpcyB1c2VkIHRoZSByZXF1ZXN0cyB3b3VsZCBiZSBzZW50IGF0IDAsIDUw MCwgMTUwMCwNCj4gPiAzNTAwLCA3NTAwLCAxNTUwMCBhbmQgMzE1MDAuICBXaGVyZSBhcmUgdGhl c2UgdmFsdWVzIGNvbWluZyBmcm9tPyAgSQ0KPiA+IGdhdGhlciBmcm9tIHRoZSBzdGF0ZW1lbnQg dGhhdCBSVE8gaGFzIGFscmVhZHkgYmVlbiBjYWxjdWxhdGVkIHNvIHRoYXQNCj4gPiBzaG91bGQg bWVhbiB3ZSBhcmUgbm90IHVzaW5nIHRoZSBmb3JtdWxhcyBpbiBSRkMgMjk4OC4gIFJGQyAyOTg4 IGRvZXMNCj4gPiBzdGF0ZSB0aGF0IHlvdSBzaG91bGQgc3RhcnQgd2l0aCA1MDAgbXMgZm9yIHRo ZSBmaXJzdCB0aW1lIGFueXdheS4gIEl0DQo+ID4gaXMgZWFzeSBlbm91Z2ggdG8gc2VlIHRoYXQg dGhvc2UgdmFsdWVzIGFyZSBiZWluZyBiYWNrZWQgb2ZmIGFuZCBzZWVtDQo+ID4gdG8gdXNlIHRo ZSBmb3JtdWxhIFJUTyA9IFJUTyAqIDIgKyBSVE8gYnV0IEkgZG9uJ3Qgc2VlIHdoZXJlIHRoaXMN Cj4gPiBmb3JtdWxhIGlzIG1lbnRpb25lZCBpbiBSRkMgNTM4OS4NCj4gDQo+IFNlY3Rpb24gNy4y LjEsIHNlY29uZCBwYXJhZ3JhcGg6DQo+IA0KPiAgICAgQSBjbGllbnQgU0hPVUxEIHJldHJhbnNt aXQgYSBTVFVOIHJlcXVlc3QgbWVzc2FnZSBzdGFydGluZyB3aXRoIGFuDQo+ICAgICBpbnRlcnZh bCBvZiBSVE8gKCJSZXRyYW5zbWlzc2lvbiBUaW1lT3V0IiksIGRvdWJsaW5nIGFmdGVyIGVhY2gN Cj4gICAgIHJldHJhbnNtaXNzaW9uLg0KPiANCj4gVGhhdCdzIGl0Lg0KPiANCj4gVmFsdWUJRGVs dGENCj4gMA0KPiA1MDAgICAgIDUwMA0KPiAxNTAwCTEwMDANCj4gMzUwMAkyMDAwDQo+IDc1MDAJ NDAwMA0KPiAxNTUwMAk4MDAwDQo+IDMxNTAwCTE2MDAwDQo+IA0KPiBTZWU/IFRoZSBkZWx0YSBk b3VibGVzIGF0IGVhY2ggbGluZS4NCj4NCg0KT2suICBJIGFwb2xvZ2l6ZSBmb3IgbXkgZWFybGll ciBtaXN1bmRlcnN0YW5kaW5nLiAgSSB0aGluayBpdCBpcyBkdWUgdG8gbGFjayBvZiBzbGVlcC4g IEkgd2FzIGlnbm9yaW5nIHRoZSBmYWN0IHRoYXQgd2UgYXJlIHRhbGtpbmcgYWJvdXQgcG9pbnRz IGluIHRpbWUuICBSVE8gc3RhcnRzIGF0IDUwMCBhbmQgaXNuJ3QgY2hhbmdpbmcuICBUaGUgZmly c3QgcmV0cmFuc21pdCBoYXBwZW5zIGFmdGVyIDUwMG1zLiAgVGhlIG5leHQgd2lsbCBoYXBwZW4g YWZ0ZXIgYW4gYWRkaXRpb25hbCBSVE8gKiAyIChvciAxMDAwKSBtcyBwdXR0aW5nIGl0IGF0IDE1 MDBtcy4gIEFuZCBzbyBvbiBhbmQgc28gZm9ydGguICBJIHRvdGFsbHkgZ2V0IGl0IG5vdyBhbmQg YXBvbG9naXplLCBhZ2FpbiwgZm9yIHRoZSBzbG93bmVzcyBmYWN0b3IuDQoNCkFzIGFuIGFkZC1v biBxdWVzdGlvbiwgYW0gSSB1bmRlcnN0YW5kaW5nIGNvcnJlY3RseSB0aGF0IEkgb25seSByZWNh bGN1bGF0ZSBSVE8gKGFjY29yZGluZyB0byBSRkMgMjk4OCkgb25jZSBJIGhhdmUgYSBzdWNjZXNz ZnVsIHRyYW5zYWN0aW9uIGFuZCBjYWxjdWxhdGUgYW4gYWN0dWFsIFJUVD8NCg0KT25lIG1vcmUs IHdvdWxkIGEgcmV0cmFuc21pc3Npb24gdGltZXIgYXBwbHkgdG8gYSBzcGVjaWZpYyB0cmFuc2Fj dGlvbiBvciB0byBhbGwgdHJhbnNhY3Rpb25zIHJlY2VudGx5IHNlbnQgYW5kIGF3YWl0aW5nIHJl cGxpZXM/DQoNCkkgYXBwcmVjaWF0ZSB0aGUgYXNzaXN0YW5jZS4gIFNpbW9uLCBJIGFsc28gd2Fu dGVkIHRvIHRoYW5rIHlvdSBzcGVjaWZpY2FsbHkgYmVjYXVzZSBvZiBOVU1CLiAgSSBoYXZlIHRv IGJ1aWxkIG15IG93biBTVFVOL1RVUk4gY2xpZW50L3NlcnZlciBmb3IgYSBwcm9qZWN0IGFuZCB0 aGUgdXNlIG9mIE5VTUIgYXMgYSB0ZXN0IGJlZCBoYXMgYmVlbiBleHRyZW1lbHkgaGVscGZ1bC4N Cg0KPiBTaW1vbg0KPiAtLQ0KPiBEVE4gbWFkZSBlYXN5LCBsZWFuLCBhbmQgc21hcnQgLS0+IGh0 dHA6Ly9wb3N0ZWxsYXRpb24udmlhZ2VuaWUuY2ENCj4gTkFUNjQvRE5TNjQgb3Blbi1zb3VyY2Ug ICAgICAgIC0tPiBodHRwOi8vZWNkeXNpcy52aWFnZW5pZS5jYQ0KPiBTVFVOL1RVUk4gc2VydmVy ICAgICAgICAgICAgICAgLS0+IGh0dHA6Ly9udW1iLnZpYWdlbmllLmNhDQo+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IEJlaGF2ZSBtYWlsaW5nIGxp c3QNCj4gQmVoYXZlQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vYmVoYXZlDQo= From simon.perreault@viagenie.ca Fri Sep 21 12:38:01 2012 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 575E521F8667 for ; Fri, 21 Sep 2012 12:38:01 -0700 (PDT) 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.046, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Ws5GZzNO-3n for ; Fri, 21 Sep 2012 12:38:00 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 938AA21F8661 for ; Fri, 21 Sep 2012 12:38:00 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:987e:53d3:3d57:e57c]) by jazz.viagenie.ca (Postfix) with ESMTPSA id C4D7840065; Fri, 21 Sep 2012 15:37:57 -0400 (EDT) Message-ID: <505CC215.5070406@viagenie.ca> Date: Fri, 21 Sep 2012 15:37:57 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120828 Thunderbird/15.0 MIME-Version: 1.0 To: Todd Herman References: <980973149D509B4AA117C3CE035BACA92F828A5F@SN2PRD0610MB372.namprd06.prod.outlook.com> <505BFFF7.4040801@acm.org> <980973149D509B4AA117C3CE035BACA92F829F2D@SN2PRD0610MB372.namprd06.prod.outlook.com> <505C64C7.6030001@viagenie.ca> <980973149D509B4AA117C3CE035BACA92F82A30E@SN2PRD0610MB372.namprd06.prod.outlook.com> In-Reply-To: <980973149D509B4AA117C3CE035BACA92F82A30E@SN2PRD0610MB372.namprd06.prod.outlook.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "behave@ietf.org" Subject: Re: [BEHAVE] Couple questions regarding RFC 5389 (STUN) 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, 21 Sep 2012 19:38:01 -0000 Le 2012-09-21 10:24, Todd Herman a écrit : > As an add-on question, am I understanding correctly that I only > recalculate RTO (according to RFC 2988) once I have a successful > transaction and calculate an actual RTT? Yes. > One more, would a retransmission timer apply to a specific > transaction or to all transactions recently sent and awaiting > replies? I'm not exactly sure what you mean. Each transaction will be retransmitted independently from the others. So each one will have its own timer. But they should share their RTT estimate, as described in this excerpt: The value for RTO SHOULD be cached by a client after the completion of the transaction, and used as the starting value for RTO for the next transaction to the same server (based on equality of IP address). The value SHOULD be considered stale and discarded after 10 minutes. > I appreciate the assistance. Simon, I also wanted to thank you > specifically because of NUMB. I have to build my own STUN/TURN > client/server for a project and the use of NUMB as a test bed has > been extremely helpful. Thanks, I'm glad that you like it! :) Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From cb.list6@gmail.com Mon Sep 24 15:36: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 DFC171F0C3A for ; Mon, 24 Sep 2012 15:36:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.356 X-Spam-Level: X-Spam-Status: No, score=-3.356 tagged_above=-999 required=5 tests=[AWL=0.243, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NRFtb8cUIAjR for ; Mon, 24 Sep 2012 15:36:06 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1E8491F041D for ; Mon, 24 Sep 2012 15:36:05 -0700 (PDT) Received: by lbok13 with SMTP id k13so1766425lbo.31 for ; Mon, 24 Sep 2012 15:36:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EvcahkFSwHsXB09RWfn+Oc9KI4Mzbx7FzLHQg7w1WGM=; b=jmI+E35MzrXKpMLfl7ZA2iTU2OigCHRH7GfpkvciUKAdtzBUQU1NC71GSOemI68teR wSOhgmtnIXRfWurUmFVDcnImKwW94U5gRtEL0+uNQt2AEQIdeTgNr5yL2A5j8/vVkh2c bwBvFlSfRoMAobAD4TtKafRFkh/mn5ssWRGUdpyLEbnC156GUojl/RvaxJEkIywfhOvy wwoVKsCtmmWHsVaXkd5cT2bF0lln7xZ/AUnHKSAQkbjGYJhs1Pi1Se62Dx3Ub1FZ6J+I bEIS5wVJCJ9W0LlNsM+4R/1cK3E53Xv6PY7UjYUkjOUY3/n729D2LoLB4iNyLwVNWxv4 zm5w== MIME-Version: 1.0 Received: by 10.152.122.9 with SMTP id lo9mr11760533lab.41.1348526164935; Mon, 24 Sep 2012 15:36:04 -0700 (PDT) Received: by 10.112.49.66 with HTTP; Mon, 24 Sep 2012 15:36:04 -0700 (PDT) In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B7C04CE@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> References: <9B57C850BB53634CACEC56EF4853FF653B7C04CE@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Date: Mon, 24 Sep 2012 15:36:04 -0700 Message-ID: From: Cameron Byrne To: Dave Thaler Content-Type: text/plain; charset=ISO-8859-1 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-11 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, 24 Sep 2012 22:36:07 -0000 On Thu, Sep 20, 2012 at 2:07 PM, Dave Thaler wrote: > All comments received during the first WGLC (on -09) have been > > resolved. > > > > This email initiates another two-week Working Group Last Call > > on draft-ietf-behave-nat64-discovery-heuristic-11, to conclude > > Thursday October 4th. > > > > We need at least 5 reviewers to comment on the doc > > (even if just saying "looks good"). > I have just read the -11 and it looks good to me. Let's move it forward, it is useful and high quality work. Cameron From philip_matthews@magma.ca Tue Sep 25 13:47:25 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 A972B1F0CB7 for ; Tue, 25 Sep 2012 13:47:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vaYI3-dxicL1 for ; Tue, 25 Sep 2012 13:47:25 -0700 (PDT) Received: from mail-09.primus.ca (mail16.primus.ca [216.254.141.183]) by ietfa.amsl.com (Postfix) with ESMTP id 00B461F0C67 for ; Tue, 25 Sep 2012 13:47:24 -0700 (PDT) Received: from [74.198.165.79] (helo=[172.20.10.2]) by mail-09.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1TGc2J-000545-1z; Tue, 25 Sep 2012 16:47:23 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-9-931647066 From: Philip Matthews In-Reply-To: <980973149D509B4AA117C3CE035BACA92F8245E6@SN2PRD0610MB372.namprd06.prod.outlook.com> Date: Tue, 25 Sep 2012 16:47:14 -0400 Message-Id: <5BB17260-F0D6-4870-923D-2B76EE46AF42@magma.ca> References: <980973149D509B4AA117C3CE035BACA92F8245E6@SN2PRD0610MB372.namprd06.prod.outlook.com> To: Todd Herman X-Mailer: Apple Mail (2.1084) X-Authenticated: philip_matthews - ([172.20.10.2]) [74.198.165.79] Cc: Rohan Mahy , Behave WG , Jonathan Rosenberg Subject: Re: [BEHAVE] Question regarding RFC 5389 (STUN) 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, 25 Sep 2012 20:47:25 -0000 --Apple-Mail-9-931647066 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Todd: Questions on STUN can be directed to the mailing list of the BEHAVE = working group, which I have copied on this reply. If I understand your question correctly, then you are asking if the = Transaction ID field is modified when retransmitting requests sent over = UDP (section 7.2.1 of RFC 5389). The answer is NO. These = retransmissions are considered to be part of a single transaction. - Philip On 2012-09-20, at 14:05 , Todd Herman wrote: > I have a STUN question and I can=92t seem to find the mailing list = that I should use to ask the question.=20 > =20 > I mostly need clarification on sending requests and RTO. Section 7.2, = the second paragraph, says that a client can have multiple transactions = to the same server with different transaction IDs. I need clarification = if these are =93new=94 transactions or retransmissions. The discussion = on retransmission follows this section so I just wanted to clarify that = there is a distinct difference between =93new transactions=94 and = retransmitted transactions? This will help me clarify that a = retransmitted message is identical to the previously sent message, = including the transaction ID. > =20 > If there is a more appropriate place that I should send this question = (as I will most likely have more), please let me know. > =20 > Thanks, > Todd Herman > =20 >=20 > =20 --Apple-Mail-9-931647066 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi = Todd:

Questions on STUN can be directed to the = mailing list of the BEHAVE working group, which I have copied on this = reply.

If I understand your question correctly, = then you are asking if the Transaction ID field is modified when = retransmitting requests sent over UDP (section 7.2.1 of RFC 5389). = The answer is NO. These retransmissions are considered to be part = of a single transaction.

- = Philip

On 2012-09-20, = at 14:05 , Todd Herman wrote:

I have a STUN question and I = can=92t seem to find the mailing list that I should use to ask the = question.

I mostly need clarification on sending requests and = RTO. Section 7.2, the second paragraph, says that a client can = have multiple transactions to the same server with different transaction = IDs. I need clarification if these are =93new=94 transactions or = retransmissions. The discussion on retransmission follows this = section so I just wanted to clarify that there is a distinct difference = between =93new transactions=94 and retransmitted transactions? = This will help me clarify that a retransmitted message is identical to = the previously sent message, including the transaction = ID.

If there is a more = appropriate place that I should send this question (as I will most = likely have more), please let me know.

Thanks,
Todd Herman

To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120926184732.4747.38765.idtracker@ietfa.amsl.com> Date: Wed, 26 Sep 2012 11:47:32 -0700 Cc: behave mailing list , behave chair , RFC Editor Subject: [BEHAVE] Protocol Action: 'Common requirements for Carrier Grade NATs (CGNs)' to Best Current Practice (draft-ietf-behave-lsn-requirements-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, 26 Sep 2012 18:47:34 -0000 The IESG has approved the following document: - 'Common requirements for Carrier Grade NATs (CGNs)' (draft-ietf-behave-lsn-requirements-09.txt) as Best Current Practice This document is the product of the Behavior Engineering for Hindrance Avoidance Working Group. The IESG contact persons are Wesley Eddy and Martin Stiemerling. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-behave-lsn-requirements/ Technical Summary This document defines common requirements for Carrier-Grade NAT (CGN) Working Group Summary Consensus is strong, except for a split between some WG members wanting "SHOULD support bulk port allocation" (in order to reduce logging) and other WG members who think no recommendation should be made. So, the document merely describes the trade-offs in its Section 5. An IPR declaration exists against the document, https://datatracker.ietf.org/ipr/1648. The actual claims are not available. At IETF82, consensus of the working group was to continue with publication of the document. Document Quality This is a requirements document, so there are not exactly implementations of it. Service providers are interested in it, and vendors are interested in supporting these requirements for that reason. Personnel The document shepherd is Dan Wing (dwing@cisco.com), and the responsible AD is Wesley Eddy (wes@mti-systems.com). RFC Editor Note Please change the REQ-7 requirement as indicated below: OLD: REQ-7: It is RECOMMENDED that a CGN have an "Endpoint-Independent NEW: REQ-7: It is RECOMMENDED that a CGN use an "Endpoint-Independent From yding@cs.helsinki.fi Wed Sep 26 12: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 265F421F84B2 for ; Wed, 26 Sep 2012 12:33:24 -0700 (PDT) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p5FohyXfw2Yi for ; Wed, 26 Sep 2012 12:33:23 -0700 (PDT) Received: from mail.cs.helsinki.fi (courier.cs.helsinki.fi [128.214.9.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5442821F849D for ; Wed, 26 Sep 2012 12:33:21 -0700 (PDT) Received: from [192.168.178.32] (brln-4db9fa5e.pool.mediaWays.net [77.185.250.94]) (AUTH: PLAIN yding, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Wed, 26 Sep 2012 22:33:19 +0300 id 0008C1B3.5063587F.00001C9A Message-ID: <50635877.20109@cs.helsinki.fi> Date: Wed, 26 Sep 2012 22:33:11 +0300 From: Aaron Yi DING Organization: Helsinki University User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Dave Thaler , "behave@ietf.org" References: <9B57C850BB53634CACEC56EF4853FF653B7C04CE@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B7C04CE@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Content-Type: multipart/alternative; boundary="------------030800080401020408060508" Subject: Re: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-11 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, 26 Sep 2012 19:33:24 -0000 This is a multi-part message in MIME format. --------------030800080401020408060508 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit The latest version -11 looks good to me. My comments in the previous round are all solved. Let's move it forward. cheers, Aaron On 21/09/12 00:07, Dave Thaler wrote: > > All comments received during the first WGLC (on -09) have been > > resolved. > > This email initiates another two-week Working Group Last Call > > on draft-ietf-behave-nat64-discovery-heuristic-11, to conclude > > Thursday October 4^th . > > We need at least 5 reviewers to comment on the doc > > (even if just saying "looks good"). > > -Dave Thaler > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave --------------030800080401020408060508 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
The latest version -11 looks good to me. My comments in the previous round are all solved.

Let's move it forward.

cheers,
Aaron

On 21/09/12 00:07, Dave Thaler wrote:

All comments received during the first WGLC (on -09) have been

resolved.

This email initiates another two-week Working Group Last Call

on draft-ietf-behave-nat64-discovery-heuristic-11, to conclude

Thursday October 4^th.

We need at least 5 reviewers to comment on the doc

(even if just saying "looks good").

-Dave Thaler

_______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave

--------------030800080401020408060508-- From mawatari@jpix.ad.jp Wed Sep 26 21:58: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 2F5CB21F8644 for ; Wed, 26 Sep 2012 21:58:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.024 X-Spam-Level: X-Spam-Status: No, score=0.024 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AGtk+zoVGIzX for ; Wed, 26 Sep 2012 21:58:41 -0700 (PDT) Received: from mx20.jpix.ad.jp (mx20.jpix.ad.jp [210.171.225.78]) by ietfa.amsl.com (Postfix) with ESMTP id 99EAB21F85B1 for ; Wed, 26 Sep 2012 21:58:40 -0700 (PDT) Received: from [10.10.31.235] (eth3-1-bb-fw-34.jpix.ad.jp [210.171.226.102]) by mx20.jpix.ad.jp (Postfix) with ESMTP id 62576FC040; Thu, 27 Sep 2012 13:58:39 +0900 (JST) Date: Thu, 27 Sep 2012 13:58:37 +0900 From: MAWATARI Masataka To: dthaler@microsoft.com In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B7C04CE@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> References: <9B57C850BB53634CACEC56EF4853FF653B7C04CE@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Message-Id: <20120927135837.B4BD.8FE1F57E@jpix.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.61.01 [ja] Cc: behave@ietf.org Subject: Re: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-11 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, 27 Sep 2012 04:58:42 -0000 Dear Dave-san and authors, Thank you for your work. I read the document. It looks good to me. Kind Regards, Masataka MAWATARI * On Thu, 20 Sep 2012 21:07:44 +0000 * Dave Thaler wrote: > All comments received during the first WGLC (on -09) have been > resolved. > > This email initiates another two-week Working Group Last Call > on draft-ietf-behave-nat64-discovery-heuristic-11, to conclude > Thursday October 4th. > > We need at least 5 reviewers to comment on the doc > (even if just saying "looks good"). > > -Dave Thaler From stephan.lagerholm@secure64.com Sat Sep 29 07:19: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 B810F21F8550 for ; Sat, 29 Sep 2012 07:19:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3JcUqCHL98DH for ; Sat, 29 Sep 2012 07:19:29 -0700 (PDT) Received: from zimbra.secure64.com (unknown [64.92.221.189]) by ietfa.amsl.com (Postfix) with ESMTP id 1E58621F84EE for ; Sat, 29 Sep 2012 07:19:28 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.secure64.com (Postfix) with ESMTP id 56C2DB8585; Sat, 29 Sep 2012 08:19:28 -0600 (MDT) X-Virus-Scanned: amavisd-new at secure64.com Received: from zimbra.secure64.com ([127.0.0.1]) by localhost (zimbra.secure64.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 65rXRdJQ+GHq; Sat, 29 Sep 2012 08:19:27 -0600 (MDT) Received: from exchange.secure64.com (exchange.secure64.com [192.168.254.250]) by zimbra.secure64.com (Postfix) with ESMTPSA id 46374B8566; Sat, 29 Sep 2012 08:19:27 -0600 (MDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=secure64.com; s=2010; t=1348928367; bh=zhfUBiwtVt0oM4BxB0BuIOvQhx8bLTkGFqy1JuYoCaQ=; h=MIME-Version:Content-Type:Content-Transfer-Encoding:Subject:Date: Message-ID:In-Reply-To:References:From:To:Cc; b=Mx2fLD7BjbS/1yt5YS 0oEPjFrbbu6BxJerIEfT2vFsnhQtbIwwEL4etvgY9lKl/XjtKQuTXCUYWIeKnFANkaC 6WG85kWiXQHu+Wqk+y/cMxWRHoFuFjiws259P5KtskwQ8NDCyLsHfpyYsMZN2tSku8/ Sm3X13GhDuR9weIlexY= 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: Sat, 29 Sep 2012 08:19:40 -0600 Message-ID: In-Reply-To: <20120927135837.B4BD.8FE1F57E@jpix.ad.jp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] Last call:draft-ietf-behave-nat64-discovery-heuristic-11 Thread-Index: Ac2cbDx5LdGLw5JSRxizJ5AeXIMH2wB4Mt3g References: <9B57C850BB53634CACEC56EF4853FF653B7C04CE@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <20120927135837.B4BD.8FE1F57E@jpix.ad.jp> From: "Stephan Lagerholm" To: "MAWATARI Masataka" , Cc: behave@ietf.org Subject: Re: [BEHAVE] Last call:draft-ietf-behave-nat64-discovery-heuristic-11 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, 29 Sep 2012 14:19:29 -0000 The -11 draft looks good to me other than a small typo with an extra zero in 64:ff9b::192.0.0.0170 on page 10. /S -----Original Message----- From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of MAWATARI Masataka Sent: Wednesday, September 26, 2012 11:59 PM To: dthaler@microsoft.com Cc: behave@ietf.org Subject: Re: [BEHAVE] Last call:draft-ietf-behave-nat64-discovery-heuristic-11 Dear Dave-san and authors, Thank you for your work. I read the document. It looks good to me. Kind Regards, Masataka MAWATARI * On Thu, 20 Sep 2012 21:07:44 +0000 * Dave Thaler wrote: > All comments received during the first WGLC (on -09) have been=20 > resolved. >=20 > This email initiates another two-week Working Group Last Call on=20 > draft-ietf-behave-nat64-discovery-heuristic-11, to conclude Thursday=20 > October 4th. >=20 > We need at least 5 reviewers to comment on the doc (even if just=20 > saying "looks good"). >=20 > -Dave Thaler _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave