From xiaohong.deng@orange-ftgroup.com Wed Apr 6 21:10:30 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E9D928C101; Wed, 6 Apr 2011 21:10:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.33 X-Spam-Level: X-Spam-Status: No, score=-0.33 tagged_above=-999 required=5 tests=[AWL=-1.416, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7S3u90z+2wRy; Wed, 6 Apr 2011 21:10:29 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id 1AE5028B797; Wed, 6 Apr 2011 21:10:28 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 162D96C8003; Thu, 7 Apr 2011 06:12:45 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id 018756C0001; Thu, 7 Apr 2011 06:12:44 +0200 (CEST) Received: from ch-mailsrv.rd.francetelecom.fr ([10.193.250.27]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 7 Apr 2011 06:12:10 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBF4D9.F48D2DE8" Date: Thu, 7 Apr 2011 12:12:05 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <0962B0BEF842A24191AD9BE41A8DD2FC01685247@ch-mailsrv.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: [Int-area] Stateless IPv4-in-IPv6 experiments && DS-Lite/NAT64 experiments Thread-Index: Acv0dqpjDSVsZIxJQe6Yllay01rTEgAXyLQg References: <0962B0BEF842A24191AD9BE41A8DD2FC016850B4@ch-mailsrv.rd.francetelecom.fr> From: To: X-OriginalArrivalTime: 07 Apr 2011 04:12:10.0454 (UTC) FILETIME=[F750CF60:01CBF4D9] Cc: softwires-request@ietf.org, behave@ietf.org, int-area@ietf.org Subject: Re: [BEHAVE] [Int-area] Stateless IPv4-in-IPv6 experiments && DS-Lite/NAT64 experiments X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 07 Apr 2011 04:10:30 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBF4D9.F48D2DE8 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: quoted-printable We have tested how applications behave when it has both DS-Lite IPv4 and = NAT64 IPv6 (but not native IPv6). Firefox, IE, Skype, Google Earth = v5.2.1, Live Messenger, uTorrent, BitComet, were on our test list.=20 =20 Despres,regarding your question ( maybe not answering your question = exactly as we tested NAT64 IPv6 instead of native IPv6 ), uTorrent v2.2 = used IPv6 for login/authentication but IPv4 for the data exchange, for = IPv6 peer was not able to talk to IPv4 peer. Although BitComet v1.23 = issued both A and AAAA quires, it completely ignored AAAA RR and only = used IPv4 for communication. =20 Please also see some of other test results below. DS-Lite/NAT64 = experiments could be documented if it is of interests.=20 =20 Tested Apps IPv4/IPv6 portion Firefox (Non-vedio) v3.6.12 All IPv6 =20 video website Half/ half =20 IE (Non-vedio) v6.0 All IPv6 =20 Skype v5.0 Major IPv6 =20 Google Earth v5.2.1 Major IPv6 =20 Live Messenger 2009 Major IPv4 =20 uTorrent v2.2 Major IPv4 =20 BitComet v1.23 All IPv4 =20 =20 BR, Xiaohong opensource A+P: http://opensourceaplusp.weebly.com/ =20 ________________________________ =B7=A2=BC=FE=C8=CB: R=A8=A6mi Despr=A8=A6s = [mailto:remi.despres@free.fr]=20 =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA4=D4=C27=C8=D5 0:21 =CA=D5=BC=FE=C8=CB: DENG Xiaohong ESP/PEK =B3=AD=CB=CD: int-area@ietf.org =D6=F7=CC=E2: Re: [Int-area] Stateless IPv4-in-IPv6 experiments =09 =09 Thank you, Xiahong, for sharing this interesting information.=20 In the case of BitComet and uTorrent, I wonder what happens if the host = has both A+P IPv4 and IPv6, as opposed to just A+P IPv4. Did you try that? Regards, RD Le 6 avr. 2011 =A8=A4 10:57, = a =A8=A6crit : Dear all, =20 An I-D about stateless IPv4-in-IPv6 experiments has been submitted. A = URL for this Internet-Draft is: = http://tools.ietf.org/html/draft-deng-aplusp-experiment-results-00 = . =20 A website introducing the detail of experiment results is also = accessible via: http://opensourceaplusp.weebly.com/ = =20 =20 BR, Xiaohong _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area =09 ------_=_NextPart_001_01CBF4D9.F48D2DE8 Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: quoted-printable

We=20 have=20 tested=20 how applications behave when it has both DS-Lite=20 IPv4=20 and NAT64 IPv6 (but not native IPv6).=20 Firefox,=20 IE, Skype, Google Earth v5.2.1, Live Messenger, uTorrent, = BitComet,=20 were on our test list. 

 

Despres,regarding your=20 question (=20 maybe not answering your question exactly as we tested NAT64=20 IPv6 instead of native IPv6 ), uTorrent v2.2 used IPv6 for=20 login/authentication but IPv4 for the data exchange, for IPv6 peer was = not able=20 to talk to IPv4 peer. Although BitComet v1.23 issued both A and AAAA = quires, it=20 completely ignored AAAA RR and only used IPv4 for=20 communication.

 

Please also see some of other test results below. DS-Lite/NAT64 experiments could be = documented if it is=20 of interests.

 

Tested Apps                   IPv4/IPv6 = portion

Firefox (Non-vedio) v3.6.12   All IPv6           &nbs= p;            = ;    =20

video website           &nbs= p;    =20 Half/ half          =20  

IE (Non-vedio) v6.0  =20      =    All IPv6           &nbs= p;            = ;   =20

Skype v5.0           =20        =20 Major IPv6          =20             &nbs= p; =20

Google Earth v5.2.1          =20 Major IPv6           &n= bsp; =20      =20

Live Messenger 2009          =20 Major IPv4           =20

uTorrent v2.2           &nbs= p;    =20 Major IPv4    =20

BitComet v1.23           &nbs= p;   =20 All IPv4      =20

 

BR,

Xiaohong

opensource A+P: http://opensourceaplusp.weeb= ly.com/

 

=B7=A2=BC=FE=C8=CB: = R=A8=A6mi Despr=A8=A6s [mailto:remi.despres@free.fr]=20
=B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA4=D4=C27=C8=D5 = 0:21
=CA=D5=BC=FE=C8=CB: DENG Xiaohong=20 ESP/PEK
=B3=AD=CB=CD: = int-area@ietf.org
=D6=F7=CC=E2: Re: [Int-area] Stateless=20 IPv4-in-IPv6 experiments

Thank you, Xiahong, for sharing this interesting = information.

In the case of BitComet and uTorrent, I wonder what happens if = the host=20 has both A+P IPv4 and IPv6, as opposed to just A+P IPv4.
Did you try that?

Regards,
RD

Le 6 avr. 2011 =A8=A4 10:57, <xiaohong.deng@orange-ftg= roup.com>=20 <xiaohong.deng@orange-ftg= roup.com>=20 a =A8=A6crit :

Dear=20 all,
 
An I-D about stateless = IPv4-in-IPv6 experiments has been submitted.=20 A URL = for this=20 Internet-Draft is: http://tools.ietf.org/html/draft-deng-aplusp-experiment-r= esults-00.
 
A website=20 introducing the detail of experiment results is also accessible = via: http://opensourceaplusp.weebly.com/
 
BR,
Xiaohong
______________________________= _________________
Int-area=20 mailing list
Int-area@ietf.org
https://www.ie= tf.org/mailman/listinfo/int-area

------_=_NextPart_001_01CBF4D9.F48D2DE8-- From remi.despres@free.fr Thu Apr 7 00:09:49 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 117C728C0D9; Thu, 7 Apr 2011 00:09:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.221 X-Spam-Level: X-Spam-Status: No, score=-0.221 tagged_above=-999 required=5 tests=[AWL=-0.553, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o0QxDCvKbLO9; Thu, 7 Apr 2011 00:09:47 -0700 (PDT) Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.10]) by core3.amsl.com (Postfix) with ESMTP id 10B013A688B; Thu, 7 Apr 2011 00:09:47 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2221.sfr.fr (SMTP Server) with ESMTP id 0C2897000092; Thu, 7 Apr 2011 09:11:31 +0200 (CEST) Received: from [192.168.0.14] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2221.sfr.fr (SMTP Server) with ESMTP id 7DD827000087; Thu, 7 Apr 2011 09:11:30 +0200 (CEST) X-SFR-UUID: 20110407071130515.7DD827000087@msfrf2221.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-28--416943308 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <0962B0BEF842A24191AD9BE41A8DD2FC01685247@ch-mailsrv.rd.francetelecom.fr> Date: Thu, 7 Apr 2011 09:11:27 +0200 Message-Id: References: <0962B0BEF842A24191AD9BE41A8DD2FC016850B4@ch-mailsrv.rd.francetelecom.fr> <0962B0BEF842A24191AD9BE41A8DD2FC01685247@ch-mailsrv.rd.francetelecom.fr> To: X-Mailer: Apple Mail (2.1084) Cc: softwires-request@ietf.org, behave@ietf.org, int-area@ietf.org Subject: Re: [BEHAVE] [Int-area] Stateless IPv4-in-IPv6 experiments && DS-Lite/NAT64 experiments X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 07 Apr 2011 07:09:49 -0000 --Apple-Mail-28--416943308 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Le 7 avr. 2011 =C3=A0 06:12, = a =C3=A9crit : > We have tested how applications behave when it has both DS-Lite IPv4 = and NAT64 IPv6 (but not native IPv6). Firefox, IE, Skype, Google Earth = v5.2.1, Live Messenger, uTorrent, BitComet, were on our test list.=20 > =20 > Despres,regarding your question ( maybe not answering your question = exactly as we tested NAT64 IPv6 instead of native IPv6 ), uTorrent v2.2 = used IPv6 for login/authentication but IPv4 for the data exchange, for = IPv6 peer was not able to talk to IPv4 peer. Although BitComet v1.23 = issued both A and AAAA quires, it completely ignored AAAA RR and only = used IPv4 for communication. Thank you. > =20 > Please also see some of other test results below. DS-Lite/NAT64 = experiments could be documented if it is of interests. If you can share your results, that's always useful information. Accordingly, if someone has results concerning native IPv6 (e2e = transparent, i.e. without NAT64) plus statelessly tunneled IPv4, that = would be nice to have. Regards, RD > =20 > Tested Apps IPv4/IPv6 portion > Firefox (Non-vedio) v3.6.12 All IPv6 =20 > video website Half/ half =20 > IE (Non-vedio) v6.0 All IPv6 =20 > Skype v5.0 Major IPv6 =20 > Google Earth v5.2.1 Major IPv6 =20 > Live Messenger 2009 Major IPv4 =20 > uTorrent v2.2 Major IPv4 =20 > BitComet v1.23 All IPv4 =20 > =20 > BR, > Xiaohong > opensource A+P: http://opensourceaplusp.weebly.com/ > =20 >=20 > =E5=8F=91=E4=BB=B6=E4=BA=BA: R=C3=A9mi Despr=C3=A9s = [mailto:remi.despres@free.fr]=20 > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2011=E5=B9=B44=E6=9C=887=E6=97=A5 = 0:21 > =E6=94=B6=E4=BB=B6=E4=BA=BA: DENG Xiaohong ESP/PEK > =E6=8A=84=E9=80=81: int-area@ietf.org > =E4=B8=BB=E9=A2=98: Re: [Int-area] Stateless IPv4-in-IPv6 experiments >=20 > Thank you, Xiahong, for sharing this interesting information. >=20 > In the case of BitComet and uTorrent, I wonder what happens if the = host has both A+P IPv4 and IPv6, as opposed to just A+P IPv4. > Did you try that? >=20 > Regards, > RD >=20 > Le 6 avr. 2011 =C3=A0 10:57, = a =C3=A9crit : >=20 >> Dear all, >> =20 >> An I-D about stateless IPv4-in-IPv6 experiments has been submitted. A = URL for this Internet-Draft is: = http://tools.ietf.org/html/draft-deng-aplusp-experiment-results-00. >> =20 >> A website introducing the detail of experiment results is also = accessible via: http://opensourceaplusp.weebly.com/ >> =20 >> BR, >> Xiaohong >> _______________________________________________ >> Int-area mailing list >> Int-area@ietf.org >> https://www.ietf.org/mailman/listinfo/int-area >=20 --Apple-Mail-28--416943308 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 xiaohong.deng@orange-ftgr= oup.com> <xiaohong.deng@orange-ftgr= oup.com> a =C3=A9crit :
We=20 have=20 tested=20 how applications behave when it has both DS-Lite=20 IPv4=20 and NAT64 IPv6 (but not native IPv6).=20 Firefox,=20 IE, Skype, Google Earth v5.2.1, Live Messenger, uTorrent, = BitComet,=20 were on our test list. 
 
Despres,regarding your=20 question (=20 maybe not answering your question exactly as we tested NAT64=20= IPv6 instead of native IPv6 ), uTorrent v2.2 used IPv6 for=20= login/authentication but IPv4 for the data exchange, for IPv6 peer was = not able=20 to talk to IPv4 peer. Although BitComet v1.23 issued both A and AAAA = quires, it=20 completely ignored AAAA RR and only used IPv4 for=20 = communication.

Thank you.

 
Please also see some of = other test results below. = DS-Lite/NAT64 experiments could be documented if it is=20 of interests. =

If you can share your results, that's always useful = information.
Accordingly, if someone has results concerning = native IPv6 (e2e transparent, i.e. without NAT64) plus statelessly = tunneled IPv4, that would be nice to = have.

Regards,
RD

<= div>
 
Tested Apps                   IPv4/IPv6 = portion
Firefox = (Non-vedio) v3.6.12   = All IPv6            = ;            &= nbsp;   =20
video = website            = ;    =20 Half/ half          =20  
IE = (Non-vedio) v6.0  =20      =    All IPv6            = ;            &= nbsp;  =20
Skype = v5.0           =20        =20 Major IPv6          =20              = ; =20
Google = Earth v5.2.1          =20 Major IPv6           &nb= sp; =20      =20
Live = Messenger 2009          =20 Major IPv4           =20
uTorrent= v2.2            = ;    =20 Major IPv4    =20
BitComet = v1.23            = ;   =20 All IPv4      =20

 

BR,
Xiaohong
 

=E5=8F=91=E4=BB=B6=E4=BA= =BA: R=C3=A9mi Despr=C3=A9s [mailto:remi.despres@free.fr]=20
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2011=E5=B9=B44=E6=9C=88= 7=E6=97=A5 0:21
=E6=94=B6=E4=BB=B6=E4=BA=BA: DENG Xiaohong=20 ESP/PEK
=E6=8A=84=E9=80=81: int-area@ietf.org
=E4=B8=BB=E9= =A2=98: Re: [Int-area] Stateless=20 IPv4-in-IPv6 experiments

Thank you, Xiahong, for sharing this interesting = information.

In the case of BitComet and uTorrent, I wonder what happens if = the host=20 has both A+P IPv4 and IPv6, as opposed to just A+P IPv4.
Did you try that?

Regards,
RD

Le 6 avr. 2011 =C3=A0 10:57, <xiaohong.deng@orange-ftgr= oup.com>=20 <xiaohong.deng@orange-ftgr= oup.com>=20 a =C3=A9crit :

Dear=20 all,
 
An I-D about = stateless IPv4-in-IPv6 = experiments has been submitted.=20 A URL for this=20 Internet-Draft is: http://tools.ietf.org/html/draft-deng-aplusp-experiment-= results-00.
 
A website=20 introducing the detail of experiment results is also accessible = via: http://opensourceaplusp.weebly.com/
 
BR,
Xiaohong
_____________________________= __________________
Int-area=20 mailing list
Int-area@ietf.org
https://www.ietf.o= rg/mailman/listinfo/int-area


= --Apple-Mail-28--416943308-- From tena@huawei.com Fri Apr 8 13:28:30 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8664E3A6957; Fri, 8 Apr 2011 13:28:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.276 X-Spam-Level: X-Spam-Status: No, score=-106.276 tagged_above=-999 required=5 tests=[AWL=0.323, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ft3TJl24cW9k; Fri, 8 Apr 2011 13:28:22 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id 5B0CC3A68CB; Fri, 8 Apr 2011 13:28:22 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJC00CCNOY7YV@usaga02-in.huawei.com>; Fri, 08 Apr 2011 13:30:07 -0700 (PDT) Received: from TingZousc1 ([10.212.246.132]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LJC005F4OY58P@usaga02-in.huawei.com>; Fri, 08 Apr 2011 13:30:07 -0700 (PDT) Date: Fri, 08 Apr 2011 13:30:05 -0700 From: Tina Tsou To: 'MBONED WG' , pim@ietf.org, 'IPv6 Ops WG' , behave@ietf.org, softwires@ietf.org Message-id: <010001cbf62b$bfc24e40$3f46eac0$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: AQEvzYA9JGDJgObGWqAS/HlE5dNRbJWMr2vQgAAKSVA= Cc: multrans@ietf.org Subject: [BEHAVE] You are invited to subscribe to the multrans list X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 08 Apr 2011 20:28:30 -0000 Hi all, You are invited to subscribe to the multrans list. https://www.ietf.org/mailman/listinfo/multrans You are invited to comment on https://datatracker.ietf.org/doc/draft-jaclee-behave-v4v6-mcast-ps/ to the multrans list. We keep our promises with one another - no matter what! Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html -----Original Message----- From: Steve Young [mailto:stevey@amsl.com] Sent: Friday, April 08, 2011 12:43 PM To: tena@huawei.com; tina.tsou.zouting@huawei.com Subject: Your new mailing list: multrans The mailing list `multrans' has just been created for you. The following is some basic information about your mailing list. Your mailing list password is: ... You need this password to configure your mailing list. You also need it to handle administrative requests, such as approving mail if you choose to run a moderated list. You can configure your mailing list at the following web page: https://www.ietf.org/mailman/admin/multrans The web page for users of your mailing list is: https://www.ietf.org/mailman/listinfo/multrans You can even customize these web pages from the list configuration page. However, you do need to know HTML to be able to do this. There is also an email-based interface for users (not administrators) of your list; you can get info about using it by sending a message with just the word `help' as subject or in the body, to: multrans-request@ietf.org To unsubscribe a user: from the mailing list 'listinfo' web page, click on or enter the user's email address as if you were that user. Where that user would put in their password to unsubscribe, put in your admin password. You can also use your password to change member's options, including digestification, delivery disabling, etc. Your mailing list is configured with a public archive which can be found at: http://www.ietf.org/mail-archive/web/multrans Please note: the archive will not be created until a message has been sent to the list and the archiving process has run (runs at 10, 30, 50 past each hour). Please address all questions to mailman-owner@ietf.org. From Internet-Drafts@ietf.org Tue Apr 12 06:15:04 2011 Return-Path: X-Original-To: behave@ietfc.amsl.com Delivered-To: behave@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 436FCE0697; Tue, 12 Apr 2011 06:15:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.188 X-Spam-Level: X-Spam-Status: No, score=-102.188 tagged_above=-999 required=5 tests=[AWL=0.411, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Junite1vg6Wd; Tue, 12 Apr 2011 06:15:03 -0700 (PDT) Received: from ietfc.amsl.com (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id F25E3E0709; Tue, 12 Apr 2011 06:15:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.16 Message-ID: <20110412131502.6177.49541.idtracker@ietfc.amsl.com> Date: Tue, 12 Apr 2011 06:15:02 -0700 Cc: behave@ietf.org Subject: [BEHAVE] I-D Action:draft-ietf-behave-v4v6-bih-04.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 13:15:04 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : Dual Stack Hosts Using "Bump-in-the-Host" (BIH) Author(s) : B. Huang, et al. Filename : draft-ietf-behave-v4v6-bih-04.txt Pages : 28 Date : 2011-04-12 Bump-In-the-Host (BIH) is a host-based IPv4 to IPv6 protocol translation mechanism that allows a class of IPv4-only applications that work through NATs to communicate with IPv6-only peers. The host on which applications are running may be connected to IPv6-only or dual-stack access networks. BIH hides IPv6 and makes the IPv4-only applications think they are talking with IPv4 peers by local synthesis of IPv4 addresses. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-v4v6-bih-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-behave-v4v6-bih-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-04-12061318.I-D@ietf.org> --NextPart-- From teemu.savolainen@nokia.com Tue Apr 12 06:25:54 2011 Return-Path: X-Original-To: behave@ietfc.amsl.com Delivered-To: behave@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 93CA3E079C for ; Tue, 12 Apr 2011 06:25:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.492 X-Spam-Level: X-Spam-Status: No, score=-4.492 tagged_above=-999 required=5 tests=[AWL=-1.893, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v9p--4VD88EI for ; Tue, 12 Apr 2011 06:25:53 -0700 (PDT) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfc.amsl.com (Postfix) with ESMTP id A57E2E07A1 for ; Tue, 12 Apr 2011 06:25:53 -0700 (PDT) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-sa02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p3CDPhPB008575 for ; Tue, 12 Apr 2011 16:25:49 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 12 Apr 2011 16:25:47 +0300 Received: from 008-AM1MMR1-006.mgdnok.nokia.com (65.54.30.61) by NOK-am1MHUB-01.mgdnok.nokia.com (65.54.30.5) with Microsoft SMTP Server (TLS) id 8.2.255.0; Tue, 12 Apr 2011 15:25:47 +0200 Received: from 008-AM1MPN1-036.mgdnok.nokia.com ([169.254.6.195]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi id 14.01.0270.002; Tue, 12 Apr 2011 15:25:47 +0200 From: To: Thread-Topic: [BEHAVE] I-D Action:draft-ietf-behave-v4v6-bih-04.txt Thread-Index: AQHL+ROpcQ9OgiAJK0yjpTFusUDCTpRaN7vg Date: Tue, 12 Apr 2011 13:25:46 +0000 Message-ID: <916CE6CF87173740BC8A2CE4430969620216B4@008-AM1MPN1-036.mgdnok.nokia.com> References: <20110412131502.6177.49541.idtracker@ietfc.amsl.com> In-Reply-To: <20110412131502.6177.49541.idtracker@ietfc.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.162.157.91] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 12 Apr 2011 13:25:47.0659 (UTC) FILETIME=[2260CDB0:01CBF915] X-Nokia-AV: Clean Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-v4v6-bih-04.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 13:25:54 -0000 Hi, This revision should have all comments included that were received during t= he WGLC. Teemu > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of ext Internet-Drafts@ietf.org > Sent: 12. huhtikuuta 2011 16:15 > To: i-d-announce@ietf.org > Cc: behave@ietf.org > Subject: [BEHAVE] I-D Action:draft-ietf-behave-v4v6-bih-04.txt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Behavior Engineering for Hindrance > Avoidance Working Group of the IETF. >=20 >=20 > Title : Dual Stack Hosts Using "Bump-in-the-Host" (BIH) > Author(s) : B. Huang, et al. > Filename : draft-ietf-behave-v4v6-bih-04.txt > Pages : 28 > Date : 2011-04-12 >=20 > Bump-In-the-Host (BIH) is a host-based IPv4 to IPv6 protocol > translation mechanism that allows a class of IPv4-only applications > that work through NATs to communicate with IPv6-only peers. The host > on which applications are running may be connected to IPv6-only or > dual-stack access networks. BIH hides IPv6 and makes the IPv4-only > applications think they are talking with IPv4 peers by local synthesis > of IPv4 addresses. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-behave-v4v6-bih-04.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. From ajs@shinkuro.com Wed Apr 13 08:32:16 2011 Return-Path: X-Original-To: behave@ietfc.amsl.com Delivered-To: behave@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 60013E0705 for ; Wed, 13 Apr 2011 08:32:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.639 X-Spam-Level: X-Spam-Status: No, score=-102.639 tagged_above=-999 required=5 tests=[AWL=-0.040, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KP-Gh5YX2lli for ; Wed, 13 Apr 2011 08:32:15 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfc.amsl.com (Postfix) with ESMTP id A23BDE06BB for ; Wed, 13 Apr 2011 08:32:15 -0700 (PDT) Received: from shinkuro.com (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 3345D1ECB420 for ; Wed, 13 Apr 2011 15:32:15 +0000 (UTC) Date: Wed, 13 Apr 2011 11:32:13 -0400 From: Andrew Sullivan To: behave@ietf.org Message-ID: <20110413153213.GN24471@crankycanuck.ca> References: <25942.1301412503@marajade.sandelman.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <25942.1301412503@marajade.sandelman.ca> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [BEHAVE] TTL in reply for DNS64 -- should be 1. X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 15:32:16 -0000 Hi, On Tue, Mar 29, 2011 at 05:28:23PM +0200, Michael Richardson wrote: > It wasn't until I started filling out they survey that I realized I > should flush my DNS cache, that I'd have to. So, this needs to be > addressed somewhere --- we really need some signal in the RA that there > is a NAT64 available, and therefore if you have a local recursive > resolver, you should either do DNS64, or you should pay more serious > attention to the DNS value you get from the RA (or the DHCPv6). I think the draft actually points out that a local, DNS64-unaware recursive resolver is going to be hosed in a NAT64 (that's what section 6 is about), although if it's not clear enough I'd be delighted to receive suggestions so that when we return to this specification in the next iteration, we can make it better. There is some current work going on to try to detect DNS64 (IMO, we are going to pick the ugliest and worst answer for this, but I don't have a better solution given the constraints we're facing). > The TTL in the reply is way too high. I can easily imagine wandering > in and out of IPv6 only networks (with suspends in between). I > shouldn't have to flush my DNS cache each time. > > I'd like to suggest that the TTL be 1. I very strongly disagree. It is certainly true that you should not have to flush your DNS cache each time you move between one DNS realm and another, when you're going to get different answers from the DNS for the same qtuple. But this is not a reason to make the TTL of answers be 1. It is instead a reason for your network manager to do the right thing rather than ignoring this problem. Making the TTL 1 will mean that local caches cannot work effectively, which will increase load on the DNS64 in the non-unusual case when you remain in the same network. > I can see that this is trying to find a heuristic that tries to find a > reasonable upper bound so that if a AAAA does appear then it won't take > too long to discover this. > > Unfortunately, it fails, I think, for mobile nodes that can be on > different networks in series without restarting. I.e. laptops and > smartphones. The DNS is loosely coherent. If we're going to start fooling with the answers (an admittedly dirty hack to begin with), then that loose coherence is going to be strained when moving in and out of realms where DNS64 is deployed. I have my doubts that this will be quite so common as you seem to be suggesting, but even if it is, I think that's part of the cost of using NAT to solve this problem. Making all caches last a second seems to me to be at least as bad as the symptom we're trying to cure. Moreover, it won't work anyway, since some applications will cleave to the first record they get even after the TTL is expired (especially if it's that short). Best, A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From matthew@matthew.at Wed Apr 13 09:02:39 2011 Return-Path: X-Original-To: behave@ietfc.amsl.com Delivered-To: behave@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A9DDAE0749 for ; Wed, 13 Apr 2011 09:02:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.429 X-Spam-Level: X-Spam-Status: No, score=-1.429 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x2aFUfp9DYz5 for ; Wed, 13 Apr 2011 09:02:39 -0700 (PDT) Received: from where.matthew.at (where.matthew.at [198.202.199.1]) by ietfc.amsl.com (Postfix) with ESMTP id 33900E073E for ; Wed, 13 Apr 2011 09:02:38 -0700 (PDT) Received: from [10.10.155.2] (unknown [10.10.155.2]) by where.matthew.at (Postfix) with ESMTP id CD1D614806C; Wed, 13 Apr 2011 09:02:37 -0700 (PDT) Message-ID: <4DA5C92A.7080408@matthew.at> Date: Wed, 13 Apr 2011 09:02:50 -0700 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Andrew Sullivan References: <25942.1301412503@marajade.sandelman.ca> <20110413153213.GN24471@crankycanuck.ca> In-Reply-To: <20110413153213.GN24471@crankycanuck.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: behave@ietf.org Subject: Re: [BEHAVE] TTL in reply for DNS64 -- should be 1. X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: matthew@matthew.at List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 16:02:39 -0000 On 4/13/2011 8:32 AM, Andrew Sullivan wrote: > > The DNS is loosely coherent. If we're going to start fooling with the > answers (an admittedly dirty hack to begin with), then that loose > coherence is going to be strained when moving in and out of realms > where DNS64 is deployed. I have my doubts that this will be quite so > common as you seem to be suggesting,... > This feels like it will be *very* common. We already have one mobile operator testing a NAT64 deployment, and when my mobile phone is at home it is on an 802.11 network with native IPv6. So every time I walk up and down the street I go in and out of a NAT64 environment (or would, if I was using that carrier). Matthew Kaufman From ajs@shinkuro.com Wed Apr 13 09:14:54 2011 Return-Path: X-Original-To: behave@ietfc.amsl.com Delivered-To: behave@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D8D9DE0807 for ; Wed, 13 Apr 2011 09:14:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.634 X-Spam-Level: X-Spam-Status: No, score=-102.634 tagged_above=-999 required=5 tests=[AWL=-0.035, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G1RSL-2Px62e for ; Wed, 13 Apr 2011 09:14:54 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfc.amsl.com (Postfix) with ESMTP id 4D686E07CE for ; Wed, 13 Apr 2011 09:14:54 -0700 (PDT) Received: from shinkuro.com (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id D94731ECB420 for ; Wed, 13 Apr 2011 16:14:53 +0000 (UTC) Date: Wed, 13 Apr 2011 12:14:52 -0400 From: Andrew Sullivan To: behave@ietf.org Message-ID: <20110413161451.GT24471@crankycanuck.ca> References: <25942.1301412503@marajade.sandelman.ca> <20110413153213.GN24471@crankycanuck.ca> <4DA5C92A.7080408@matthew.at> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DA5C92A.7080408@matthew.at> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [BEHAVE] TTL in reply for DNS64 -- should be 1. X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 16:14:55 -0000 On Wed, Apr 13, 2011 at 09:02:50AM -0700, Matthew Kaufman wrote: > > This feels like it will be *very* common. We already have one mobile > operator testing a NAT64 deployment, and when my mobile phone is at > home it is on an 802.11 network with native IPv6. So every time I > walk up and down the street I go in and out of a NAT64 environment > (or would, if I was using that carrier). Well, yes, but is your phone caching its DNS responses? And if so, does it respect the TTL from the RR that it gets back? Remember, reducing the TTL will only work in the case where your end node has a cache, that cache is DNS64-unaware, and there is no mechanism to tell it that it has changed upstream DNS sources. If your network manager notices that it has moved from one v6 network to another, then it probably needs to flush your DNS cache. This is already true today, even though we would like it not to be. The DNS hasn't been a unified namespace for a long time, and your local DNS server may well provide you with results local to your network. Moreover, mDNS is all but guaranteed to do so. So your network manager, if you are using mDNS, already needs to know how to do some of this. There is, moreover, the fact that some applications don't release the address record they have even if the TTL expires. I don't think the way to fix this generic problem is to turn down the TTL for one species of the problem. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From simon.perreault@viagenie.ca Wed Apr 13 09:16:49 2011 Return-Path: X-Original-To: behave@ietfc.amsl.com Delivered-To: behave@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 0FE25E0821 for ; Wed, 13 Apr 2011 09:16:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.445 X-Spam-Level: X-Spam-Status: No, score=-2.445 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l6spj6-rV+ir for ; Wed, 13 Apr 2011 09:16:48 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfc.amsl.com (Postfix) with ESMTP id 6F1ECE0815 for ; Wed, 13 Apr 2011 09:16:48 -0700 (PDT) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id AC61B20D23 for ; Wed, 13 Apr 2011 12:16:47 -0400 (EDT) Message-ID: <4DA5CC6F.2030600@viagenie.ca> Date: Wed, 13 Apr 2011 12:16:47 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110320 Fedora/3.1.9-4.fc16 Lightning/1.0b3pre Thunderbird/3.1.9 MIME-Version: 1.0 To: behave@ietf.org References: <25942.1301412503@marajade.sandelman.ca> <20110413153213.GN24471@crankycanuck.ca> <4DA5C92A.7080408@matthew.at> <20110413161451.GT24471@crankycanuck.ca> In-Reply-To: <20110413161451.GT24471@crankycanuck.ca> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] TTL in reply for DNS64 -- should be 1. X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 16:16:49 -0000 On 2011-04-13 12:14, Andrew Sullivan wrote: > I don't think the way to fix this generic problem is to turn down the > TTL for one species of the problem. +1 The network manager is where this should be fixed. 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 matthew@matthew.at Wed Apr 13 10:33:23 2011 Return-Path: X-Original-To: behave@ietfc.amsl.com Delivered-To: behave@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 849B0E07D0 for ; Wed, 13 Apr 2011 10:33:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.43 X-Spam-Level: X-Spam-Status: No, score=-1.43 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rR4kWacPMOua for ; Wed, 13 Apr 2011 10:33:23 -0700 (PDT) Received: from where.matthew.at (where.matthew.at [198.202.199.1]) by ietfc.amsl.com (Postfix) with ESMTP id 04F35E0704 for ; Wed, 13 Apr 2011 10:33:22 -0700 (PDT) Received: from [10.10.155.2] (unknown [10.10.155.2]) by where.matthew.at (Postfix) with ESMTP id 6AACB14806C; Wed, 13 Apr 2011 10:33:22 -0700 (PDT) Message-ID: <4DA5DE6F.4060407@matthew.at> Date: Wed, 13 Apr 2011 10:33:35 -0700 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Andrew Sullivan References: <25942.1301412503@marajade.sandelman.ca> <20110413153213.GN24471@crankycanuck.ca> <4DA5C92A.7080408@matthew.at> <20110413161451.GT24471@crankycanuck.ca> In-Reply-To: <20110413161451.GT24471@crankycanuck.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: behave@ietf.org Subject: Re: [BEHAVE] TTL in reply for DNS64 -- should be 1. X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: matthew@matthew.at List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 17:33:23 -0000 On 4/13/2011 9:14 AM, Andrew Sullivan wrote: > On Wed, Apr 13, 2011 at 09:02:50AM -0700, Matthew Kaufman wrote: >> This feels like it will be *very* common. We already have one mobile >> operator testing a NAT64 deployment, and when my mobile phone is at >> home it is on an 802.11 network with native IPv6. So every time I >> walk up and down the street I go in and out of a NAT64 environment >> (or would, if I was using that carrier). > > I don't think the way to fix this generic problem is to turn down the > TTL for one species of the problem. > I wasn't arguing for the particular solution, just that the hypothetical situation (of moving in/out of NAT64) seems much more likely to be commonplace. Matthew Kaufman From iljitsch@muada.com Wed Apr 13 14:48:39 2011 Return-Path: X-Original-To: behave@ietfc.amsl.com Delivered-To: behave@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 53C10E07BA for ; Wed, 13 Apr 2011 14:48:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tzySC4TNMjtr for ; Wed, 13 Apr 2011 14:48:38 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) by ietfc.amsl.com (Postfix) with ESMTP id 9741FE07AC for ; Wed, 13 Apr 2011 14:48:38 -0700 (PDT) Received: from [192.168.0.140] (static-167-138-7-89.ipcom.comunitel.net [89.7.138.167] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id p3DLo6Bx045531 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 13 Apr 2011 23:50:07 +0200 (CEST) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Iljitsch van Beijnum In-Reply-To: <25942.1301412503@marajade.sandelman.ca> Date: Wed, 13 Apr 2011 23:48:28 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <11F23F73-E5B9-4FF6-A812-752165C5E1CE@muada.com> References: <25942.1301412503@marajade.sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.1084) Cc: behave@ietf.org Subject: Re: [BEHAVE] TTL in reply for DNS64 -- should be 1. X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 21:48:39 -0000 On 29 mrt 2011, at 17:28, Michael Richardson wrote: > we really need some signal in the RA that there > is a NAT64 available, and therefore if you have a local recursive > resolver, you should either do DNS64, or you should pay more serious > attention to the DNS value you get from the RA (or the DHCPv6). Adding stuff to RAs is even harder than adding stuff to DHCP. I don't = think handling this corner case more gracefully is worth the trouble. If people have IPv6 but no IPv4 and run a local recursive DNS then = presumably they'll have an incentive to investigate the availability of = NAT64. But if your favorite DNS vendor wants to add a config option = "forward-first-if-no-ipv4-available" nothing's stopping them.= From dthaler@microsoft.com Thu Apr 14 09:11:22 2011 Return-Path: X-Original-To: behave@ietfc.amsl.com Delivered-To: behave@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C7F1EE0814 for ; Thu, 14 Apr 2011 09:11:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.527 X-Spam-Level: X-Spam-Status: No, score=-110.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ibWLILsPAwTo for ; Thu, 14 Apr 2011 09:11:21 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by ietfc.amsl.com (Postfix) with ESMTP id A06DAE0803 for ; Thu, 14 Apr 2011 09:11:19 -0700 (PDT) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (157.54.80.25) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 14 Apr 2011 09:11:18 -0700 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14HUBC104.redmond.corp.microsoft.com (157.54.80.25) with Microsoft SMTP Server (TLS) id 14.1.289.8; Thu, 14 Apr 2011 09:11:18 -0700 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.127]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.01.0270.002; Thu, 14 Apr 2011 09:11:18 -0700 From: Dave Thaler To: Andrew Sullivan , "behave@ietf.org" Thread-Topic: [BEHAVE] TTL in reply for DNS64 -- should be 1. Thread-Index: AQHL78sW73UzrluHSkS+Wvvdor9z4ZRcda6AgAEnVFA= Date: Thu, 14 Apr 2011 16:11:17 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B043BC7@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> References: <25942.1301412503@marajade.sandelman.ca> <20110413153213.GN24471@crankycanuck.ca> In-Reply-To: <20110413153213.GN24471@crankycanuck.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.42] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [BEHAVE] TTL in reply for DNS64 -- should be 1. 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, 14 Apr 2011 16:11:22 -0000 [...] > > The TTL in the reply is way too high. I can easily imagine wandering > > in and out of IPv6 only networks (with suspends in between). I > > shouldn't have to flush my DNS cache each time. > > > > I'd like to suggest that the TTL be 1. >=20 > I very strongly disagree. >=20 > It is certainly true that you should not have to flush your DNS cache eac= h time > you move between one DNS realm and another, when you're going to get > different answers from the DNS for the same qtuple. But this is not a re= ason to > make the TTL of answers be 1. It is instead a reason for your network ma= nager > to do the right thing rather than ignoring this problem. [...] I completely agree with Andrew. If there's a cache in the host, then the host is responsible for flushing the cache when you change networks. This= =20 is not a reason to punish everyone else by making TTL=3D1. -Dave From cb.list6@gmail.com Thu Apr 14 09:16:08 2011 Return-Path: X-Original-To: behave@ietfc.amsl.com Delivered-To: behave@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D3651E07FD for ; Thu, 14 Apr 2011 09:16:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.838 X-Spam-Level: X-Spam-Status: No, score=-2.838 tagged_above=-999 required=5 tests=[AWL=0.761, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 70KphiNXt7jg for ; Thu, 14 Apr 2011 09:16:08 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfc.amsl.com (Postfix) with ESMTP id 1C2F6E06A4 for ; Thu, 14 Apr 2011 09:16:07 -0700 (PDT) Received: by eye13 with SMTP id 13so651033eye.31 for ; Thu, 14 Apr 2011 09:16:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=EnBIkVjYt19u/8UbU1bUcUEtslfwN53lEmsZXaGxxkk=; b=hx6Ajm0KpEjA9Zl8ChfhkY0J5KHpvHO3h7NxUHwySA5kC60CNcIug4HWzBmhiUHsMr 5iLu+tkl+za3x7QUYy5ESwj1EYOgDCrLP4Hy/6SZvfWKkFzR2vanEtMrHkqbFqJGl8e9 pyTgTVaSbBv6wwb8e/AzpJalkN/sypf95qHsU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=gVnb+Ixbte+Lv7MqfRCN0P1ZB5iOQa9TNGvssbcKvmYBsKFwom90GIUiFFdAL8X6uk jn6RsFL7bFLVxxYt018/j/5BKsCRISf+6BPsEv3+/f3ooX+FKV35mI+5iJjEs/ianKZO oNVOC6BX7xYbOVhSys5jHtgoodq9hrflPhhAA= MIME-Version: 1.0 Received: by 10.213.15.82 with SMTP id j18mr2574378eba.82.1302797767296; Thu, 14 Apr 2011 09:16:07 -0700 (PDT) Received: by 10.213.113.194 with HTTP; Thu, 14 Apr 2011 09:16:07 -0700 (PDT) In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B043BC7@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> References: <25942.1301412503@marajade.sandelman.ca> <20110413153213.GN24471@crankycanuck.ca> <9B57C850BB53634CACEC56EF4853FF653B043BC7@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Date: Thu, 14 Apr 2011 09:16:07 -0700 Message-ID: From: Cameron Byrne To: Dave Thaler Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Andrew Sullivan , "behave@ietf.org" Subject: Re: [BEHAVE] TTL in reply for DNS64 -- should be 1. 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, 14 Apr 2011 16:16:09 -0000 On Thu, Apr 14, 2011 at 9:11 AM, Dave Thaler wrote: > [...] >> > The TTL in the reply is way too high. =A0 I can easily imagine wanderi= ng >> > in and out of IPv6 only networks (with suspends in between). =A0 I >> > shouldn't have to flush my DNS cache each time. >> > >> > I'd like to suggest that the TTL be 1. >> >> I very strongly disagree. >> >> It is certainly true that you should not have to flush your DNS cache ea= ch time >> you move between one DNS realm and another, when you're going to get >> different answers from the DNS for the same qtuple. =A0But this is not a= reason to >> make the TTL of answers be 1. =A0It is instead a reason for your network= manager >> to do the right thing rather than ignoring this problem. > [...] > > I completely agree with Andrew. =A0 If there's a cache in the host, then = the > host is responsible for flushing the cache when you change networks. =A0T= his > is not a reason to punish everyone else by making TTL=3D1. > Completely agree. Cameron From Francis.Dupont@fdupont.fr Fri Apr 22 05:42:44 2011 Return-Path: X-Original-To: behave@ietfc.amsl.com Delivered-To: behave@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D25E0E067C; Fri, 22 Apr 2011 05:42:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jxOHQzPlvy-2; Fri, 22 Apr 2011 05:42:44 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfc.amsl.com (Postfix) with ESMTP id 231D2E0664; Fri, 22 Apr 2011 05:42:44 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id p3MCghWW022871; Fri, 22 Apr 2011 14:42:43 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201104221242.p3MCghWW022871@givry.fdupont.fr> From: Francis Dupont To: pcp@ietf.org Date: Fri, 22 Apr 2011 14:42:43 +0200 Sender: Francis.Dupont@fdupont.fr Cc: behave@ietf.org Subject: [BEHAVE] about PCP (in)security 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, 22 Apr 2011 12:42:45 -0000 I am afraid the current specs don't correctly assume the fact PCP no longer applies to residential gateways as NAT-PMP does, but is intended to be used with CGNs which have some critical security constraints (something clear now the definition of a CGN is based on security considerations). There are IMHO two ways to solve this problem: - to get all the security sensible requirements in the BEHAVE CGN requirements document and refers to it. This has some obvious drawbacks, in particular this creates a normative reference to a document which is far to be published if it will be one day. - the other solution is to duplicate the work and to put these requirements in the PCP base specs. Of course this is not fine: these requirements are not in general specific to PCP, it is a duplicated and out of scope work, etc. PCP WG chairs want to follow a third way: do nothing. I send this message to express my formal disapproval to this (non) solution. Regards Francis.Dupont@fdupont.fr From xing@cernet.edu.cn Mon Apr 25 17:02:07 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0F42E068D for ; Mon, 25 Apr 2011 17:02:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.903 X-Spam-Level: X-Spam-Status: No, score=-99.903 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HAS_XAIMC=2.696, 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 fGTQ+vswCIPE for ; Mon, 25 Apr 2011 17:02:07 -0700 (PDT) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.39.2]) by ietfa.amsl.com (Postfix) with SMTP id CCE69E062A for ; Mon, 25 Apr 2011 17:02:06 -0700 (PDT) Received: from [127.0.0.1]([125.34.55.89]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm74db636cc; Tue, 26 Apr 2011 08:02:04 +0800 Message-ID: <4DB60B7A.9020701@cernet.edu.cn> Date: Tue, 26 Apr 2011 08:02:02 +0800 From: Xing Li User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; zh-CN; rv:1.9.2.14) Gecko/20110221 Thunderbird/3.1.8 MIME-Version: 1.0 To: dthaler@microsoft.com, Dan Wing Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-AIMC-AUTH: xing X-AIMC-MAILFROM: xing@cernet.edu.cn X-AIMC-Msg-ID: q3Kj5O0B Cc: Congxiao Bao , behave@ietf.org, leo.vegoda@icann.org, Xing Li , behave-chairs@tools.ietf.org, "Ramji Vaithianathan \(rvaithia\)" , Geoff Huston Subject: [BEHAVE] updates of draft-xli-behave-icmp-address X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 00:02:07 -0000 Dear Behave Working Group Chairs, We have uploaded a simplified version of draft-xli-behave-icmp-address in https://datatracker.ietf.org/doc/draft-xli-behave-icmp-address/ The goal of this draft is to get an IPv4 /24 from IANA that can make the vendor and operator to implement stateless IPv4/IPv6 translation (RFC-to-be 6145) without worrying the uncertainty of the source address of the ICMP packets which are translated from ICMPv6 packets by an IPv4/IPv6 translator. The authors think this draft is a very important late addendum to the IPv4/IPv6 translation RFC and ¡°RFC-to-be¡±s and request Behave WG¡¯s review and adoption. Thank you very much! Xing Li, Congxiao Bao, Dan Wing, Ramji Vaithianathan and Geoff Huston From dwing@cisco.com Tue Apr 26 14:08:19 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CBC6E0812 for ; Tue, 26 Apr 2011 14:08:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.389 X-Spam-Level: X-Spam-Status: No, score=-110.389 tagged_above=-999 required=5 tests=[AWL=0.210, 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 j43zWDBTYbGk for ; Tue, 26 Apr 2011 14:08:18 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id 953B6E080E for ; Tue, 26 Apr 2011 14:08:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=154; q=dns/txt; s=iport; t=1303852098; x=1305061698; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=IXRgyqzsGTILPxBMD0wDkmC7vedht5HEcYV8Nbf1EA8=; b=Y2saNAVQ3ebADaV8iyEQPWK8jk1qfg0oqxWh2OBE7gzpGbezGcMqRSkT 5KoP7e0EsSsyE9eIqyeoN0+fACPqUvAxw5/QnFCYemCEgq9EW2zwc2FWk RJTDhnNr7iUq3MaMhqg00qH6JylyxPTrh8rrjgC7MszWPOuUOqH9xYVzd 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAIABkzt02rRDoJ/2dsb2JhbACYOIEkjAt3qledEYV2BIV9lwQ X-IronPort-AV: E=Sophos;i="4.64,270,1301875200"; d="scan'208";a="436830860" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-1.cisco.com with ESMTP; 26 Apr 2011 21:08:18 +0000 Received: from dwingWS ([10.32.240.195]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p3QL8IjT023026; Tue, 26 Apr 2011 21:08:18 GMT From: "Dan Wing" To: Date: Tue, 26 Apr 2011 14:08:18 -0700 Message-ID: <07d601cc0456$10dd2a10$32977e30$@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: AcwEVhCoD7suv2q/QdOhwhw1hQEP7A== Content-Language: en-us Cc: 'Behave Chairs' Subject: [BEHAVE] IETF80 minutes posted X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 21:08:19 -0000 BEHAVE minutes are posted at: http://www.ietf.org/proceedings/80/minutes/behave.txt Please email the chairs if you have changes/corrections. -d From mcr@sandelman.ca Wed Apr 27 06:22:50 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 029CBE074C for ; Wed, 27 Apr 2011 06:22:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.954 X-Spam-Level: X-Spam-Status: No, score=-1.954 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] 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 sLguxvNR+Mfe for ; Wed, 27 Apr 2011 06:22:40 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 5F8C3E074B for ; Wed, 27 Apr 2011 06:22:39 -0700 (PDT) Received: from marajade.sandelman.ca (unknown [206.47.3.30]) by relay.sandelman.ca (Postfix) with ESMTPS id 3265C34014 for ; Wed, 27 Apr 2011 09:22:39 -0400 (EDT) Received: from marajade.sandelman.ca (marajade.sandelman.ca [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 53C4898B29 for ; Wed, 27 Apr 2011 09:23:39 -0400 (EDT) From: Michael Richardson To: behave@ietf.org In-Reply-To: <20110413153213.GN24471@crankycanuck.ca> References: <25942.1301412503@marajade.sandelman.ca> <20110413153213.GN24471@crankycanuck.ca> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 27 Apr 2011 09:23:39 -0400 Message-ID: <10904.1303910619@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [BEHAVE] TTL in reply for DNS64 -- should be 1. X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 13:22:50 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable {my appologies for late reply: I read my IETF lists in large chunks. On the other hand, I can read the entire thread before replying} >>>>> "Andrew" =3D=3D Andrew Sullivan writes: Andrew> There is some current work going on to try to detect DNS64 Andrew> (IMO, we are going to pick the ugliest and worst answer for Andrew> this, but I don't have a better solution given the Andrew> constraints we're facing). I am in favour of heuristics, but they should be a mitigation until a non-heuristic signal is available.=20=20 An RA option seems like a great thing to me, and I can't see why how long this will take to standardize should matter.=20=20 Andrew> It is certainly true that you should not have to flush your Andrew> DNS cache each time you move between one DNS realm and Andrew> another, when you're going to get different answers from the Andrew> DNS for the same qtuple. But this is not a reason to make Andrew> the TTL of answers be 1. It is instead a reason for your Andrew> network manager to do the right thing rather than ignoring Andrew> this problem. okay, I will buy this. My preference is really to do the AAAA synthesis locally, where I also want to do DNSSEC. If I have that RA signal that I should do it, then I'm set, and I can flush as necessary. >> Unfortunately, it fails, I think, for mobile nodes that can be on >> different networks in series without restarting. I.e. laptops >> and smartphones. Andrew> The DNS is loosely coherent. If we're going to start Andrew> fooling with the answers (an admittedly dirty hack to begin Andrew> with), then that loose coherence is going to be strained Andrew> when moving in and out of realms where DNS64 is deployed. I Andrew> have my doubts that this will be quite so common as you seem Andrew> to be suggesting, but even if it is, I think that's part of Andrew> the cost of using NAT to solve this problem. Making all Andrew> caches last a second seems to me to be at least as bad as Andrew> the symptom we're trying to cure. Moreover, it won't work Andrew> anyway, since some applications will cleave to the first Andrew> record they get even after the TTL is expired (especially if Andrew> it's that short). Yes, I agree that this is a problem. >>>>> "Iljitsch" =3D=3D Iljitsch van Beijnum writes: Iljitsch> On 29 mrt 2011, at 17:28, Michael Richardson wrote: >> we really need some signal in the RA that there is a NAT64 >> available, and therefore if you have a local recursive resolver, >> you should either do DNS64, or you should pay more serious >> attention to the DNS value you get from the RA (or the DHCPv6). Iljitsch> Adding stuff to RAs is even harder than adding stuff to Iljitsch> DHCP. I don't think handling this corner case more Iljitsch> gracefully is worth the trouble. okay, I find this very surprising. Iljitsch> If people have IPv6 but no IPv4 and run a local recursive Iljitsch> DNS then presumably they'll have an incentive to Iljitsch> investigate the availability of NAT64. okay, so the problem is we need a signal that NAT64 is available so that local synethesis can occur. +1 on the network manager doing this. =2D-=20 ] He who is tired of Weird Al is tired of life! | firewall= s [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net archit= ect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device dri= ver[ Kyoto Plus: watch the video then sign the petition.=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEVAwUATbgY2oCLcPvd0N1lAQJaGAf+Ig3oyIhhXwYrk7IysCBTxq7krpgIN/Qo I44jJjnjmiaehS5iSrRDB0cGl+apIzvy5yPw8+EFZxXCK16pgF163VQAz8avMbfx pF9tuzQeocpPjf11LH8UFG20xpZjndn2D6m9/0vez+cQYR1H3ByA+F/VwR4TfTg8 8imxKpx31WrrB5AcToTTIUX5qxQ9hWdrrJHW/pjT6gsMbHzuOOZE2RONntkYCgVZ fgEAQHrN/en9anHFQX8RXOcm41G0TLFagVnCVcGjJXYVXbU5yBJmMY1Cp7XXGdvJ 4Ygnbd8X5eoWTgg5apjTfzxBvUG5QuMMHZEzHn427qq8v9Up0dk2Lw== =HG+6 -----END PGP SIGNATURE----- --=-=-=-- From iljitsch@muada.com Wed Apr 27 06:59:30 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79286E069F for ; Wed, 27 Apr 2011 06:59:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 QB+DUlVjJ4FW for ; Wed, 27 Apr 2011 06:59:30 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) by ietfa.amsl.com (Postfix) with ESMTP id AD017E0704 for ; Wed, 27 Apr 2011 06:59:29 -0700 (PDT) Received: from [IPv6:2001:720:410:100f:223:32ff:fec4:ba94] ([IPv6:2001:720:410:100f:223:32ff:fec4:ba94]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id p3RE0mNa049446 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 27 Apr 2011 16:00:48 +0200 (CEST) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Iljitsch van Beijnum In-Reply-To: <10904.1303910619@marajade.sandelman.ca> Date: Wed, 27 Apr 2011 15:59:25 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <973158E6-34B9-4B84-B1E8-8C64A3140FB3@muada.com> References: <25942.1301412503@marajade.sandelman.ca> <20110413153213.GN24471@crankycanuck.ca> <10904.1303910619@marajade.sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.1084) Cc: behave@ietf.org Subject: Re: [BEHAVE] TTL in reply for DNS64 -- should be 1. X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 13:59:30 -0000 On 27 apr 2011, at 15:23, Michael Richardson wrote: > An RA option seems like a great thing to me, and I can't see why how > long this will take to standardize should matter. =20 > Iljitsch> Adding stuff to RAs is even harder than adding stuff to > Iljitsch> DHCP. I don't think handling this corner case more > Iljitsch> gracefully is worth the trouble. > okay, I find this very surprising. Which part? That it's hard or that because it's hard it's not worth = doing? The problem with RAs is that you need it in hosts and in routers, and = unless the user/administrator wants to do a lot of hacking, this needs = to sit deep in the OS. These OSes are on fairly long update cycles, and = in the case of routers, it can take REALLY long for software that's = available to be deployed, typically people don't update their routers = unless they really need to. Also, this needs to be configured unless the = router is the NAT64 or DNS64, which makes the chance of this happening = even smaller. So you're looking at at least one, but more realistically two years = before it even starts appearing. And even then you're looking at 5+ = years of partial deployment. So if you can't depend on this feature = being there for that long, you need to address the issue through other = means anyway, and then, what's the point of doing it in RAs anyway? > Iljitsch> If people have IPv6 but no IPv4 and run a local recursive > Iljitsch> DNS then presumably they'll have an incentive to > Iljitsch> investigate the availability of NAT64. > okay, so the problem is we need a signal that NAT64 is available so = that > local synethesis can occur. +1 on the network manager doing this. A host could assume (and test for) the presence of a NAT64 on the well = known prefix if it is running IPv6-only.= From mcr@sandelman.ca Wed Apr 27 15:14:58 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9B9CE06F7 for ; Wed, 27 Apr 2011 15:14:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.954 X-Spam-Level: X-Spam-Status: No, score=-1.954 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] 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 pMDavNx5MaKl for ; Wed, 27 Apr 2011 15:14:55 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 80E27E06EC for ; Wed, 27 Apr 2011 15:14:54 -0700 (PDT) Received: from marajade.sandelman.ca (unknown [199.7.156.34]) by relay.sandelman.ca (Postfix) with ESMTPS id DFBAA34015; Wed, 27 Apr 2011 18:14:53 -0400 (EDT) Received: from marajade.sandelman.ca (marajade.sandelman.ca [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id EDD1C98B44; Wed, 27 Apr 2011 18:16:03 -0400 (EDT) From: Michael Richardson To: Iljitsch van Beijnum In-Reply-To: <973158E6-34B9-4B84-B1E8-8C64A3140FB3@muada.com> References: <25942.1301412503@marajade.sandelman.ca> <20110413153213.GN24471@crankycanuck.ca> <10904.1303910619@marajade.sandelman.ca> <973158E6-34B9-4B84-B1E8-8C64A3140FB3@muada.com> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 22) Date: Wed, 27 Apr 2011 18:16:03 -0400 Message-ID: <8736.1303942563@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: behave@ietf.org Subject: Re: [BEHAVE] TTL in reply for DNS64 -- should be 1. X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 22:14:59 -0000 >>>>> "Iljitsch" == Iljitsch van Beijnum writes: Iljitsch> Adding stuff to RAs is even harder than adding stuff to Iljitsch> DHCP. I don't think handling this corner case more Iljitsch> gracefully is worth the trouble. >> okay, I find this very surprising. Iljitsch> Which part? That it's hard or that because it's hard it's Iljitsch> not worth doing? Iljitsch> The problem with RAs is that you need it in hosts and in Iljitsch> routers, and unless the user/administrator wants to do a Iljitsch> lot of hacking, this needs to sit deep in the OS. These Iljitsch> OSes are on fairly long update cycles, and in the case of Iljitsch> routers, it can take REALLY long for software that's Iljitsch> available to be deployed, typically people don't update Iljitsch> their routers unless they really need to. Also, this needs Iljitsch> to be configured unless the router is the NAT64 or DNS64, Iljitsch> which makes the chance of this happening even smaller. Iljitsch> So you're looking at at least one, but more realistically Iljitsch> two years before it even starts appearing. And even then No, I'm in a greenfield, and the routers I care about are all open source, and the CPE devices have SDKs. So, I think I can do it on my network in time for my NAT64/DNS64 deployment in June. If only I had a code point. >> okay, so the problem is we need a signal that NAT64 is available >> so that local synethesis can occur. +1 on the network manager >> doing this. Iljitsch> A host could assume (and test for) the presence of a NAT64 Iljitsch> on the well known prefix if it is running IPv6-only. okay, that's a good heuristic. I'll be hacking my install to return TTL=1 as well. It's my DNS server I'll be killing. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From wwwrun@rfc-editor.org Wed Apr 27 16:33:11 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A391BE080F; Wed, 27 Apr 2011 16:33:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.322 X-Spam-Level: X-Spam-Status: No, score=-102.322 tagged_above=-999 required=5 tests=[AWL=0.278, 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 kXAUXYDiGL8t; Wed, 27 Apr 2011 16:33:11 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by ietfa.amsl.com (Postfix) with ESMTP id 381E9E080B; Wed, 27 Apr 2011 16:33:10 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 41BAAE0751; Wed, 27 Apr 2011 16:33:10 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20110427233310.41BAAE0751@rfc-editor.org> Date: Wed, 27 Apr 2011 16:33:10 -0700 (PDT) Cc: behave@ietf.org, rfc-editor@rfc-editor.org Subject: [BEHAVE] RFC 6144 on Framework for IPv4/IPv6 Translation X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 23:33:11 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6144 Title: Framework for IPv4/IPv6 Translation Author: F. Baker, X. Li, C. Bao, K. Yin Status: Informational Stream: IETF Date: April 2011 Mailbox: fred@cisco.com, xing@cernet.edu.cn, congxiao@cernet.edu.cn, kyin@cisco.com Pages: 31 Characters: 67181 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-behave-v6v4-framework-10.txt URL: http://www.rfc-editor.org/rfc/rfc6144.txt This note describes a framework for IPv4/IPv6 translation. This is in the context of replacing Network Address Translation - Protocol Translation (NAT-PT), which was deprecated by RFC 4966, and to enable networks to have IPv4 and IPv6 coexist in a somewhat rational manner while transitioning to an IPv6 network. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From wwwrun@rfc-editor.org Wed Apr 27 16:33:53 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 796AFE0823; Wed, 27 Apr 2011 16:33:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.031 X-Spam-Level: X-Spam-Status: No, score=-102.031 tagged_above=-999 required=5 tests=[AWL=-0.031, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, 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 wjs24UmsCYQb; Wed, 27 Apr 2011 16:33:53 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by ietfa.amsl.com (Postfix) with ESMTP id AC33BE0824; Wed, 27 Apr 2011 16:33:25 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id A09F9E0778; Wed, 27 Apr 2011 16:33:25 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20110427233325.A09F9E0778@rfc-editor.org> Date: Wed, 27 Apr 2011 16:33:25 -0700 (PDT) Cc: behave@ietf.org, rfc-editor@rfc-editor.org Subject: [BEHAVE] RFC 6145 on IP/ICMP Translation Algorithm X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 23:33:53 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6145 Title: IP/ICMP Translation Algorithm Author: X. Li, C. Bao, F. Baker Status: Standards Track Stream: IETF Date: April 2011 Mailbox: xing@cernet.edu.cn, congxiao@cernet.edu.cn, fred@cisco.com Pages: 33 Characters: 76484 Obsoletes: RFC2765 I-D Tag: draft-ietf-behave-v6v4-xlate-23.txt URL: http://www.rfc-editor.org/rfc/rfc6145.txt This document describes the Stateless IP/ICMP Translation Algorithm (SIIT), which translates between IPv4 and IPv6 packet headers (including ICMP headers). This document obsoletes RFC 2765. [STANDARDS-TRACK] This document is a product of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From wwwrun@rfc-editor.org Wed Apr 27 16:33:55 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B249E0840; Wed, 27 Apr 2011 16:33:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.03 X-Spam-Level: X-Spam-Status: No, score=-102.03 tagged_above=-999 required=5 tests=[AWL=-0.030, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, 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 m-NNLDLIQ74d; Wed, 27 Apr 2011 16:33:55 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by ietfa.amsl.com (Postfix) with ESMTP id DCC58E082E; Wed, 27 Apr 2011 16:33:36 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id C9961E0780; Wed, 27 Apr 2011 16:33:36 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20110427233336.C9961E0780@rfc-editor.org> Date: Wed, 27 Apr 2011 16:33:36 -0700 (PDT) Cc: behave@ietf.org, rfc-editor@rfc-editor.org Subject: [BEHAVE] RFC 6146 on Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 23:33:55 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6146 Title: Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers Author: M. Bagnulo, P. Matthews, I. van Beijnum Status: Standards Track Stream: IETF Date: April 2011 Mailbox: marcelo@it.uc3m.es, philip_matthews@magma.ca, iljitsch@muada.com Pages: 45 Characters: 107954 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-behave-v6v4-xlate-stateful-12.txt URL: http://www.rfc-editor.org/rfc/rfc6146.txt This document is a product of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From wwwrun@rfc-editor.org Wed Apr 27 16:34:01 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F442E087F; Wed, 27 Apr 2011 16:34:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.029 X-Spam-Level: X-Spam-Status: No, score=-102.029 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, 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 KD7F102lt6+9; Wed, 27 Apr 2011 16:34:01 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by ietfa.amsl.com (Postfix) with ESMTP id 866CCE0838; Wed, 27 Apr 2011 16:33:47 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 71572E0784; Wed, 27 Apr 2011 16:33:47 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20110427233347.71572E0784@rfc-editor.org> Date: Wed, 27 Apr 2011 16:33:47 -0700 (PDT) Cc: behave@ietf.org, rfc-editor@rfc-editor.org Subject: [BEHAVE] RFC 6147 on DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 23:34:01 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6147 Title: DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers Author: M. Bagnulo, A. Sullivan, P. Matthews, I. van Beijnum Status: Standards Track Stream: IETF Date: April 2011 Mailbox: marcelo@it.uc3m.es, ajs@shinkuro.com, philip_matthews@magma.ca, iljitsch@muada.com Pages: 32 Characters: 75103 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-behave-dns64-11.txt URL: http://www.rfc-editor.org/rfc/rfc6147.txt DNS64 is a mechanism for synthesizing AAAA records from A records. DNS64 is used with an IPv6/IPv4 translator to enable client-server communication between an IPv6-only client and an IPv4-only server, without requiring any changes to either the IPv6 or the IPv4 node, for the class of applications that work through NATs. This document specifies DNS64, and provides suggestions on how it should be deployed in conjunction with IPv6/IPv4 translators. [STANDARDS-TRACK] This document is a product of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From wwwrun@rfc-editor.org Wed Apr 27 16:34:05 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 721E1E0824; Wed, 27 Apr 2011 16:34:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.815 X-Spam-Level: X-Spam-Status: No, score=-103.815 tagged_above=-999 required=5 tests=[AWL=1.262, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_MED=-4, 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 xY2MaVVdqoeo; Wed, 27 Apr 2011 16:34:04 -0700 (PDT) Received: from rfc-editor.org (rfcpa.amsl.com [64.170.98.47]) by ietfa.amsl.com (Postfix) with ESMTP id 1C6BCE087D; Wed, 27 Apr 2011 16:33:59 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 0AE1BE078B; Wed, 27 Apr 2011 16:33:59 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20110427233359.0AE1BE078B@rfc-editor.org> Date: Wed, 27 Apr 2011 16:33:59 -0700 (PDT) Cc: behave@ietf.org, rfc-editor@rfc-editor.org Subject: [BEHAVE] RFC 6156 on Traversal Using Relays around NAT (TURN) Extension for IPv6 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 23:34:05 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6156 Title: Traversal Using Relays around NAT (TURN) Extension for IPv6 Author: G. Camarillo, O. Novo, S. Perreault, Ed. Status: Standards Track Stream: IETF Date: April 2011 Mailbox: Gonzalo.Camarillo@ericsson.com, Oscar.Novo@ericsson.com, simon.perreault@viagenie.ca Pages: 14 Characters: 27758 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-behave-turn-ipv6-11.txt URL: http://www.rfc-editor.org/rfc/rfc6156.txt This document adds IPv6 support to Traversal Using Relays around NAT (TURN). IPv6 support in TURN includes IPv4-to-IPv6, IPv6-to-IPv6, and IPv6-to-IPv4 relaying. This document defines the REQUESTED- ADDRESS-FAMILY attribute for TURN. The REQUESTED-ADDRESS-FAMILY attribute allows a client to explicitly request the address type the TURN server will allocate (e.g., an IPv4-only node may request the TURN server to allocate an IPv6 address). [STANDARDS-TRACK] This document is a product of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From dwing@cisco.com Wed Apr 27 17:19:10 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E387E084D for ; Wed, 27 Apr 2011 17:19:10 -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 ewobj0WIIeKD for ; Wed, 27 Apr 2011 17:19:07 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id CE4B6E0691 for ; Wed, 27 Apr 2011 17:19:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=675; q=dns/txt; s=iport; t=1303949947; x=1305159547; h=from:to:subject:date:message-id:mime-version: content-transfer-encoding; bh=q6mEEvejbPOKSEpKaUmnyM0EbbN8bn3eNo8C07sv9hY=; b=F9z391BbRCwGrwwMSCNDKCLYPRllND08QWlKPWBUau+CuhFWGeEMZKsZ 710w2nOTYQ2UOQhQcR7uBl3eemx0z/z8UCMPNPXWq1gYb8bWTUQXs33/h UFqyd4QQiswOrxl6nn8DP/wU27iSKNlLGq8nsSBHk42er0kiR8ssW+d35 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AroHAJ2xuE2rRDoI/2dsb2JhbACYUYEkjAp3p3+dAYV2BIYDlxo X-IronPort-AV: E=Sophos;i="4.64,277,1301875200"; d="scan'208";a="688378999" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-6.cisco.com with ESMTP; 28 Apr 2011 00:19:07 +0000 Received: from dwingWS (dhcp-128-107-104-245.cisco.com [128.107.104.245]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3S0J7SY005373 for ; Thu, 28 Apr 2011 00:19:07 GMT From: "Dan Wing" To: Date: Wed, 27 Apr 2011 17:19:07 -0700 Message-ID: <03c501cc0539$e3808ff0$aa81afd0$@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: AcwFOeNib8Yg9k+EQBWv2X5oA0AFFA== Content-Language: en-us Subject: [BEHAVE] IPv6/IPv4 translation documents published as RFCs X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 00:19:10 -0000 Congratulations to the WG and authors for today's publication of BEHAVE's IPv6/IPv4 translation documents. This provides the industry with necessary IPv6 transition tools, and these specifications were finished with the urgency necessary due to IPv4 exhaustion. Great job. RFC6052, IPv6 Addressing of IPv4/IPv6 Translators (published October 2010) RFC6144, Framework for IPv4/IPv6 Translation RFC6145, IP/ICMP Translation Algorithm RFC6146, Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers RFC6147, DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers Thanks again, -d From cb.list6@gmail.com Wed Apr 27 17:43:18 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C41BEE08F0 for ; Wed, 27 Apr 2011 17:43:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.792 X-Spam-Level: X-Spam-Status: No, score=-2.792 tagged_above=-999 required=5 tests=[AWL=0.806, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 qfZ-UE9pZAwr for ; Wed, 27 Apr 2011 17:43:18 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id EDB32E08E8 for ; Wed, 27 Apr 2011 17:43:17 -0700 (PDT) Received: by eye13 with SMTP id 13so836150eye.31 for ; Wed, 27 Apr 2011 17:43:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=/TIb+F7zjddOuCrpcx772V45jh8znB1NaZRdASr0mgY=; b=PfOHXQn3q+w0xmXJH1l/GuYwMJcJCC9YfcHoyQFTHreUnX8VoqBPh5WiEnhypIgIu/ wARxk1NnwmtY4kCjY6ZSY2GBxUkX/wQnsPEttaGhr5aCss5mSJi+8aRU+2RvFJ8jJj8q g6txZCs1ftgscmaU+ISAYnyF+w9pX6I5DqNv0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=k4HaVdbEqVDhvz/GdWtK35FAoovs7bDLqX5xfCPc6IuGvtKLUuIaYTAbWN3dCs4IOg SQz8G5WYEJWRSP+GhKtXTyq00CgrZOZI6Q+8wjKJuZmB3c9uWljceB52+gGHxfceYZB5 rDe57uCw2jMNskvuWCPH89xBvQ5Vpjwffce6I= MIME-Version: 1.0 Received: by 10.14.17.194 with SMTP id j42mr1295590eej.81.1303951395101; Wed, 27 Apr 2011 17:43:15 -0700 (PDT) Received: by 10.14.126.210 with HTTP; Wed, 27 Apr 2011 17:43:15 -0700 (PDT) Received: by 10.14.126.210 with HTTP; Wed, 27 Apr 2011 17:43:15 -0700 (PDT) In-Reply-To: <03c501cc0539$e3808ff0$aa81afd0$@com> References: <03c501cc0539$e3808ff0$aa81afd0$@com> Date: Wed, 27 Apr 2011 17:43:15 -0700 Message-ID: From: Cameron Byrne To: Dan Wing Content-Type: multipart/alternative; boundary=0016e659fefcb59d8a04a1efd707 Cc: behave@ietf.org Subject: Re: [BEHAVE] IPv6/IPv4 translation documents published as RFCs X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 00:43:18 -0000 --0016e659fefcb59d8a04a1efd707 Content-Type: text/plain; charset=ISO-8859-1 On Apr 27, 2011 5:19 PM, "Dan Wing" wrote: > > Congratulations to the WG and authors for today's publication of BEHAVE's > IPv6/IPv4 translation documents. This provides the industry with necessary > IPv6 transition tools, and these specifications were finished with the > urgency necessary due to IPv4 exhaustion. Great job. > > RFC6052, IPv6 Addressing of IPv4/IPv6 Translators (published October 2010) > RFC6144, Framework for IPv4/IPv6 Translation > RFC6145, IP/ICMP Translation Algorithm > RFC6146, Stateful NAT64: Network Address and Protocol Translation from > IPv6 Clients to IPv4 Servers > RFC6147, DNS64: DNS Extensions for Network Address Translation from IPv6 > Clients to IPv4 Servers > +1. Great work. This work will have a very meaningful impact on the internet. Cb > Thanks again, > -d > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave --0016e659fefcb59d8a04a1efd707 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Apr 27, 2011 5:19 PM, "Dan Wing" <dwing@cisco.com> wrote:
>
> Congratulations to the WG and authors for today's publication of B= EHAVE's
> IPv6/IPv4 translation documents. =A0This provides the industry with ne= cessary
> IPv6 transition tools, and these specifications were finished with the=
> urgency necessary due to IPv4 exhaustion. =A0Great job.
>
> =A0RFC6052, IPv6 Addressing of IPv4/IPv6 Translators (published Octobe= r 2010)
> =A0RFC6144, Framework for IPv4/IPv6 Translation
> =A0RFC6145, IP/ICMP Translation Algorithm
> =A0RFC6146, Stateful NAT64: Network Address and Protocol Translation f= rom
> IPv6 Clients to IPv4 Servers
> =A0RFC6147, DNS64: DNS Extensions for Network Address Translation from= IPv6
> Clients to IPv4 Servers
>

+1. Great work. This work will have a very meaningful impact on the inte= rnet.

Cb

> Thanks again,
> -d
>
>
> _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www.i= etf.org/mailman/listinfo/behave

--0016e659fefcb59d8a04a1efd707-- From mohamed.boucadair@orange-ftgroup.com Wed Apr 27 23:06:44 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0CC0E0675 for ; Wed, 27 Apr 2011 23:06:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.092 X-Spam-Level: X-Spam-Status: No, score=-2.092 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, 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 m3yel-1gbkOp for ; Wed, 27 Apr 2011 23:06:44 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by ietfa.amsl.com (Postfix) with ESMTP id 0F2B5E064B for ; Wed, 27 Apr 2011 23:06:43 -0700 (PDT) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id 4FE6C1B824C; Thu, 28 Apr 2011 08:06:42 +0200 (CEST) Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 5C4B115805A; Thu, 28 Apr 2011 08:06:38 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.10]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Thu, 28 Apr 2011 08:06:38 +0200 From: To: "behave@ietf.org" Date: Thu, 28 Apr 2011 08:06:36 +0200 Thread-Topic: WG LC draft-ietf-behave-64-analysis Thread-Index: AcwFam6XdSPr8K9sR3+cQ8/1OPZbiw== Message-ID: <94C682931C08B048B7A8645303FDC9F33C5120D4DA@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F33C5120D4DAPUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.4.28.52417 Cc: "draft-ietf-behave-64-analysis@tools.ietf.org" Subject: [BEHAVE] WG LC draft-ietf-behave-64-analysis X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 06:06:44 -0000 --_000_94C682931C08B048B7A8645303FDC9F33C5120D4DAPUEXCB1Bnante_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear chairs, Would it be possible to launch a WG LC on this document as agreed in Prague= ? Thank you. Cheers, Med --_000_94C682931C08B048B7A8645303FDC9F33C5120D4DAPUEXCB1Bnante_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
D= ear=20 chairs,
 
W= ould it be=20 possible to launch a WG LC on this document as agreed in=20 Prague?
 
T= hank=20 you.
 
Cheers,
Med
 
--_000_94C682931C08B048B7A8645303FDC9F33C5120D4DAPUEXCB1Bnante_-- From buptnoc@gmail.com Thu Apr 28 18:58:32 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4BC2E0715 for ; Thu, 28 Apr 2011 18:58:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.125 X-Spam-Level: *** X-Spam-Status: No, score=3.125 tagged_above=-999 required=5 tests=[AWL=2.422, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, 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 lzYYmnLYB4GV for ; Thu, 28 Apr 2011 18:58:32 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 662C2E0713 for ; Thu, 28 Apr 2011 18:58:32 -0700 (PDT) Received: by pwi5 with SMTP id 5so1970660pwi.31 for ; Thu, 28 Apr 2011 18:58:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=5556NO6huMWGdhRKXWmzwThUWolI1uCqL4mgxuXIyRQ=; b=BWeAES18gMdffucd4ni9shWPAbwoEQvaZvgN0bsq+tF4Qvhq0CRg0Ik7GXxOv1acpZ Q15AZxs8PvJUVnYzuXYyZjzr1kdp3Pf2/48/DG9sEOXkYZ2nGkp/Eu+rT0XTYhSOXIOi 9BTv2RNZlOX+5Jlr/3lxEhvL2QDCiRm5Ump2s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=QssUNVVgV6fYc/ckoB9SmlpXTE3sdc4yMi/m3HcRu/x+rSDLINMIa+AvZV/H8agTfO 3U5VC6R5dP6VLZztp13uTftEw0ZePJ6R153ht7YKZ7D3JKiwbsCQZDzohVBeFtxL81Cn rHimj1a1z/d1mBdhRj0WyXwgMfH09TkxzV9CQ= Received: by 10.68.48.100 with SMTP id k4mr4629112pbn.160.1304042312011; Thu, 28 Apr 2011 18:58:32 -0700 (PDT) Received: from [210.25.132.207] ([210.25.132.207]) by mx.google.com with ESMTPS id z10sm1576806pbi.48.2011.04.28.18.58.29 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 28 Apr 2011 18:58:31 -0700 (PDT) Message-ID: <4DBA1B45.2060906@gmail.com> Date: Fri, 29 Apr 2011 09:58:29 +0800 From: buptnoc User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-CN; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: behave@ietf.org Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: 8bit Subject: [BEHAVE] Question about scenario 4 in draft-ietf-behave-v4v6-framework-10 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2011 01:58:32 -0000 Hi£¬

    As described in draft-ietf-behave-v6v4-framework-10#section-2.4 £¬ we need nat46 translator.
    But, do we really need this scenario£¿Is it worth to deploy this scenario?

    In fact, this scenario appears when we have v4-only client and v6-only servers! How can v6-only servers  benefit ISP or ICP?

    Thank you !